MCP federation explained
Published · Updated · Synamcps
One MCP front door for Jira, GitHub, and internal servers — with credentials encrypted at rest and tools namespaced as {slug}__{tool}.
Organizations rarely run a single MCP server. You may already have a Jira MCP, a GitHub MCP, and an internal data MCP — each with its own URL, credentials, and ACL story. Agents then need many connections, and security loses a single place to enforce policy.
MCP federation in Synamcps means registering those upstream HTTP/SSE servers in the Admin UI. Synamcps auto-discovers tools, resources, and prompts, namespaces them as {slug}__{tool}, and re-exposes them on the same /mcp endpoint as native knowledge tools.
Governance stays unified. Permission-narrowing tokens, per-token rate limits, and storage-style allowlists apply to federated tools the same way they apply to knowledge_search. Upstream secrets are stored encrypted at rest so the gateway — not every agent config — holds the credentials.
The result is one front door for a fleet of agents: Claude Code, Cursor, and custom runners authenticate once, receive a tools/list tailored to their token, and reach every upstream capability they are entitled to — without probing servers they should never see.
If you are consolidating MCP sprawl or building a least-privilege agent platform, federation turns many MCP origins into one governed surface without rewriting each upstream server.