Skip to content

One MCP vs. many

A practical question every Gaby operator hits: do I plug in one MCP per backing system (Postgres + Keycloak + GitHub + Notion = 4 connectors), or do I run a single team-MCP that exposes everything?

Both work. They have different trade-offs. Here's the recommendation, and the reasoning.

TL;DR

Recommended for most teams: one workspace-MCP exposing the tools your team uses. Cheaper LLM-side, smaller blast radius, easier to evolve. The federated alternative (one MCP per system) is fine and remains the default when you onboard with the curated connectors, but consolidates poorly as your tool surface grows.

How they differ

Federated (one MCP per system) — the default

                  ┌────────────────────┐
                  │   Gaby (host)      │
                  └────────────────────┘
                    │      │      │
              ┌─────┘      │      └─────┐
              ▼            ▼            ▼
        Postgres-MCP   GitHub-MCP   Notion-MCP

What you get:

  • Drop-in connectors from Connectors → Add.
  • Each MCP is independently maintained upstream.
  • Failures are isolated: a Notion outage doesn't take Postgres reads down.

What it costs you:

  • Every planner call sees the union of every MCP's tools. With 6 connectors averaging 8 tools each, that's 48 tools in the tools-block — bigger prompt, more attention burned on tool selection.
  • The 4-breakpoint prompt cache (see ARCHITECTURE.md §8.2) caches the tools block once, so the cost is paid once per cache window — but the window does churn.
  • Scope management lives across multiple connectors.scopes rows. Auditing "what can this agent actually touch?" requires looking at all of them.

Consolidated (one workspace-MCP)

                  ┌────────────────────┐
                  │   Gaby (host)      │
                  └────────────────────┘
                            │
                            ▼
                  ┌────────────────────┐
                  │   team-mcp         │
                  │  - get_user(id)    │
                  │  - get_invoice(id) │
                  │  - search_repo(q)  │
                  │  - …               │
                  └────────────────────┘
                    │      │      │
              ┌─────┘      │      └─────┐
              ▼            ▼            ▼
        Postgres       GitHub       Notion

What you get:

  • One tool surface, shaped to your domain. Instead of 48 raw tools, you expose 6 high-level ones the agent actually needs (get_customer, find_related_tickets, etc).
  • One place to define scopes. Your MCP enforces "this tool can read customers, never write."
  • One audit log per MCP, easier to reason about.
  • Smaller tools block per planner call: cheaper, faster, more accurate tool selection.

What it costs you:

  • You have to write and maintain the MCP. ~150 lines of Python for a starter (see connectors/example-mcp/); production-shaped ones can grow to a few hundred.
  • A bug in your MCP affects every tool in it. The restart supervisor handles crashes, but a logic bug in one tool can affect adjacent ones.
  • You're responsible for the upstream APIs your MCP wraps. The community MCPs do this work for you.

When to pick which

Pick federated when:

  • You're trying Gaby out, wiring up the obvious systems (Postgres, GitHub, Slack). The curated connectors get you running in minutes.
  • The tools you need from each system are roughly what the community MCP already exposes.
  • Your team doesn't have engineering bandwidth to maintain an internal MCP.

Pick consolidated when:

  • The investigations you care about cross 4+ backing systems and you want the agent to reason at the level of "the user", not "the user in Keycloak + their row in Postgres + their Stripe subscription".
  • You have specific business rules ("never read PII columns from customer table") that you want enforced at the tool boundary, not in prompts.
  • You're at the scale where prompt cost matters and you've noticed the planner spending tokens on tool selection.

You can also mix: keep the curated Postgres + Keycloak builtins (they do the basics well), and add a single consolidated MCP for your domain logic on top.

What we recommend at Skycloak (running Gaby ourselves)

Two-tier:

  1. Builtin Postgres for raw DB reads (we trust the read-only scope gates).
  2. skycloak-mcp — internal, domain-shaped — for the high-level tools (describe_tenant, latest_deploy_status, find_related_tickets).

The planner gets the domain tools at the top and falls through to raw Postgres when nothing higher-level fits. Best of both.

  • Bring your own MCP — how to wire one in.
  • Community catalogue — what we ship pre-curated.
  • ARCHITECTURE.md §5 — the MCP host's lifecycle + restart supervisor.
  • ARCHITECTURE.md §8.2 — prompt cache layout (why tool count matters).