Multi-Server Federation

Enterprise data does not live in one system. Customer records are in Salesforce, support tickets in ServiceNow, financial data in SAP, logs in Elasticsearch, and documents in SharePoint. MCP federation connects an AI client to multiple MCP servers simultaneously — each server owns one data source, and the client aggregates data across them at read time. No ETL pipeline, no data warehouse, no overnight batch jobs. The AI model reads from each server independently and correlates the data in its context window.

Federation architecture has three layers. The transport layer establishes connections to each MCP server — typically stdio for local servers and SSE for remote ones. The discovery layer enumerates available resources from each server using resources/list, building a unified catalog the client can navigate. The routing layer directs resource reads to the correct server based on URI scheme — salesforce:// goes to the Salesforce server, servicenow:// goes to the ServiceNow server. The client handles routing transparently; the model does not need to know which server serves which resource.

Server isolation is a feature, not a limitation. Each MCP server runs its own authentication, applies its own access control, and manages its own connection pool. A failure in the Salesforce server does not affect the ServiceNow server. This blast-radius containment is critical in enterprise environments where data sources have different SLAs, maintenance windows, and failure modes. The federation layer must handle partial availability — if one server is down, the client should still be able to read from the others.

{
  "mcpServers": {
    "salesforce": {
      "command": "npx",
      "args": ["-y", "@company/mcp-salesforce"],
      "env": {
        "SF_INSTANCE_URL": "${SF_INSTANCE_URL}",
        "SF_ACCESS_TOKEN": "${SF_ACCESS_TOKEN}"
      }
    },
    "servicenow": {
      "command": "npx",
      "args": ["-y", "@company/mcp-servicenow"],
      "env": {
        "SN_INSTANCE": "${SN_INSTANCE}",
        "SN_USER": "${SN_SERVICE_USER}",
        "SN_PASSWORD": "${SN_SERVICE_PASSWORD}"
      }
    },
    "sap": {
      "transport": "sse",
      "url": "https://mcp-sap.internal.company.com/sse",
      "headers": {
        "Authorization": "Bearer ${SAP_MCP_TOKEN}"
      }
    },
    "data-lake": {
      "command": "npx",
      "args": ["-y", "@company/mcp-datalake"],
      "env": {
        "LAKE_ENDPOINT": "${DATA_LAKE_ENDPOINT}",
        "LAKE_KEY": "${DATA_LAKE_KEY}"
      }
    }
  }
}

1. Inventory your data sources List every system the AI needs to read from. For each, identify the owner, authentication method, data sensitivity, and availability SLA. This becomes your federation roadmap.
2. Deploy servers incrementally Start with the two highest-value, most-stable data sources. Get authentication, access control, and monitoring working before adding more servers to the federation.
3. Handle partial failures Test what happens when one server is unavailable. The client should gracefully degrade — read from available servers and clearly indicate which data sources are unreachable.