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

Q: What's the difference between MCP and function calling?

Function calling is the model capability (emit a structured call, receive a result). MCP is the integration layer that standardizes where those functions come from, how they're discovered, and how they're transported. MCP tools become function definitions when handed to the model.

Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard for connecting AI models to external tools and data. Instead of every AI application writing bespoke integrations for GitHub, Slack, databases, and internal APIs, a service exposes one MCP server, and any MCP-capable client — Claude, IDEs, agent frameworks — can discover and call its capabilities.

MCP is often described as "USB-C for AI": a single connector standard that replaces the N×M problem of wiring every model to every tool. Introduced by Anthropic in late 2024 and since adopted across the industry, it has become the default way to give AI agents real-world capabilities.

TL;DR

MCP standardizes how an AI application (client/host) talks to a capability provider (server) — one protocol instead of per-integration glue code.
Servers expose three primitives: tools (actions the model can call), resources (data the client can read into context), and prompts (reusable templates).
Two main transports: stdio (server runs as a local subprocess) and Streamable HTTP (remote servers, e.g. https://mcp.linear.app/mcp).
The client handles discovery: it lists a server's tools and hands their schemas to the model — the model then calls them like any tool use.
Major services (GitHub, Linear, Notion, Slack, Stripe…) ship official MCP servers; writing your own is a small amount of SDK code.
Treat MCP servers as an attack surface: tool results can carry prompt injection, and a malicious server sees whatever the model sends it.

Quick Example

A minimal MCP server in TypeScript exposing one tool:

Now "what's the status of order ORD-1042?" resolves to a structured tool call against your database — no custom integration code in the client.

Core Concepts

The Architecture

The host is the AI application; it runs one client connection per server.
Servers are small programs (any language) exposing capabilities.
On connect, the client calls tools/list, resources/list, etc., and presents what it finds to the model.

The Three Primitives

Tools dominate in practice: they carry a name, a description, and a JSON Schema for inputs — exactly the shape LLM tool-calling APIs expect, which is why the bridge is so thin.

💡 Tool descriptions are prompt engineering. The model chooses tools based on the description text — say when to call it ("Call this when the user asks about order status"), not just what it does. See Prompt Engineering.

Transports

Remote servers authenticate with OAuth 2.1 bearer tokens — note that a service's MCP OAuth token is generally not the same credential as its REST API key.

Using MCP

In AI Applications (the API side)

Anthropic's Messages API can connect to remote MCP servers directly — the API layer makes the MCP connection server-side, so your code just declares the server and its toolset:

Both halves are required: every server in mcp_servers must be referenced by an mcp_toolset entry in tools. Agent frameworks (Claude Agent SDK, LangChain, OpenAI Agents SDK) ship equivalent MCP client support.

In Developer Tools

Claude Code, Claude Desktop, Cursor, VS Code, and most agentic IDEs are MCP hosts — configure a server once and every conversation can use it. Typical team setup: a Postgres server for schema-aware queries, the GitHub server for PRs and issues, and one internal server wrapping the company's own APIs.

Building a Server: Design Guidance

Fewer, higher-level tools beat many granular ones. search_orders(query) outperforms exposing 15 raw CRUD endpoints — the model composes less and errs less.
Return structured, compact results. Huge JSON blobs burn context; filter and summarize server-side.
Validate inputs like a public API. The model generates arguments; treat them as untrusted user input (SQL injection rules apply to generated SQL too).
Scope credentials minimally. The server acts with whatever permissions its token carries — an agent bug becomes a data-loss bug if the token allows it.

Security Considerations

MCP moves real capabilities into the model's reach, which makes its threat model worth taking seriously:

Prompt injection via tool results. A tool that returns web content, tickets, or emails can carry adversarial instructions ("ignore previous instructions and..."). The host must treat tool output as data, and sensitive actions should require human confirmation.
Malicious or compromised servers. A server sees every argument the model sends and controls what comes back. Install servers like you install dependencies: from trusted sources, pinned, reviewed.
Tool shadowing / rug pulls. A server can change its tool descriptions after you've approved it. Clients increasingly pin and diff tool definitions.
Confused deputy. An agent with both a "read customer data" tool and a "send email" tool can be induced to combine them. Separate high-risk capabilities behind approval gates.

The same API security fundamentals — least privilege, input validation, audit logging — apply on both sides of the protocol.

MCP vs Plain Tool Calling

They compose rather than compete: your agent might define two custom tools inline and pull thirty more from MCP servers. Under the hood the model sees one merged tool list either way.

Common Mistakes

Exposing a Raw API 1:1

Wrapping every REST endpoint as a tool gives the model 80 confusing options. Design tools around user intents, not your API's shape.

Trusting Tool Output as Instructions

Rendering a fetched webpage or ticket into context without treating it as untrusted input is how agents get hijacked. Guard sensitive tools with confirmation, and prefer allowlisted actions.

Unbounded Result Sizes

A query_database tool that can return a million rows will, eventually. Cap and paginate results server-side — context windows and bills both thank you.

Assuming REST Credentials Work for MCP

Hosted MCP servers (Notion, Linear, GitHub) typically use their own OAuth flow. A service's REST API key usually won't authenticate its MCP endpoint.

FAQ

Is MCP tied to Claude?

No — Anthropic created it, but it's an open specification with an open-source SDK ecosystem (TypeScript, Python, Java, C#, and more), and it's supported by clients and platforms well beyond Anthropic's. That neutrality is why services standardized on it.

Do I need MCP for a simple agent?

If your agent needs three tools you control, plain tool calling is simpler. MCP pays off when integrations should be reusable across apps and teams, or when you want to consume the growing catalog of official servers instead of writing integrations.

What's the difference between MCP and function calling?

Function calling is the model capability (emit a structured call, receive a result). MCP is the integration layer that standardizes where those functions come from, how they're discovered, and how they're transported. MCP tools become function definitions when handed to the model.

How do I find existing MCP servers?

Official registries and directories list servers from major vendors (GitHub, Notion, Stripe, Cloudflare, and hundreds more), and most developer platforms document their server's URL and auth. Check the service's own docs first — official servers beat community ones for support and security.

Can MCP servers run in production backends?

Yes — remote Streamable HTTP servers are ordinary web services: deploy, scale, and monitor them like any API, with OAuth in front and rate limiting as usual.