What is MCP (Model Context Protocol)? A guide for enterprise teams

What problem does MCP solve?

Before MCP, every AI application needed its own integration for every system it touched. Ten assistants and ten business systems meant up to a hundred bespoke connectors, each with its own way of describing functions, passing credentials and returning results. Anthropic’s launch post described the problem as models “trapped behind information silos and legacy systems”.

MCP replaces that with one protocol. A system is wrapped once as an MCP server, and any MCP-compatible application can discover what it offers and use it. The same server that works with a desktop assistant also works with an IDE or an enterprise agent platform.

MCP does not replace APIs. An MCP server usually sits in front of an existing API and translates it into a form an AI application can discover and call safely. What MCP standardises is the conversation between the AI side and the tool side.

Who created MCP, and who governs it now?

MCP was created at Anthropic by David Soria Parra and Justin Spahr-Summers and open-sourced on 25 November 2024. The launch included the specification and SDKs, local MCP server support in the Claude desktop apps, and an open-source repository of reference servers for systems such as Google Drive, Slack, GitHub, Git and Postgres.

On 9 December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The project’s maintainers keep control of its technical direction. By then, the MCP maintainers reported client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code, among others.

The specification is versioned by date. The current revision at the time of writing is 2026-07-28, which makes the protocol stateless: every request carries its own protocol version and capabilities, and clients can ask a server what it supports with a discovery request.

How does MCP work? Hosts, clients and servers

MCP has three participants. The host is the AI application, such as a chat assistant, an IDE or an assistant platform. For each server it connects to, the host creates an MCP client that keeps a dedicated connection. The server is the program that exposes capabilities, running either locally or remotely.

Messages use JSON-RPC 2.0. Local servers usually talk over stdio, launched as a subprocess on the same machine. Remote servers use Streamable HTTP, which supports standard authentication such as bearer tokens and API keys; the MCP documentation recommends OAuth for obtaining tokens.

• Discover: the client asks the server which protocol versions and capabilities it supports.
• List: the client calls tools/list and receives each tool’s name, description and JSON Schema for its inputs.
• Choose: the host hands those tool definitions to the language model, which decides whether a tool is needed.
• Call: the client sends tools/call with the tool name and arguments, and the server runs the underlying API call.
• Return: the result goes back to the model as context for its next step or final answer.

MCP vs plugins and function calling: what is the difference?

Function calling is the model-side capability: the model returns a structured request to call a function you described. MCP sits one layer out. It standardises how those function descriptions are published, discovered and executed across process and network boundaries, so the same tool works with any compatible host.

Proprietary plugin systems solved a similar problem for one product at a time. MCP’s advantage is portability: a team that wraps an internal system as an MCP server once can use it from several AI applications instead of rebuilding the integration for each.

Is MCP secure? The risks to control

MCP is a protocol, not a security model. It defines how tools are described and called; whether a call is appropriate is the host’s responsibility. The specification says that for trust and safety there should always be a human in the loop with the ability to deny tool invocations, and that clients must treat tool annotations, such as a claim that a tool is read-only, as untrusted unless they come from a trusted server.

In practice, an MCP server is third-party code with access to your systems, and its tool descriptions and outputs are text your model will read. Treat both accordingly.

• Tool approval: require human approval for any tool that writes, deletes or sends outside the organisation, and do not trust a server’s own description of how risky a tool is.
• Credential handling: store server tokens and API keys encrypted, scope them to one tenant or team, prefer OAuth where the server supports it, and never put secrets in prompts.
• Least privilege: give the server a dedicated service account with only the permissions its tools need.
• Prompt injection: tool descriptions and tool results can carry instructions aimed at the model; treat them as data.
• Supply chain: check who maintains a server, how it is updated and what it can reach before installing it.
• Audit: record every tool call, its arguments, the approval decision and the result.

How Botify uses MCP

Botify can register any MCP server per tenant by its HTTP endpoint. If the server needs an API key, the key is sealed in Botify’s credential vault with AES-256-GCM and is never returned by the API. Each registered server’s tools are namespaced to that registration, so two tenants’ servers never collide.

Discovered tools join the same catalogue and policies as the built-in connectors, but Botify does not trust the server’s own metadata: every MCP tool starts at risk level write with approval mode always, meaning each call waits for an authorised person, until an admin reviews that specific tool and relaxes it. Botify can also expose an agent’s tools as an MCP endpoint, and calls through it pass the same policy and approval checks.

Can I connect an ERP such as Odoo to an assistant through MCP?

Yes. For Odoo, third-party modules on the Odoo Apps Store and open-source projects publish MCP servers that expose records to AI applications. These are maintained by their own authors; evaluate them like any vendor software, including licence, maintenance and the Odoo access rights they require.

Botify connects to Odoo directly, so Odoo itself does not need a third-party MCP server, and its actions follow the same policies, approvals and audit trail as every other system. Other ERPs can be reached through MCP by registering their server with Botify as described above. Botify connects to MCP servers over HTTP, so a server that only speaks stdio must first be hosted behind an HTTP endpoint.

• Create a dedicated ERP user for the integration with the minimum access rights the use case needs.
• For an ERP reached through MCP, register the server and review each discovered tool before relaxing its approval.
• Relax only read tools, such as searching records, once reviewed; keep create, update and delete tools on approval.
• Test with real questions in a sandbox database before pointing the assistant at production.