AI Glossary

MCP

Agentic AIPublished By Simon Budziak

MCP, the Model Context Protocol, is an open standard from Anthropic that lets an AI application connect to external tools, data sources, and services through one shared protocol, replacing a custom integration for every pair of client and server with a single specification both sides implement once.

Anthropic introduced MCP in November 2024 to fix a specific integration problem: with N applications and M tools, custom connectors mean N times M separate integrations. MCP turns that into N plus M: a tool is exposed once, behind a server, and any MCP-compatible client, Claude, an IDE, an internal agent, can call it without custom code.

MCP architecture: a host application's client connects over the protocol to multiple MCP servers, each exposing tools, resources, and prompts that front an external system

MCP is not a smarter model. It is the wiring that lets any model reach any tool without a bespoke integration for each pair.

How is MCP actually structured?

MCP defines three roles. A host is the application the user interacts with. It runs one or more clients, each holding a single, stateful connection to exactly one server, which exposes tools, resources, and prompts. Messages follow JSON-RPC 2.0 over stdio, for a local subprocess, or Streamable HTTP, for a remote server. The client discovers a server’s capabilities at connection time, so a host never needs to know them in advance.

MCP vs plain function calling: what changes?

Function calling is a model capability that predates MCP and still underlies it: given tool definitions, the model emits a structured call instead of free text. What MCP adds is everything around that call: discovery, a connection lifecycle, typed resources beyond functions, and a specification both sides implement once and reuse. A tool behind an MCP server works with every compatible client; a tool wired into one agent’s schema works only there.

When should a team build a server, and what changes when they do?

Build one when more than one client needs the capability, or when you want to compose in tools you did not write. Skip it for a single-use script inside one agent’s own codebase. Once a capability is standardized this way it becomes shared infrastructure, versioned and tested once instead of drifting across every AI agent that reimplements it separately, and reachable by dynamic retrieval patterns like agentic RAG without a bespoke connector per source.

What are the real security considerations?

MCP standardizes the wire protocol, not the trust model. Scope credentials to the narrowest permission a tool needs. Put destructive or costly actions, a write, a payment, an external message, behind a human approval step in the host, the same gate any agentic AI system needs for risky actions, rather than trusting the model’s plan unconditionally. Log every call: a semi-autonomous caller with tool access is a new class of actor in your audit trail, not a traditional, fixed-pattern API client.

Frequently asked questions

Is MCP the same as function calling or tool calling?

No. Function calling is the model's ability to emit a structured request for a tool. MCP is the transport and discovery layer around that: a standard way for a client to find out which tools a server exposes and to call them, so the same server works with any MCP-compatible client.

Do I need to build an MCP server for every internal tool?

Only for tools an agent needs to call at runtime and that are worth reusing across more than one client or agent. A one-off script an agent will never call directly does not need one.

Is an MCP server secure to expose to an LLM by default?

Not automatically. MCP defines the protocol, not the permissions. A server should scope credentials narrowly, require explicit user consent for sensitive actions, and log every call, the same way you would treat any API a semi-autonomous caller can invoke.

Summarize this page with

See how this works in a real workflow