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

Ron Reynolds · 2026-03-18 · 7 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. cartadditem adds an item to a cart. checkoutstart starts a checkout. An agent connecting to our gateway doesn't explore — it acts. The tool name is the documentation.

We have 30 dedicated tools organized by domain — catalog, cart, checkout, orders, inventory, federation. Each domain is a coherent set of operations that make sense together. Plus a pass-through for the long tail of 43 REST endpoints that don't need their own dedicated tool.

That's not accidental. That's architecture. 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. Any enterprise SSO provider (Okta, Azure AD, any OIDC) plugs in natively.

Scoped permissions — cart:manage, orders:read, catalog:write, 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. A management agent can read analytics but can't process refunds.

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. The gateway enforces this at the routing layer, not the application layer.

Full audit trail — every tool call, every decision, every escalation is logged with the complete context chain. Not because compliance requires it (though it does). Because you can't govern what you can't see.

Security is a non-negotiable. That's why we didn't negotiate on it. 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 inventory service — the same service that decremented the count when the last order shipped. Not an API proxy. Not a data lake. The source of truth.

When an agent adds an item to a cart, the cart service validates the product exists, checks inventory, applies pricing rules, and confirms the addition — all before returning a response. 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 runs three autonomous agents on the gateway itself: A health monitor that tracks every tenant connection in real time A circuit breaker that opens after 5 failures and auto-recovers after 30 seconds — per tenant, so one bad connection doesn't take down the network A usage analytics agent that tracks tool call patterns, token consumption, and performance metrics

Beyond the gateway, every agent in the system operates under the Decision Engine — four autonomy levels (off, recommend, confirm, auto), confidence scoring on every action, merchant-controlled escalation, and time-windowed rollback.

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.