The Model Context Protocol (MCP) is an open protocol that gives AI models a standard, structured way to invoke external tools and retrieve context from external services. Instead of each model provider and each tool vendor agreeing on a bespoke integration, MCP defines a common wire format and calling convention so that any MCP-compatible client can connect to any MCP-compatible server. For teams building or operating AI agents, MCP is significant because it shifts the integration problem from "build a custom connector per tool" to "register a server once and let any capable agent use it."
Why Tool Use Needed a Protocol
AI models have been calling external tools for some time, but the integration patterns have been fragmented. One framework defines tools as JSON schema objects passed in a system prompt. Another uses function-calling conventions specific to a given model API. A third builds its own plugin format. The result is that a tool built for one platform rarely works on another without modification.
This fragmentation creates friction in two directions. For tool builders, publishing to multiple AI platforms means maintaining multiple adapters. For platform operators, adding a new tool means custom integration work even when the tool already exists and works elsewhere.
MCP addresses this by specifying what a tool server must expose — a list of named tools with typed input schemas — and how a client queries and invokes them. The protocol runs over a transport layer (commonly HTTP with server-sent events or standard I/O for local processes) and uses JSON-RPC 2.0 as the message format. A model or agent that understands MCP can, in principle, talk to any MCP server without additional glue code.
For a comparison with the Agent-to-Agent (A2A) protocol and when to use each, see A2A vs MCP: What's the Difference?.
The Structure of an MCP Server
An MCP server is a process that exposes two primary capabilities: tool listing and tool invocation.
Tool listing is how a client discovers what the server offers. The server responds with a schema for each tool — its name, a description written in natural language (which the model uses to decide when to call it), and a JSON Schema definition of the input parameters. This schema-first design matters: the model or orchestrator can validate inputs before sending them, and the server can reject malformed requests cleanly.
Tool invocation is the actual call. The client sends a request naming the tool and providing the arguments as a JSON object conforming to the schema. The server executes the action — querying a database, calling an API, reading a file — and returns a result, also in a structured format.
MCP servers can also expose resources, which are data sources a model can read without performing an action: documents, configuration files, reference data. This distinction between tools (which take actions) and resources (which return data) is useful for governance, because the two carry different risk profiles.
Security Questions MCP Raises
The value MCP delivers — a single protocol that any agent can use to call any server — is also the surface that needs careful management. A few questions deserve attention before you connect agents to MCP servers at scale.
Who controls what an agent can call? Without explicit access controls, an agent that has access to an MCP server has access to every tool on that server. Least-privilege thinking requires that each agent's connection specifies which tools it is permitted to use. If the agent needs one database query tool, it should not also be able to call a tool that writes records or deletes data.
How are MCP server credentials protected? MCP servers often act as proxies to other systems. The credentials those servers hold — API keys, database passwords, OAuth tokens — need to be encrypted at rest and kept out of the calling agent's view. The agent gets a result, not the underlying credential.
What gets logged? Every tool call through MCP is a potential audit event. The arguments passed to a tool may contain PII; the result returned may contain sensitive output. A governance-minded deployment logs each invocation — which agent called which tool with what arguments, what the outcome was, and how long it took — so you have a forensic record if something goes wrong.
Can MCP servers be spoofed or tampered with? An agent that blindly trusts whatever endpoint it is pointed to can be redirected to a malicious server that returns manipulated outputs. Discovery mechanisms for MCP servers should include validation that the registered URL is reachable, that the registrant controls it, and that private or internal network ranges are blocked to prevent server-side request forgery.
MCP in a Governed Agent Deployment
Connecting agents to MCP servers without a governance layer means accepting that tool use happens opaquely. You know the agent ran; you may not know which tool it called, what arguments it passed, or what data came back. At small scale this is manageable. At the scale of a team running dozens of agents against dozens of MCP servers, it is not.
A well-designed governance approach treats each MCP server registration as a governed resource: encrypted auth credentials, per-tool rate limits, a policy gate on each tool call that can allow, deny, require step-up approval, or flag for observation. Each call generates a forensic record that captures the policy decision alongside the call metadata. Agents connect to MCP servers through that governed layer rather than directly, so tool use is visible and controllable without changing the agent's code.
This design separates the protocol (MCP handles the wire format and tool schema) from the governance layer (which enforces who can call what and records the outcome). Neither layer needs to understand the other's internal details. For a practical walkthrough of scoping tool permissions, see Scoping MCP Tool Permissions: Least Privilege for Tools, and for guidance on securing the servers themselves, MCP Server Security: A Complete Checklist covers the key controls.
Choosing and Evaluating MCP Servers
If your agents are consuming third-party MCP servers — public ones or those operated by vendors — a few evaluation criteria apply regardless of what the server does.
Authentication matters. An MCP server that accepts anonymous connections hands off control to whoever finds the endpoint. Prefer servers that require a credential on every call, ideally scoped to the organization or the specific agent rather than a shared long-lived key.
Schema quality correlates with reliability. A server whose tool descriptions are vague or whose input schemas allow arbitrary strings is harder to use safely. Well-typed schemas mean the calling agent or the orchestration layer can validate inputs before they reach the server, catching obvious misuse early.
Logging and versioning signal maturity. A server that does not log calls gives you no visibility into how it is being used. A server with no versioning strategy for its tool list will break calling agents silently when it changes. These are operational signals that the server is maintained with production use in mind.
For the full checklist of what to verify when registering and operating MCP servers in production, see registering and governing MCP servers.
Common questions
Does MCP replace function calling in model APIs? Not exactly. Function calling in model APIs is a mechanism for the model to express its intent to call a tool. MCP is a protocol for how that tool call is actually executed against an external server. The two layers work together: the model uses function calling to decide it wants to invoke a tool, and MCP provides the standard way for the calling infrastructure to reach the tool server and get a result back.
Is MCP only for large deployments? No. Even a single agent calling a handful of tools benefits from MCP if those tools are servers other teams or vendors also operate. The protocol overhead is low, and the interoperability gain — using tools without custom integration code — pays off quickly. The governance layer on top becomes more important as the number of agents and tool servers grows, but the protocol itself is lightweight enough for small setups.
How should sensitive data returned by MCP tools be handled? Tool call results should pass through a content inspection layer before reaching the calling agent. PII or secrets in a tool response can be flagged or redacted before they enter the agent's context window and potentially end up in logs or downstream outputs. See content guardrails for AI agents for details on configuring guardrail policies for MCP tool calls.
What is the difference between an MCP tool and an MCP resource? Tools take actions — they execute queries, call APIs, write data — and carry higher risk because they modify state. Resources return data passively, more like a read-only data source. The distinction matters for governance: tool calls typically warrant stricter rate limits, audit logging, and approval gates than resource reads, which carry lower operational risk.
How do you prevent an agent from calling MCP tools it should not have access to? The safest approach is to apply an explicit tool-level allow-list on each agent-to-server connection, so that even if the server exposes many tools, the agent can only invoke the specific ones it needs. This is the least-privilege principle applied at the MCP layer. For a full discussion, see Scoping MCP Tool Permissions: Least Privilege for Tools.