The Model Context Protocol, MCP, is the most important piece of enterprise AI infrastructure nobody explained properly in 2024. By the time most organisations noticed, the decision wasn’t whether to adopt MCP but how not to do it badly.
This is the handbook I wish existed when we started shipping MCP servers into regulated environments. It covers what MCP is, why it matters, the enterprise concerns that will break a hobby-grade implementation, the architecture patterns that actually survive audit, and the engagement shapes that make sense depending on where you’re starting.
If you want the deeper technical spec, the canonical docs at modelcontextprotocol.io are authoritative. This essay is the operator view, what to worry about, in what order, and why.
What MCP actually is
MCP is a standardised protocol for exposing tools, resources, and prompts to AI models and agents. An MCP server offers capabilities. An MCP client (Claude Desktop, ChatGPT Enterprise, Gemini, custom LangGraph agents, n8n workflows, Claude Code) discovers and calls them.
The three primitives:
- Tools: actions the agent can take (send email, query a table, post to an API). Typed inputs, typed outputs, descriptions the model can reason about.
- Resources: read-only data the agent can pull (documents, database rows, logs). Addressable by URI.
- Prompts: reusable prompt templates the client can offer to the user.
If you think “this sounds like just an API”, you’re not wrong, but you’re missing the architectural point.
The architectural point
Before MCP, every integration between an AI model and an internal system was bespoke to that model. OpenAI functions. Claude tool schemas. Azure connectors. Gemini function calls. When you swapped models, and in 2025 most serious enterprises swapped at least once, every integration rotted.
MCP solves this by standardising the integration interface. One MCP server can be consumed by any MCP-aware client. Your integration to SAP, or Dynamics, or your internal knowledge base, becomes a reusable asset rather than per-vendor work.
This is why the protocol moved from “interesting” to “inevitable” in 2025: Anthropic, OpenAI, Google, and Microsoft all standardised around it. Gartner now forecasts 40% of enterprise applications will include task-specific AI agents by end of 2026, up from less than 5% a year ago. Forrester projects 30% of enterprise app vendors will launch their own MCP servers in 2026. The ecosystem has passed 5,000 public servers and growing fast.
Translation: if you are building agents in 2026 and not using MCP, you are fighting the ecosystem.
Why enterprise MCP is a different beast
Public MCP servers for hobby use are fine. Drop-in, wire-up, done. Enterprise MCP is different, because your concerns are different:
- Identity. Agents act on behalf of users. Your server must carry identity through to the underlying system, not act as an omnipotent service account.
- Tenancy. Multi-business-unit or multi-customer? The server must guarantee tenant isolation even under adversarial prompts.
- Auditability. Every call needs an audit trail your compliance team will accept.
- Rate & cost control. Agents loop. Without limits, one bad prompt can burn a quarter’s budget.
- Data scope. Which data can this agent reach, for this user, in this tenant, at this time?
- Schema discipline. Typed everything. Descriptions that are accurate. Deprecations managed.
- Portability. Across models and across clients, without hidden assumptions about one vendor.
Miss any of these and you will either get a veto from security at go-live, or an incident three months in.
The seven layers of an enterprise MCP server
Think of an enterprise MCP server as a stack. Each layer does a discrete job; each failure mode lives at a specific layer.
1. Transport
MCP supports three transports: stdio (local, for IDE and desktop use), streamable HTTP (remote, HTTP-based, the usual enterprise choice), and SSE (server-sent events, legacy). Pick based on deployment context.
For enterprise, streamable HTTP is almost always the answer. It runs behind a gateway, plays nicely with SSO, and survives NAT traversal. TLS 1.3 end-to-end, no exceptions.
A common mistake is exposing the server directly to the public internet. Don’t. Put it behind an API gateway with IP allowlisting, WAF rules, and DDoS protection, the same posture you’d use for any internal API surfaced to external partners.
2. Authentication & authorisation
This is the layer that kills the most hobby-grade implementations at security review.
The pattern that works:
- Interactive agents (user sits in front of an MCP client): OAuth 2.0 with PKCE, the user’s identity flows through to the server, and from there into the underlying system.
- Non-interactive agents (scheduled, service-to-service): service principals or workload identity, with the principal explicitly recorded in every audit log.
- Token scope: every token is scoped to the minimum necessary, a read token cannot write, a single-tenant token cannot reach another tenant, and no token has “all tools” permission by default.
Your server should reject any call that cannot be tied to a specific, identified principal. “Anonymous” is not an enterprise option.
3. Authorisation policy (the Z-axis)
Authentication answers who is this?. Authorisation answers what are they allowed to do right now?. These are different problems.
For an enterprise MCP server, authorisation lives at three levels:
- Tool level: can this principal invoke this tool at all?
- Argument level: can this principal pass these arguments? (e.g., can they query for financial data in this region, for this date range?)
- Row / record level: of the results the underlying system returns, which ones is the principal allowed to see?
Most public MCP servers handle level 1 only. Enterprise servers must handle all three. Build authorisation as a policy layer, it belongs outside the tool logic, and wire it into every call.
4. Schema discipline
The MCP spec is generous; enterprise rigour is not.
- Every tool input and output is typed with JSON Schema.
- Every field has a description that would be useful to a model reading it cold.
- Deprecated tools are marked deprecated, not silently removed.
- Additions are backwards-compatible, or they’re a new tool rather than a breaking change to the old one.
- The schema is the contract, and it’s versioned.
Why this matters: models reason about tools using their descriptions. A fuzzy description produces hallucinated calls. A broken contract produces mystery failures agents cannot recover from.
5. Observability
If you can’t see it, you can’t debug it or audit it. Instrument every call with:
- Trace ID. Propagated from the client through every downstream call.
- Principal. The identified user or service.
- Tool + arguments. Full arguments, redacted where they contain secrets.
- Result. Success/fail, duration, error class.
- Cost. Tokens, API units, downstream-system cost.
- Model & client. Which agent/model/client invoked this call?
Ship these to your existing observability stack, OpenTelemetry is the lingua franca, and will land cleanly in Datadog, Grafana, Azure Monitor, or Splunk. Don’t build a bespoke logging system for MCP; use what the rest of your platform already uses.
6. Governance & audit
Audit is observability with a longer retention period and a different query surface. Your compliance team will eventually ask:
- “Did any agent access customer X’s data on date Y?”, needs to be a query.
- “Which tools have been called by principal Z in the last 30 days?”, needs to be a query.
- “Show me every failed authorisation attempt.”, needs to be a query.
- “What was the full input and output of this specific call?”, retrievable, with the principal attached, within the retention window.
Get the audit schema right before your first go-live. Retrofitting is painful and sometimes impossible.
Under the EU AI Act, which becomes enforceable for high-risk systems on 2 August 2026, with penalties up to €35M or 7% of global turnover, this audit capability may be a compliance requirement, not just a nice-to-have. Build accordingly.
7. Rate & cost control
Agents loop. Sometimes productively. Sometimes not. Your server protects the underlying systems and your budget.
- Per-principal rate limits. N calls per minute per principal. Hard-enforced.
- Per-tool rate limits. Some tools are cheap, some are not. Limit the expensive ones harder.
- Per-tenant cost caps. Monthly budget per tenant. Alert at 50%, 80%, 100%. Hard stop at 120%.
- Timeouts. Default aggressive, overridable by tool when the underlying system genuinely takes longer.
This layer is where you find out whether your MCP server is enterprise-grade or a lab experiment.
The ten decisions that shape your server
When we scope an MCP engagement, these are the decisions I walk the architect through in week one. Nail them now; revisit them only if constraints change.
- Which systems will this server reach? One server per system, or a consolidated server with a grouped tool surface?
- Interactive, non-interactive, or both? Drives the auth model.
- SSO provider. Entra ID, Okta, Auth0, something homegrown? Are service principals available?
- Tenancy model. Single tenant, multi-tenant hard-isolated, multi-tenant shared infrastructure?
- Data classification. What’s the highest-sensitivity data this server can touch, and what are the corresponding controls?
- Deployment. Your cloud, our cloud, self-hosted on-prem, sovereign region?
- Clients. Which MCP-aware clients need to consume this server? Drives transport and auth choices.
- Observability target. Your existing stack, or do we bring one?
- Compliance context. ISO, SOC 2, HIPAA, PCI, EU AI Act, what are the relevant regimes?
- Lifecycle. Who maintains this server after handover? Internal team, us, or shared?
Get these wrong early and you pay for it every week for the server’s lifetime.
Four architectures we see in the wild
Architecture A, “single-system server”
One MCP server wraps one underlying system (e.g. NetSuite, or Dynamics Finance). SSO at the gateway, service principal for non-interactive, audit in Splunk.
Best for: starting out, or where the underlying system’s surface area is large enough to warrant its own server.
Pitfall: teams sometimes build one of these and then bolt tools for adjacent systems onto it “temporarily”. This is always temporary forever. Don’t.
Architecture B, “domain server”
One MCP server per business domain (e.g. “Finance”, “HR”, “Supply”), which internally fans out to multiple underlying systems. Domain-level authorisation policy sits in the server.
Best for: mature organisations with clear domain boundaries and platform engineers who can own the composition.
Pitfall: domain servers accumulate responsibilities and become monoliths. Treat them as platforms, not utilities.
Architecture C, “MCP gateway + many servers”
A central MCP gateway federates many smaller servers. The gateway handles auth, rate limits, audit, and routing. Individual servers can be owned by different teams.
Best for: large organisations with many MCP servers (usually 10+) and a platform team that can own the gateway.
Pitfall: the gateway becomes a single point of failure and a single point of contention. Invest in its operability before this is a problem.
Architecture D, “MCP as a product surface”
Your organisation publishes an MCP server as a product for external customers to consume. Their agents reach your systems through this surface.
Best for: SaaS vendors and platform businesses. Forrester projects 30% of enterprise app vendors will do this in 2026.
Pitfall: external-facing MCP is a different threat model. Every concern in this handbook applies, and more. Consider it a product launch, not an internal integration.
Practical patterns that save pain
A few patterns we keep reusing, without ceremony:
The “read-then-write” split. Expose separate read and write tools for every capability, with different auth scopes. Most agent workflows need read more than write. This makes the blast radius of a misconfigured token bounded.
The “preview / commit” pattern. For destructive operations, expose a preview tool that returns what would happen, and a commit tool that enacts it. The agent calls preview first, surfaces the intent to a human (or the governance layer), then commits.
Idempotency keys. Every write tool accepts an idempotency key. Agents retry. You don’t want them creating five copies of the same invoice.
Explicit refusal. Tools return structured refusal responses when authorisation fails or input is malformed. Agents learn from structured refusals; they don’t learn from opaque 500s.
“What you see is what they get” tools. A whoami-style tool that returns the current principal, tenant, and effective permissions. Agents can use this to self-correct. Auditors can use it to verify isolation.
The staging MCP endpoint. Same server, staging data, staging auth. Used for eval and red-team. Never exposed to production agents. Never connected to production systems.
How to evaluate an MCP server before you call it done
If you’re about to put an MCP server into production, check every item below. Missing any of these is not an “we’ll fix it in phase two”, it’s a blocking issue.
- Every tool has typed input, typed output, and a description useful to a model.
- Every call carries a principal that can be traced to a real identity.
- Authorisation is enforced at tool, argument, and row levels.
- Every call is logged with principal, args (redacted where needed), result, duration, and cost.
- Rate and cost limits are enforced per principal and per tenant.
- The server rejects unauthenticated calls, malformed inputs, and unsupported tool invocations with structured errors.
- Red-team prompts cannot cause the server to reach another tenant’s data.
- Timeouts, retries, and idempotency are defined for every write tool.
- A runbook exists, and an on-call engineer who isn’t you has read it.
- Staging is identical to prod in shape and completely isolated in data.
When to build, when to buy, when to wait
You have three options for every enterprise MCP need:
Build custom. You get exactly what you need, shaped to your auth, tenancy, data, and audit. Cost is engineering time. Pick this when: the underlying system matters to you, public MCP servers don’t exist or don’t meet your security posture, or you need tight schema control.
Use a vendor-provided MCP server. Many enterprise app vendors are shipping their own, SAP, Dynamics, Salesforce, Atlassian are all in progress. Cost is licensing and vendor lock-in to a degree. Pick this when: the vendor’s surface matches your needs, their auth model is compatible with yours, and you’re happy with their update cadence.
Wait. MCP is young. The 2026 roadmap addresses several gaps, gateway behaviour, transport scalability, configuration portability. Pick this when: your use case is non-urgent, and current gaps materially affect you. (Honestly, this option is shrinking, most gaps have workarounds, and waiting means watching competitors ship.)
At SyncBricks we usually run a mix: vendor-provided servers where they fit cleanly, custom where they don’t, and careful gateway design to make the mix invisible to downstream agents.
The commercial case, in one paragraph
For the exec sponsor, the MCP pitch is: one governed integration works across every current and future AI model, drops integration cost for every subsequent agent you build, reduces vendor lock-in, and produces the audit trail your compliance team needs. Cost is a three-to-eight-week build per server, priced at A$25k per single-system server. Compare that against the alternative, bespoke integrations per model, multiplied by every vendor change. The economics are not close.
What to do next
If you are starting from zero: begin with a scoped discovery. Pick two or three high-priority internal systems your agents need to reach. Audit your SSO and identity substrate. Get the stakeholder map clean. Produce an architecture brief and a prioritised server backlog.
If you are mid-build: audit the server you have against the ten-point evaluation checklist above. Most problems are caught and fixed cheaply before go-live. Caught after, they’re expensive.
If you have MCP servers in production already: pressure-test them against the seven-layer stack. Especially layers 2, 3, and 6. This is where I most often see retrofits in 2026.
Building or scaling enterprise MCP? We run MCP server development engagements, from 2-week discovery to production-grade server build to enterprise platform programmes. Or read the full AI Factory playbook for how MCP fits into the broader agent-deployment stack.