Where your MCP server lives matters more than how you build it: an architecture guide

EastVersion1226 · reddit · 2026-09-08

After running several PoCs before committing to an agent build, the author found that the MCP spec deliberately avoids saying where the server should sit, while vendor docs only pitch their own placement — so they wrote the decision framework they wish they'd had.

There are really only two families, four shapes:

Co-located: MCP embedded in an existing service — inside a BFF aggregation layer, or shipping with the domain service that owns the tools
Dedicated: MCP as its own networked service — a "gateway" in front of backend services, or a "direct DB" shape

Six decisive questions before choosing:

What are you exposing — single capabilities fit domain services; cross-domain workflows fit a gateway; mixing them yields the "God Tool" anti-pattern
How large is the tool surface — production telemetry (N=200 per bucket) shows LLM tool-selection accuracy degrades past 10–15 tools: Claude Haiku 4.5 holds ≥90% accuracy up to 10 tools and drops at 15; Sonnet 4 at 20/30. Past 10 tools you need retrieval-over-tools or partitioning with an aggregator
Who owns the contract — the hidden cost of gateways: every downstream API change risks tool drift; enforce versioning discipline downstream or co-deploy MCP with the service
Authorization boundary — row/field-level auth must be structural (RLS, deterministic query rewrite, role-scoped views), never prompt-based, or you're building the next Supabase-shaped incident
Cross-domain composition — queries spanning two bounded contexts distributed across domain-service MCPs become chatty and error-prone; this needs a composition layer with Tool Orchestrator patterns

Original post →

Where your MCP server lives matters more than how you build it: an architecture guide

More from coding & agent