MCP Servers in Production: What Claude's Tool Protocol Actually Means for Enterprise

What MCP actually 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 Odoo instance, 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. Everything else — authentication, authorization, rate limiting, input validation, audit logging — you build yourself.

Where MCP has worked well in our deployments

The use cases where MCP produced clear value:

Read-only ERP data access. An MCP server that exposes Odoo data queries — "get supplier by name," "list open purchase orders for org," "get invoice status by number" — is a clean, reusable integration layer. We built an Odoo MCP server that exposes 23 read operations. It took four days to build. Any AI agent we build for that client can now use those 23 operations without additional integration work per agent. Before MCP, each agent required a custom tool definition with custom error handling. With MCP, the integration is defined once.

Document corpus access. MCP's resource protocol is well-suited for 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, a calendar tool that checks availability — these can be built once as MCP servers and reused across agents and workflows.

4 daysto build an MCP server exposing 23 Odoo read operations — now reusable across all agents for that client

The security design that MCP requires

MCP does not specify authentication or authorization. The protocol assumes you handle these at the server layer. In practice, enterprise MCP servers need three security layers that are not in the protocol specification:

1.Client authentication. Who is allowed to connect to this MCP server? The server should require authentication — API key, 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 relatively new protocol and the ecosystem is still maturing. Three gaps we have hit in production:

No native streaming support for long-running tools. An MCP tool call is a request-response interaction. If the tool needs to run a long computation — a report that takes 30 seconds to generate, a batch operation that processes thousands of records — the protocol has no native way to stream progress back to the client. The call either times out or you have to implement a polling pattern on top of MCP. We have worked around this with background job patterns and status-check tools, but it is a design limitation you hit on 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 we described in our tool-use article — wrong tool called, wrong arguments passed. MCP does not improve this problem. It just standardizes where the description lives.

Multi-model compatibility is theoretical, not tested. MCP is described as a standard that any AI model can implement. In practice, the production implementations are Claude-first and the compatibility with other models is not battle-tested in enterprise environments. If you build an MCP server today with the expectation that you can swap Claude for another model later, verify that assumption with a real test before committing 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 Odoo 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, notification tools, and calendar data — benefits significantly from 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.