Five Requirements You've Already Met - If You Built the Architecture Right

Ron Reynolds · 2026-03-18 · 8 min read

There's an emerging consensus on what it takes to deploy MCP servers in production. Five requirements keep surfacing: narrow tool scope, integration governance, security, data quality, and end-to-end observability.

Most organizations are going to fail at this. Not because MCP is bad. Because the requirements for doing MCP well are the same requirements most companies skip when they're racing to ship.

Here are all five — and why they describe the architecture we built before the checklist existed. Requirement 1: "Design Your MCP Servers to Be Narrowly Focused"

Simon Margolis from SADA put it clearly: expose specific, granular tools — not general-purpose APIs. Narrow scope improves discovery, reduces token waste, and makes access control manageable.

This is the difference between handing an agent a Swiss Army knife and handing it a scalpel.

Most companies will get this wrong. They'll wrap their existing REST APIs in MCP and call it done. An agent will get a tool called api_call that accepts any endpoint, any payload, any method — and then they'll wonder why the agent hallucinates parameters, burns tokens exploring the API surface, and occasionally writes to production databases it shouldn't touch.

In ComOS, every MCP tool has a single job. catalogsearch searches the catalog. inventorycheck reads the shelf. order_create places an order. An agent connecting to our gateway doesn't explore — it acts. The tool name is the documentation.

Tools are organized by domain — catalog, inventory, orders, returns, customers, federation. Each domain is a coherent set of operations that make sense together, and there is no generic pass-through for an agent to wander into.

That's architecture, and it was chosen on purpose. Requirement 2: "Establish Integration Governance"

The experts split here. One camp says: make the MCP server the single source of truth. Another says: don't use MCP for data retrieval at all — use RAG. A third warns against exposing existing web APIs as MCP tools because they're too granular and verbose.

They're all partially right, which means they're all partially wrong.

The disagreement reveals the real problem: when your data lives in twelve different systems, there's no clean answer for how MCP should access it. Every approach is a compromise. The RAG camp is compensating for stale data. The centralization camp is trying to paper over fragmented sources. The API camp is acknowledging that existing APIs weren't designed for agent consumption.

None of those problems exist when the data is native.

In ComOS, the MCP gateway connects to a commerce operating system — not a collection of SaaS tools stitched together. When an agent queries inventory through our MCP tools, it gets the real number. Not a cached count from a webhook that fired six hours ago. Not a RAG retrieval from a document that was current last Tuesday.

Real inventory. Real prices. Real order status. The MCP layer is a window into the system, not a bridge between systems. There's nothing to govern because there's nothing to reconcile. Requirement 3: "Implement Security Non-Negotiables"

This is where it gets serious — and where most implementations will collapse.

Ian Beaver from Verint identifies the core vulnerability: "Prompt injection risks exist in both tool responses and inputs, making tool use the primary vulnerability point." Arash Nourian from Postman is blunter: MCP currently offers minimal security with weak authentication and unvetted registries.

They're describing the default state of MCP. The protocol itself doesn't enforce security. That's a feature, not a bug — MCP is a transport layer. But it means every implementation has to build its own security, and most will do it badly.

ComOS built this from the ground up:

OAuth 2.1 with PKCE — not API keys, not basic auth. Standards-compliant authorization with RFC 9728 and RFC 8414 discovery, so an MCP client finds the authorization server on its own.

Scoped permissions — orders:read, catalog:write, orders:refund, agents:admin. An agent gets exactly the permissions it needs and nothing more. A shopping agent can browse and buy but can't modify inventory. Refunds sit behind orders:refund, a step-up scope a person arms for the session on the consent screen; no other scope implies it.

Per-tenant isolation — every merchant's data is fully separated. An agent authenticated for Tenant A cannot see Tenant B's catalog, orders, or customers. Each tenant's records live in that tenant's own database, and a tool resolves the caller's tenant before it opens anything.

Full audit trail — every routed tool call writes a structured record: which agent, which tenant, which tool, the scope the tool required, the scope the caller held, and the outcome. Compliance asks for it, and you can't govern what you can't see. Requirement 4: "Don't Delegate Data Responsibilities to MCP Servers"

Sonny Patel from Socotra delivers the line that should be on every architect's wall: "AI agents can only be as effective as their data access quality."

The standard advice: validate inputs before they reach the agent's reasoning engine. Classify data. Establish access boundaries. Implement runtime interception to prevent tool poisoning.

All of that is necessary — when your MCP server is connecting to systems it doesn't control.

When you own the data layer, the equation changes. ComOS doesn't delegate data responsibility to the MCP gateway. The gateway is the commerce system. The data isn't being retrieved from somewhere else, validated, and passed through. It's authoritative by construction.

When an agent asks "is this product in stock?" the answer comes from the same record the last order decremented. Not an API proxy. Not a data lake. The source of truth.

When an agent places an order, order_create does the whole job in one call: it reads inventory for each line, reserves it inside the commit, resolves the price with tax and shipping, settles, and persists the order paid. If anything fails after the reservation, the reservation is released and the agent gets a clean error. The MCP layer doesn't need to intercept and validate because the commerce engine already did.

Data quality isn't a problem you solve with middleware. It's a problem you solve with architecture. Requirement 5: "Manage the End-to-End Agent Experience"

The final requirement is the one most teams will deprioritize — and the one that matters most in production.

Or Oxenberg from Lasso Security points out that MCP gateways only see inbound and outbound traffic. You need to capture everything: planning, decisions, actions, outcomes. Edgar Kussberg from Sonar adds that "when agents receive broad tools, they consume excessive tokens exploring and filtering, wasting budget and complicating workflows."

Both are describing the operational maturity gap. Getting MCP to work is step one. Getting it to work well — efficiently, observably, reliably — is the part that takes years.

ComOS watches its own gateway: Health endpoints report liveness, readiness, and a full health snapshot of the gateway and its upstreams A usage analytics agent writes one run record an hour with tenant counts and real p50/p95/p99 tool-call latency over the trailing window, so the trend is visible without opening a database On a node, an event-loop monitor logs any window in which one caller held the thread long enough to stall the others

Beyond the gateway, the same rule holds for every agent in the system: it reaches only what its scopes allow, and the scopes that move money, send to customers or publish a page are step-up scopes a person arms for the session.

The requirement says manage the experience. We say: the experience is the product. The Meta-Lesson

Look at all five requirements together and you'll notice a pattern. Every requirement is compensating for the same root cause: MCP is being deployed on top of architectures that weren't designed for it.

Narrow tool scope — because existing APIs are too broad. Integration governance — because data is fragmented. Security layers — because the underlying systems weren't built for agent access. Data validation — because the sources aren't authoritative. End-to-end management — because nobody has visibility across the full stack.

Every requirement is a patch. And patches work — until they don't.

The alternative is to build the architecture right from the beginning. Design the data model, the services, the security, and the agent governance as one coherent system — and then expose it through MCP as a natural extension of what already exists.

That's harder. That's slower at the start. But it means when an enterprise checklist shows up with five requirements, you've already met all five — because they describe your architecture, not your aspirations.