Scrydon

Serveurs MCP

Livrez la définition gouvernée d'un serveur MCP dans un Pack Scrydon et maîtrisez son approbation, sa disponibilité et son transport

Cet artefact est livré dans un Pack. Pour le cycle de vie partagé — pack build, téléversement, installation — voir Packs & SDK d'authoring.

Une entrée de contenu serveur MCP permet à un pack de livrer un serveur Model Context Protocol entièrement configuré — son transport, son point de terminaison (ou sa commande de lancement) et ses outils annoncés — sous forme de configuration sérialisable en JSON. L'application du pack enregistre le serveur au niveau de l'organisation. Une installation explicite par un administrateur ou une source signée l'enregistre comme approved ; une synchronisation non interactive d'une source non signée l'enregistre comme pending, en attente d'examen. Personne ne saisit d'URL ni de commande à la main.

Contrairement à une intégration, un serveur MCP ne porte aucun artefact de code — le manifeste est toute la définition, il voyage donc en ligne dans le pack, sans bundle.tar.gz.

Création avec defineMcpServer

mcp-server-github/manifest.ts
import { defineMcpServer } from "@scrydon/sdk-authoring/mcp-servers/define";

export default defineMcpServer({
  // Slug kebab stable — la clé d'idempotence. Renommer `name` plus tard est sûr ;
  // changer `id` enregistre un nouveau serveur.
  id: "github-mcp",
  name: "GitHub MCP",
  description: "Outils d'issues et de PR pour les dépôts GitHub.",
  transport: "streamable-http",
  url: "https://mcp.example.com/github",
  // Outils annoncés → la liste d'autorisation du registre. La découverte en
  // direct a toujours lieu à la connexion ; ceci est la surface de gouvernance.
  tools: ["search_issues", "create_issue"],
});

stdio est actuellement limité à l'enregistrement. Il ne peut pas devenir disponible par défaut dans l'organisation, être installé ou activé dans un espace de travail, ni être exécuté. Son exécution nécessite le plan MCP gouverné introduit par la PR #2140 ainsi qu'un dispatcher stdio distinct, examiné, sur ce plan ; la fusion du plan seul n'active pas stdio. Les entrées stdio enregistrées restent visibles et supprimables.

Un serveur stdio déclare une command (et éventuellement args / envVarKeys) au lieu d'une url :

export default defineMcpServer({
  id: "everything",
  name: "Everything",
  transport: "stdio",
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-everything"],
  envVarKeys: ["API_KEY"],
});

Champs

ChampRequisNotes
idSlug kebab minuscule stable. La clé d'idempotence — gardez-le stable entre versions.
nameNom d'affichage. Doit être unique dans l'organisation.
descriptionAffiché dans l'interface du registre.
transport"streamable-http" ou "stdio".
urlpour HTTPPoint de terminaison pour streamable-http.
command / argspour stdioCommande de lancement pour stdio.
envVarKeysNoms réservés au futur dispatcher stdio gouverné. Les valeurs ne sont jamais intégrées ; le runtime actuel n'exécute pas stdio.
toolsNoms des outils annoncés → la liste d'autorisation du registre.
authConfiguration d'authentification par référence uniquement — voir ci-dessous. Omettez-la et le serveur s'enregistre sans authentification particulière.

Authentification (auth)

L'authentification est livrée par référence, jamais sous forme de jeton intégré. Le champ auth est un sous-ensemble du modèle d'authentification du registre pour les serveurs HTTP streamable packagés qui s'exécutent sans interaction ou depuis un workflow, sans utilisateur présent :

kindUsage
"none"Aucun en-tête d'authentification.
"static_header"Envoie la table d'en-têtes statiques configurée, dont les placeholders {{secret}} sont résolus depuis le coffre de secrets de l'espace de travail à l'exécution. (envVarKeys est le mécanisme distinct d'env stdio, pas des valeurs d'en-tête.)
"oauth_client_credentials"OAuth 2.1 service-à-service. Requiert tokenUrl, clientId et clientSecretRef (une référence vers un secret de l'espace de travail, jamais le secret lui-même) ; scopes, audience, resource, useBasicAuth optionnels.
defineMcpServer({
  id: "github-mcp",
  name: "GitHub MCP",
  transport: "streamable-http",
  url: "https://mcp.example.com/github",
  auth: {
    kind: "oauth_client_credentials",
    tokenUrl: "https://idp.example.com/oauth/token",
    clientId: "scrydon-github-mcp",
    clientSecretRef: "github-mcp-client-secret", // résolu depuis le coffre de secrets
    scopes: ["repo"],
  },
});

Ne mettez pas de secrets dans le manifeste. Les modes délégués par utilisateur (oauth_authorization_code, managed_ema) ne sont pas disponibles pour les packs — ils nécessitent un utilisateur présent, ce qu'une exécution déclenchée / en arrière-plan n'a pas.

Structure du pack

Placez chaque serveur dans son propre sous-dossier ; référencez-le depuis pack.json :

pack.json
{
  "contents": [
    { "kind": "mcp-server", "path": "mcp-server-github", "version": "1.0.0", "required": true }
  ],
  "installOrder": ["mcp-server"]
}
mcp-server-github/
  manifest.json   # la sortie de defineMcpServer (pas de bundle.tar.gz)

Un pack peut livrer plusieurs serveurs MCP — donnez à chacun son propre sous-dossier mcp-server-<slug>/.

Cycle de vie

Construire et appliquer — exécutez pack build, puis installez le pack ou synchronisez sa source. Une installation explicite par un administrateur ou une source signée crée une ligne approved. Une synchronisation non interactive non signée crée une ligne pending.
Examiner les entrées en attente — un administrateur d'organisation examine et approuve le contenu. L'approbation accepte la définition dans le registre de l'organisation ; elle ne rend pas stdio exécutable.
Rendre le HTTP distant disponible — un administrateur d'espace de travail peut ajouter un serveur streamable-http approuvé. Un administrateur d'organisation connecté peut aussi le rendre disponible par défaut dans toute l'organisation. Un espace de travail peut supprimer ce serveur par défaut pour créer une exclusion explicite, puis l'ajouter de nouveau. La configuration d'un serveur par défaut matérialise les surcharges de l'espace de travail.
Réappliquer sans doublon — appliquer la même combinaison (organisation, pack, id source) met à jour une seule ligne et préserve son statut de gouvernance. Renommer name en conservant id met cette ligne à jour ; changer id enregistre une autre entrée source.

Un pack ne peut pas écraser un serveur qu'il ne possède pas : si l'organisation a déjà un serveur du même name créé à la main ou livré par un autre pack, l'installation refuse cette entrée au lieu de l'écraser.

Les serveurs enregistrés apparaissent sur la page Packs sous Contribue → Serveurs MCP. Les serveurs HTTP streamable approuvés peuvent ensuite apparaître dans les paramètres de l'organisation et le Marketplace de l'espace de travail selon leur politique de disponibilité.

Sur cette page

Sur cette page