One MCP server, five scopes: how 27 agents share a single brain

As soon as you have more than a couple of agents, "let each one call the APIs it needs" stops scaling. You duplicate auth, retries and schemas; a change in one place silently breaks five others. The Model Context Protocol (MCP) exists to put a clean seam between agents and the systems they act on.

A single entry point with scoped access

I run one self-hosted MCP server in front of org memory. Agents never touch Postgres or third-party APIs directly — they talk to MCP. Access is split into five scopes, so a marketing agent simply cannot reach finance tools. One door, with a bouncer, instead of 27 unlocked windows.

Hybrid search is the actual product

Under MCP sits Postgres 16 + pgvector. Pure vector search misses exact strings; pure keyword search misses meaning. I fuse vector, BM25 and trigram with Reciprocal Rank Fusion, so a query for an exact part number and a query for a vague concept both land. That hybrid retrieval is what makes the tools feel sharp instead of fuzzy.

Tools are contracts, not endpoints

Each MCP tool has a typed schema and a single responsibility. The model gets a clear contract it can reason about; I get one place to add validation, logging and limits. When a tool changes, every agent gets the new behaviour at once — no copy-paste drift across 27 codepaths.

Why MCP over a pile of function-calling glue

• One auth and audit surface instead of N separate ones.
• Tools are reusable across agents and across LLM vendors (Claude, GPT) behind one gateway.
• A new agent means picking scopes, not rebuilding integrations.
• Schemas live in one repo, versioned and reviewable.

What I would tell a team starting today

Do not let every agent grow its own tentacles. Put a protocol between your agents and your data on day one, even with just two agents. Adding the seam early costs an afternoon; untangling it at 27 agents costs a rewrite.

“The integration you do not write is the one you never have to debug.”