Model Context Protocol (MCP): Connecting LLMs to Tools and Data

The Problem MCP Solves

LLM applications are only as useful as the tools and data they can reach: your database, the file system, a search API, an internal service. Before any standard existed, every team wired these up ad hoc — custom glue code per model, per tool, per app. With M models and N tools you drifted toward M×N bespoke integrations, none reusable.

The Model Context Protocol (MCP) is an open standard that turns that into M+N: tools expose their capabilities once via an MCP server, and any MCP-capable client can use them. Think of it as a common port — a "USB-C for AI applications" — between models and the outside world.

If you're building agents, read this alongside Multi-Agent LLM Systems and Agent Context Engineering.

The Architecture

MCP uses a client–server model with three roles:

• Host — the LLM application the user interacts with (an IDE assistant, a chat app, an agent runtime).
• Client — lives inside the host and maintains a 1:1 connection to a server.
• Server — a lightweight process that exposes capabilities: a database server, a GitHub server, a filesystem server.

Communication is JSON-RPC over a transport — stdio for local servers (the host launches the process directly) or HTTP with Server-Sent Events / streamable HTTP for remote servers. A host can connect to many servers at once, composing capabilities from each.

The Three Primitives

MCP servers expose capabilities in three flavors, and the distinction matters:

1. Tools (model-controlled)

Functions the model can decide to call — search_orders, create_ticket, run_query. Each has a name, description, and JSON Schema for its inputs. This is the same idea as function/tool calling, standardized so it's portable across hosts. The model chooses when to invoke them.

2. Resources (application-controlled)

Read-only data the host can load into context — a file, a database record, a document. Identified by URI. Resources are for providing information, not taking actions, and the application decides what to surface.

3. Prompts (user-controlled)

Reusable, parameterized prompt templates a server offers — e.g. a "summarize this PR" workflow — usually surfaced to the user as slash commands or menu items.

This tri-fold split (who's in control: model, app, or user) is the conceptual core of MCP and what makes it more than "portable function calling."

Why It Caught On

• Write once, reuse everywhere. Build an MCP server for your internal API and every MCP-capable assistant can use it — no per-app rework.
• Decouples tools from models. Swap the underlying model without touching integrations.
• Ecosystem. A growing catalog of prebuilt servers (databases, cloud providers, dev tools) means you often integrate by configuration, not code.
• Dynamic discovery. Clients query servers for their capabilities at runtime, so tools can appear or change without redeploying the host.

Security: Read This Before Production

MCP's power is also its risk surface. Treat servers as privileged integrations:

• Tool permissions. A server that can run queries or write files needs the same scrutiny as any service with those rights. Scope credentials tightly.
• Prompt injection via content. If a tool returns attacker-controlled text (a web page, an issue body), that text can try to manipulate the model into misusing other tools. Isolate, validate, and constrain what tools can do.
• Human-in-the-loop for destructive actions. Require confirmation before a model executes irreversible operations (deletes, sends, payments).
• Trust the source. Running a third-party MCP server is running third-party code with whatever access you grant it. Vet it like a dependency.
• Least privilege everywhere. Give each server the minimum scope its job requires.

When to Adopt MCP

Reach for it when:

• You're building agents that touch many tools or data sources.
• You want integrations to work across multiple LLM apps or to survive model swaps.
• A prebuilt server already exists for the system you need (fast win).

You may not need it when:

• You have a single app calling one or two tools — native function calling is simpler.
• Ultra-low latency matters and the extra process hop isn't justified.
• Your integration is a throwaway prototype.

MCP is infrastructure. Adopt it when the reuse and portability pay for the added moving parts — not reflexively.

Key Takeaways

1. MCP standardizes how LLMs connect to tools and data, turning M×N integrations into M+N.
2. Architecture: hosts contain clients that connect to capability-exposing servers over JSON-RPC.
3. Three primitives — tools (model-controlled), resources (app-controlled), prompts (user-controlled).
4. Security is central: scope permissions, guard against prompt injection, gate destructive actions.
5. Best fit for multi-tool agents and cross-app reuse; overkill for a single small integration.

---

Building agents on top of this? See Multi-Agent LLM Systems and Compound AI Systems.