What Is the Model Context Protocol and When to Use It

Before MCP, every AI application that wanted to use an outside service needed its own integration with that service. Google Cloud's explainer calls this the "N x M" problem: the number of custom connections grows with the number of AI applications multiplied by the number of tools and data sources (Google Cloud). Databricks describes it the same way, noting that without a standard, "each AI application must integrate directly with every external service" (Databricks).

Anthropic's announcement framed the cost in plain terms: even capable models are "trapped behind information silos and legacy systems," and "every new data source requires its own custom implementation" (Anthropic).

MCP turns that multiplication into addition. Each service gets one MCP server. Each AI application gets one MCP client implementation. Any client can then talk to any server.

Google Cloud also notes that MCP "builds on existing concepts like tool use and function calling but standardizes them." It does not replace the model's ability to call tools. It standardizes how those tools are described, discovered and reached.

The architecture documentation defines three participants (MCP architecture):

• MCP host: the AI application that coordinates everything, such as an editor or desktop assistant.
• MCP client: a component inside the host that maintains a connection to one server.
• MCP server: a program that provides context and capabilities to clients.

The host creates one client for each server it connects to. The documentation's example is Visual Studio Code: when it connects to a monitoring service's MCP server, it creates a client for that connection, and when it also connects to a local filesystem server, it creates a second client.

Servers can run in two places, matching the two transports the protocol defines:

The documentation notes that stdio gives "optimal performance with no network overhead," while Streamable HTTP supports standard HTTP authentication methods, with OAuth recommended for obtaining tokens. Messages on both use the same JSON-RPC 2.0 format.

What a server offers is described by three core primitives:

• Tools: "Executable functions that AI applications can invoke to perform actions," such as file operations, API calls or database queries.
• Resources: "Data sources that provide contextual information," such as file contents or database records.
• Prompts: "Reusable templates that help structure interactions with language models."

Each primitive has list methods, so a client can ask a server what it offers at runtime and get an up-to-date answer. That discovery step is what makes MCP different from hard-coding tool definitions into an application, and, as the security section shows, it is also where much of the risk comes from.

MCP adds a process or a network hop, a server to run, and a connection to manage. That overhead pays off in some situations and not in others. Prefect's guide to choosing between MCP and function calling puts the dividing line clearly: MCP wins "when tools need to be shared, discovered, or governed independently of any single application" (Prefect).

Its decision table, slightly condensed:

Prefect lists specific cases where plain function calling is better: single-application tools, tools generated at runtime from the conversation, latency-sensitive paths where an extra hop matters, and prototypes where you are still finding out whether a tool is useful. MCP is better for multi-client access, portability across models, team-shared tools, and production governance, where a gateway in front of the servers can handle "authentication, rate limiting, audit logging, and access control."

Most teams end up using both. Prefect's example is an incident-response agent. Searching alerts and querying the runbook database are shared capabilities that many agents and people need, so they belong on MCP servers. Formatting the agent's own Slack summary is specific to that agent, so it stays as a function call. Putting it on a server "would add infrastructure overhead for no benefit."

For coding agents, a practical rule follows from this. If a capability is already offered as a well-maintained MCP server by the service you use, connect to it. If you need a small helper for one project, a script the agent can run, described in a skill or a project context file, is often simpler than a server. Build your own MCP server when several tools or teams need the same internal capability, such as querying a company database with access control.

Connecting an MCP server gives text written by someone else a direct path into your agent's context. That is the core risk, and several security teams have documented how it plays out.

Tool poisoning. Invariant Labs described tool poisoning attacks, in which "malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models" (Invariant Labs). Their experiments showed that a malicious server could instruct the model to read sensitive local files and pass their contents along as a tool argument, while the user interface showed only a harmless-looking call. They also found that a malicious server can "override instructions provided by other, trusted servers."

Rug pulls. Datadog's security team describes a server that was approved when it was safe and later updated with new tool definitions the user never saw, a pattern it calls a rug pull (Datadog). Elastic Security Labs defines the same attack as a tool's description or behavior being "silently altered after user approval" (Elastic Security Labs).

Injection through tool output. The OWASP community page on MCP tool poisoning points out that tool responses are often added to the model's context without validation, that internal and external tools often share the same privilege level, and that restrictions written into a system prompt "are enforced only by the LLM's instruction-following, not by backend access controls" (OWASP).

Credentials in configuration. MCP servers hold the keys to the systems they connect to. Datadog notes that improperly stored server configuration files, which typically contain those credentials, can give attackers access to connected systems.

Consent fatigue. Requiring approval for sensitive actions is the right control, but Datadog warns it "can fail if a malicious MCP server inserts a harmful action in between an influx of legitimate ones," and that many users switch on automatic approval to stop the prompts.

None of this makes MCP unusable. It makes each server a dependency with the same trust questions as any package you install, plus one more: it can talk to your model directly.

The recommendations from OWASP and Elastic overlap closely (OWASP, Elastic Security Labs). Combined into one list:

Before connecting a server
[ ] It comes from a trusted source, and someone has read its tool descriptions
[ ] It is on the team's allowlist of approved servers
[ ] Its credentials are scoped to what the task needs, nothing more

While running it
[ ] Local servers run in a sandbox, such as a container, away from your own credentials
[ ] Privileged tools (files, databases, internal APIs) are isolated from external servers
[ ] Access limits are enforced in the tool or server, not only in the system prompt
[ ] Destructive or data-sending actions require human approval outside the model
[ ] "Always allow" and auto-run are off for tools that touch sensitive data

Over time
[ ] Every tool call is logged and the logs are reviewed
[ ] Server versions are pinned, and description changes are reviewed before update
[ ] Unused servers are disconnected

Two of these deserve emphasis. First, enforce limits server-side. OWASP's advice is direct: "Do not rely on system prompt instructions to restrict tool access." Second, keep approvals meaningful. If an approval prompt appears so often that people click through it, reduce what needs approval by narrowing permissions, so that the prompts that remain are worth reading.

Treated this way, MCP gives an agent useful reach into the systems a team already uses, with one well-understood interface for each, and with the same supply-chain discipline you would apply to any other dependency.