La fédération MCP expliquée
Publié · Mis à jour · Synamcps
Une seule porte MCP pour Jira, GitHub et serveurs internes — credentials chiffrés au repos et tools namespacés en {slug}__{tool}.
Les organisations exécutent rarement un seul serveur MCP. Vous avez peut-être déjà un Jira MCP, un GitHub MCP et un MCP de données interne — chacun avec son URL, ses credentials et son histoire d'ACL. Les agents ont besoin de nombreuses connexions, et la sécurité perd un lieu unique pour appliquer la politique.
La fédération MCP dans Synamcps consiste à enregistrer ces serveurs upstream HTTP/SSE dans l'Admin UI. Synamcps découvre automatiquement tools, resources et prompts, les namespace en {slug}__{tool}, et les réexpose sur le même endpoint /mcp que les tools de connaissances natives.
La gouvernance reste unifiée. Les tokens à permissions réduites, les rate limits par token et les allowlists façon storage s'appliquent aux tools fédérées comme à knowledge_search. Les secrets upstream sont chiffrés au repos : la passerelle — pas chaque config d'agent — détient les credentials.
Le résultat est une seule porte pour une flotte d'agents : Claude Code, Cursor et runners personnalisés s'authentifient une fois, reçoivent un tools/list adapté à leur token, et atteignent chaque capacité upstream autorisée — sans sonder des serveurs qu'ils ne devraient jamais voir.
Si vous consolidez le sprawl MCP ou construisez une plateforme d'agents à moindre privilège, la fédération transforme de nombreuses origines MCP en une surface gouvernée sans réécrire chaque serveur upstream.