Every AI agent project eventually hits the same wall: the model is smart, but it can't see your CRM, your ERP or your internal wiki. Until recently, every connection was a custom integration written for one model vendor and one application. The Model Context Protocol (MCP) changes that by giving AI applications a single, open way to talk to tools and data. This guide explains what MCP is, when it is worth adopting, how to design an MCP server for a business system and how to keep it secure.
What MCP is, in one paragraph
MCP is an open protocol that standardizes how AI applications connect to external data sources and tools. Anthropic introduced it in November 2024 (Anthropic, 2024), and in December 2025 it was donated to the Agentic AI Foundation, a vendor-neutral fund under the Linux Foundation whose platinum members include AWS, Anthropic, Google, Microsoft and OpenAI (Linux Foundation, 2025). The specification is versioned by date; the current revision is 2026-07-28.
The best analogy comes from the spec itself: MCP does for AI tools what the Language Server Protocol did for code editors. Instead of every editor implementing support for every language, each language ships one server and every editor can use it.
How MCP works: hosts, clients and servers
MCP messages use JSON-RPC 2.0 between three roles (MCP specification):
- Host — the AI application the user works in: a chat app, an IDE, an internal assistant.
- Client — the connector inside the host that maintains a connection to one server.
- Server — a service that exposes context and capabilities, for example "our CRM" or "our document store".
Servers offer three kinds of features:
| Feature | Controlled by | Example in a business system |
|---|---|---|
| Tools | The model decides when to call | create_invoice, search_customers, get_stock_level |
| Resources | The application or user chooses | A contract PDF, a price list, a database schema |
| Prompts | The user picks a template | "Summarize this customer's last quarter" |
Clients can offer elicitation: a server can ask the user for missing information mid-task instead of guessing. Optional extensions add long-running tasks and interactive UI elements.
Why it matters for business
Without a standard, connecting three AI applications to five internal systems means fifteen integrations, each with its own auth, error handling and maintenance. With MCP, you build five servers once, and any MCP-compatible host can use them.
The practical benefits we see:
- No vendor lock-in. The same server works with assistants from different model providers, because the protocol is now governed by a neutral foundation rather than a single company.
- One security boundary per system. Access control, logging and rate limits live in the server, next to the data, not in prompts.
- Faster pilots. Once your ERP has an MCP server, a new assistant for sales or support is mostly prompt and UX work.
- Reuse across teams. The finance team's reporting assistant and the support team's agent call the same
get_ordertool.
MCP is not a replacement for good retrieval. For questions over large document collections you still need indexing, hybrid search and reranking, as described in RAG for business. MCP is how the agent reaches that search, and how it reaches structured systems that should never be "guessed" from text.
When MCP is the wrong tool
- A single, fixed workflow. If your code always calls the same three APIs in the same order, a plain function or a workflow engine is simpler.
- Bulk data movement. MCP is designed for interactive, model-driven access, not for nightly ETL of millions of rows.
- Systems without a stable API. An MCP server is a thin, well-designed layer over an existing API. If the API itself is unreliable, fix that first.
Designing an MCP server for a business system
The quality of an agent depends heavily on the quality of its tools. A few rules we follow:
- Design tools around tasks, not endpoints. One
find_customer(query)tool that searches by name, email or tax ID beats three low-level endpoints the model has to chain. - Write descriptions for the model. The tool description is effectively part of the prompt: say what it does, when to use it, and what it returns.
- Return compact, structured results. Twenty relevant fields, not the full 200-field record. Large payloads waste context and money.
- Make side effects explicit. Separate read tools (
get_invoice) from write tools (post_invoice), and require confirmation for anything that moves money or sends messages. - Fail informatively. "Customer not found; try searching by tax ID" helps the model recover; a stack trace does not.
Here is a minimal read-only server in Python using the official SDK's FastMCP helper:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("crm")
@mcp.tool()
def find_customer(query: str, limit: int = 5) -> list[dict]:
"""Search customers by name, email or tax ID.
Use this before any customer-specific action. Returns id, name,
email, segment and open_balance for up to `limit` matches."""
rows = crm_db.search_customers(query, limit=limit) # your existing data layer
return [
{"id": r.id, "name": r.name, "email": r.email,
"segment": r.segment, "open_balance": float(r.balance)}
for r in rows
]
@mcp.resource("crm://customers/{customer_id}/summary")
def customer_summary(customer_id: str) -> str:
"""Plain-text account summary for a single customer."""
return crm_db.render_summary(customer_id)
if __name__ == "__main__":
mcp.run()
Start read-only. Add write tools only after you have logs showing how the model uses the read tools on real questions.
Security: the part you cannot skip
MCP gives a model the ability to read data and take actions, so the security principles in the specification are not optional reading. Hosts must obtain explicit user consent before invoking tools, tool descriptions from untrusted servers must be treated as untrusted, and user data must not be sent elsewhere without consent (MCP specification: security).
In practice:
- Authenticate users, not the agent. For remote servers, the spec defines an authorization flow based on OAuth (MCP authorization). Every tool call should run with the permissions of the human who asked, so the agent can never see more than that person could.
- Only install servers you trust. Researchers have demonstrated "tool poisoning", where a malicious server hides instructions in a tool description that the model follows (Invariant Labs, 2025). Review third-party servers like any other dependency.
- Avoid the lethal trifecta. An agent that has access to private data, is exposed to untrusted content and can communicate externally can be tricked into leaking data (Simon Willison, 2025). Break at least one leg for each workflow.
- Log every call. Who asked, which tool, which arguments, what came back. You will need it for debugging, audits and incident response.
We cover prompt injection and the wider threat model in AI agent security: prompt injection and the OWASP Top 10 for LLMs.
A rollout plan that works
| Phase | Duration | Deliverable |
|---|---|---|
| 1. Pick one system and one use case | 1 week | A list of 20–50 real questions users ask |
| 2. Read-only server | 1–2 weeks | 3–6 tools, OAuth, logging |
| 3. Pilot with 5–10 users | 2–4 weeks | Logged sessions, failure analysis, better tool descriptions |
| 4. Write tools with confirmation | 2 weeks | Actions such as creating tickets or drafts |
| 5. Expand | ongoing | Next system, shared tool conventions |
Measure the pilot like any AI feature: task success rate, tool error rate and how often users have to correct the agent. Our approach to measuring is in How to evaluate LLM applications. If your core system is Odoo, see Integrating AI agents with Odoo for a concrete example.
FAQ
Is MCP only for Claude? No. MCP is an open protocol governed by the Agentic AI Foundation under the Linux Foundation, and it is supported by applications and SDKs from many vendors.
Do I need MCP if I already have a REST API? Your REST API stays. An MCP server is a thin layer on top that describes your API in a way AI applications understand and adds consent, auth and logging suited to agents.
Local or remote servers? Local servers suit developer tools and desktop apps. For business systems shared by a team, use remote servers with OAuth so access is centrally managed and audited.
How long does it take to build one? A read-only server for a system with a decent API usually takes one to two weeks including auth and logging. Most of the effort goes into tool design and testing on real questions.
Sources
- Anthropic (2024). Introducing the Model Context Protocol.
- Linux Foundation (2025). Formation of the Agentic AI Foundation; MCP joins the Agentic AI Foundation.
- Model Context Protocol. Specification, revision 2026-07-28 and Authorization.
- Invariant Labs (2025). MCP security notification: tool poisoning attacks.
- Simon Willison (2025). The lethal trifecta for AI agents.