Instance federation

Agents and MCPMCPHTTPPOST /api/mcp/serversstreamable-httpservice accountmcp:read

One Long Tail calls another's tools over MCP with a service account the remote issues; neither side shares a database or a login.

The situation

Operations and sales each run their own instance, with their own roles, queues and workflows. A shared instance needs to read operations’ queues and start a workflow there, without merging databases or handing out logins.

The recipe

On the remote, create a service account with only the roles the connection should act under, and mint a key. On the calling instance, register the remote’s /mcp as a server:

curl -X POST https://lt.acme.dev/api/mcp/servers \
  -H "Authorization: Bearer $LT_TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "name": "operations-longtail",
    "transport_type": "streamable-http",
    "transport_config": {
      "url": "https://ops.lt.acme.dev/mcp",
      "headers": { "Authorization": "Bearer <remote service-account key>" }
    },
    "tags": ["longtail", "operations"],
    "auto_connect": true
  }'

POST /api/mcp/servers/test-connection lists the tools the remote offers this account; POST /api/mcp/servers/:id/connect connects and caches the list.

The guarantee

The remote decides what the connection can do: it lists only the tools its account’s roles allow, applies the key’s scope, filters every result to the account’s read scope, and records every action as that account. The calling instance decides who may use the connection: calling an external server’s tools directly is a builder capability, and everyone else reaches the remote through deployed workflows with their own invocation roles. Revoking the key on the remote ends the connection on its next call. See MCP.

Agents and MCP