MCP Servers in Production: What the Model Context Protocol Means for Enterprise

What MCP is, and what it is not

Model Context Protocol is a JSON-RPC-based protocol that defines how an AI model client communicates with an external tool server. The MCP server exposes a list of available tools (functions the AI can call), resources (data sources the AI can read), and prompts (reusable prompt templates). The client discovers these capabilities and can invoke them during a conversation or agentic workflow.

What MCP is: a standardized interface that reduces the per-integration development work for connecting AI models to external systems. Instead of writing custom tool definitions for every AI system that needs to talk to your ERP, you write one MCP server and any MCP-compatible client can use it.

What MCP is not: a security boundary, an access control layer, a guaranteed compatibility guarantee across model versions, or a replacement for thinking carefully about what tools you expose to an AI model. The protocol standardizes the interface. Much of the rest (per-tool authorization, rate limiting, input validation, audit logging) you build yourself.

Where MCP works well

The use cases where MCP produced clear value:

Read-only ERP data access. An MCP server that exposes ERP data queries ("get supplier by name," "list open purchase orders for org," "get invoice status by number") is a clean, reusable integration layer. A server with a couple of dozen read operations is a few days of work, and every agent built afterward can use those operations with no extra integration work. Before MCP, each agent needed its own tool definitions and its own error handling. With MCP, the integration is defined once.

Document corpus access. MCP's resource protocol is well suited to document retrieval: exposing a company's policy documents, product catalogs or knowledge base as resources that an agent can query. The structured resource listing means the model knows what documents exist and can retrieve specific ones by URI rather than performing an open-ended search.

Internal tooling standardization. For teams building multiple AI features, MCP provides a standard way to expose internal tools across those features. An analytics tool that generates reports, a notification tool that sends messages and a calendar tool that checks availability can each be built once as an MCP server and reused across agents and workflows.

The security design that MCP requires

The protocol leaves most of the security design to you. In practice, an enterprise MCP server needs three layers:

1.Client authentication. Who is allowed to connect to this MCP server? The server should require authentication (an API key, an OAuth token or mutual TLS) and reject unauthenticated connections. Do not expose an MCP server to the public internet without authentication regardless of how narrow the exposed tools are.
2.Tool-level authorization. Even authenticated clients should not have access to all tools. An agent that handles customer queries does not need the tool that can modify supplier payment terms. Implement per-tool authorization so you can scope what each client can call.
3.Input validation and output sanitization. The MCP server receives tool call arguments from an AI model. Those arguments came from natural language processing of untrusted user input. Validate every argument against expected types and ranges. If a tool that queries invoices by ID receives a SQL fragment instead of an invoice ID, the server should reject it, not execute it.

MCP servers with write access to enterprise systems are a significant attack surface. If the server can create POs, post journal entries, or modify supplier records, an attacker who compromises the AI model's context (through prompt injection or other means) has a path to making real changes to your ERP. The defense is least-privilege tool exposure: build separate MCP servers for read-only and write operations, and require additional authorization steps for write operations.

Production gaps in the current MCP ecosystem

MCP is a young protocol and the ecosystem is still maturing. Three gaps to plan for:

Long-running tools need care. An MCP tool call is a request and a response. If the tool has to run a long computation, such as a report that takes 30 seconds to generate or a batch operation over thousands of records, the call can time out. The protocol has progress notifications, but client support for them varies. The dependable pattern is a background job plus a status-check tool, and you will need it for any tool that runs longer than a few seconds.

Tool description quality is the bottleneck. The model's ability to correctly use MCP tools depends entirely on the quality of the tool descriptions in the server manifest. Vague or incomplete descriptions lead to the same tool selection errors described in our tool-use article: the wrong tool called, the wrong arguments passed. MCP does not improve this problem. It just standardizes where the description lives.

Client support is uneven. MCP is a standard that any AI client can implement, and each client implements a different subset of it. If you build an MCP server expecting to swap one model or client for another later, verify that with a real test before you commit to the architecture.

Our take

Our current recommendation: Build MCP servers for your enterprise tool integrations now. The standardization benefit is real and the ecosystem will improve. Start with read-only operations. Take the security design seriously from day one, because retrofitting authentication and authorization onto an existing MCP server is harder than building it in. Write your tool descriptions as if the model has never seen your system before, because it has not.

What MCP means for enterprise AI architecture

The most significant implication of MCP for enterprise architecture is that it separates the AI integration concern from the tool implementation concern. Your ERP team builds and maintains the MCP server that exposes ERP operations. Your AI team builds agents that consume MCP tools. Neither team needs to understand the other's domain deeply.

This separation is valuable as AI systems multiply. An organization that will have 5–10 AI agents over the next two years, each needing access to ERP data, document systems and notification tools, gets a lot out of a standardized integration layer. Without it, each agent is a custom integration project. With it, each new agent inherits the organization's existing MCP tool catalog and spends its development time on agent logic, not integration plumbing.