Model Context Protocol (MCP) Explained

The Model Context Protocol (MCP) is an open standard that defines how AI models connect to external tools, data sources and services. Anthropic introduced it in November 2024, and it has since been adopted by OpenAI, Google DeepMind, Microsoft and thousands of enterprise teams. Instead of writing a custom connector for every pairing of application and system, a tool exposes itself once through an MCP server and any MCP-compliant client can use it. The protocol is built on JSON-RPC 2.0, uses a host, client and server architecture, and organizes capabilities into tools, resources and prompts. It is an integration layer, not a full agent framework, so orchestration, permissions, logging and review remain the responsibility of the team deploying it.

Key concepts

Model Context Protocol

An open standard that defines how AI models connect to external tools, data sources and services, replacing one-off custom integrations with a single shared interface. S4 · zenity.ioS6 · databricks.com

Host, client and server

The host is the AI application and runs an MCP client. Each external integration runs as an MCP server that exposes specific capabilities through the protocol. S4 · zenity.ioS7 · stytch.comS3 · codingscape.com

Tools, resources and prompts

The three primitives of MCP capabilities. They define what an agent can do, what it can read, and how it is instructed. S4 · zenity.io

N×M integration problem

Without a standard, each AI application integrates directly with every external service. MCP has each client and server implement the protocol once, reducing integrations from N×M to N+M. S6 · databricks.com

Agent tools

Functions and services that help an agent act on the world: call APIs, query databases, send messages and run workflows. They turn a text generator into an agent that interacts with live systems. S1 · neo4j.com

How an MCP-enabled agent calls a tool

1. Expose capabilities through MCP serversTeams wrap database lookups, API calls, file reads or automation steps in MCP servers instead of hard-coding them inside the agent.
2. Host application runs an MCP clientThe agent application uses an MCP client to connect to one or more servers. The model does not talk to APIs directly.
3. Client discovers available toolsAt runtime the client queries each MCP server for its available functions or data endpoints and learns their capabilities through structured descriptions.
4. Model decides to invoke a toolWhen a user query needs external information or an action, the model chooses the appropriate tool, and the client calls the server.
5. Server acts as gatekeeperThe server enforces authentication, auditing and authorization for its system, then returns data or performs the action.
6. Log and review the callProduction teams log every tool call, input, output, model decision, review decision and recovery action, with human review for irreversible or costly actions.

Architecture: hosts, clients, servers and primitives

An MCP deployment has three moving parts: host, client and server. The host is the AI-powered application, such as a chatbot, IDE assistant, Claude Desktop or agent, and it runs an MCP client component. Each external integration runs as an MCP server, a lightweight program that exposes specific capabilities over the protocol. Servers can reach local data sources such as files, databases and services, or remote services available through APIs. A host can connect to multiple servers at once. The model does not talk to APIs directly; it goes through the MCP client and server handshake, which structures the exchange. Capabilities are built from three primitives: tools, resources and prompts, which define what an agent can do, what it can read and how it is instructed. The protocol is built on JSON-RPC 2.0, and an AI client can query any MCP server for its available functions or data endpoints before calling them consistently.

Why a standard protocol: from N×M to N+M

Before MCP, every connection between a model and a system such as a CRM, a code repository or an internal database required its own custom-built integration. An organization running several AI applications against dozens of tools could end up maintaining hundreds of one-off connectors, each with its own authentication method, data format and failure mode. Databricks frames this as the N×M integration problem, where N is the number of tools and M the number of clients. MCP requires each client and each server to implement the protocol just once, reducing total integrations from N×M to N+M. A tool exposes itself once through an MCP server, and any MCP-compliant application can connect without additional custom code. Communication works in both directions: models can pull in context, such as a customer record or a file, and trigger actions, such as updating a ticket or sending a message. Anthropic compares MCP to a USB-C port for AI applications.

Scoping tools and securing MCP in production

MCP standardizes the connection, but production success still depends on scoped permissions, logging, evaluation, failure recovery and human review. MCP is an integration protocol, not a complete agent framework, so orchestration, observability and deployment controls remain separate work. The safest workflows separate retrieval, action and review instead of giving one agent broad access to every system. Tool categories carry different risk: web search and retrieval are low to medium risk, while file writes, computer-use and business tools such as email, CRM and ticketing carry medium to high risk because of external effects. Scoping the toolset to the job makes the agent more reliable and predictable. MCP does not enforce authentication, authorization or input validation at the protocol level, so an MCP server is only as secure as the team that built and deployed it. Human review matters most for irreversible, expensive, customer-visible, compliance-sensitive or low-confidence actions.

Custom integrations versus MCP

Timeline

1. 2024-11
   Anthropic introduces the Model Context Protocol as an open-source release.zenity.io

Common pitfalls

• MCP does not enforce authentication, authorization or input validation at the protocol level, so each server must be secured by the team that builds and deploys it.
• Giving one agent broad access to every system is risky. Separate retrieval, action and review, and scope permissions to the job.
• Treating MCP as a complete agent framework is a mistake. You still need orchestration, permissions, observability, evaluation and deployment controls.
• Every new capability creates a new failure path. Tools with external effects, such as email, CRM and computer-use, carry high risk and need approval gates on writes.

Key takeaways

• MCP replaces custom per-tool connectors with one shared client-server protocol, cutting integrations from N×M to N+M.
• It is an integration layer only; orchestration, scoped permissions, logging and evaluation must still be built around it.
• Security is not built into the protocol, so authenticate and authorize at each server and keep human review for high-impact actions.

FAQ

How this page is made. Built from the full text of 8 sources found with the AISA Tavily API (advanced search), refreshed weekly. A language model organizes what those sources state into the blocks above; each block links the sources it draws on, and figures that do not appear in the sources are removed.