A language model on its own is a closed box: it can only produce text from what it already knows. To be genuinely useful — to check today’s weather, query your database, edit a file — it has to reach outside itself and use tools. The problem is that every tool has its own API, and wiring each model to each tool by hand doesn’t scale. The Model Context Protocol (MCP) is the fix: a single, open standard for connecting an AI host (the app the model runs in) to servers that expose tools, data (“resources”), and prompts. Think of it as a USB-C port for AI — instead of a custom cable per device, tools speak one protocol and any MCP-aware host can use them. The loop is always the same: the host connects to servers and discovers the tools they advertise (each with a name, description, and a JSON schema for its arguments); the model reads the user’s request and the available tools and decides which tool to call and with what arguments; the host relays the call to the right server, which executes it and returns a result; and that result flows back into the model’s context so it can answer — or call another tool. Step through a real request below and watch the whole discover → call → result → answer cycle.
host ↔ servers · tools advertised with schemas · model decides the call · server executes · result flows back
host / client
The AI application the model runs in (e.g. an IDE or chat app). It connects to MCP servers on the model’s behalf.
server
A program that exposes tools, resources, and prompts over MCP. One server might wrap a database; another, the filesystem.
tool
An action the model can invoke, advertised with a name, description, and a JSON schema describing its arguments.
resource
Read-only data a server exposes (a file, a record, a document) that the host can pull into the model’s context.
mcp.js — discover, call, result, answer
Ready
A user asks the host to check Tokyo’s weather and save it to notes. The host talks to two MCP servers. Press Next to walk the flow: discover the tools, let the model choose a call, run it on the server, and feed the result back — until the model can answer.
0
step
0
tools discovered
0
tool calls
How it works
MCP matters because it turns an N×M integration problem into an N+M one. Before a shared protocol, connecting m AI applications to n tools meant potentially m×n bespoke integrations, each re-implementing auth, schemas, and error handling. With MCP, a tool author writes one server and every MCP-aware host can use it; a host author implements the protocol once and gains access to the whole ecosystem of servers. Architecturally it’s a clean client–server design carried over a simple JSON-RPC message stream (over stdio for a local server, or HTTP for a remote one). A server advertises three kinds of capability: tools (actions the model can invoke — the model-controlled part), resources (read-only data the host can attach to context — application-controlled), and prompts (reusable templates a user can invoke). The crucial design choice is that the model proposes tool calls but the host mediates them: the host decides which servers to connect, can require human approval before a tool with side effects runs, and enforces permissions — which is exactly where the security thinking lives, because a tool result flows back into the model’s context and a malicious server or a poisoned document could try to steer the model (prompt injection). In practice a single agent turn may loop through several tool calls — call a search tool, read a resource, call a write tool — each following the same discover-if-needed → call → result cycle you can step through here, with the model deciding after each result whether it has enough to answer or needs another call. This standardization is why the same set of tool servers can back many different assistants, and why “add a capability to your agent” increasingly means “point it at an MCP server” rather than writing a custom integration.
1
Connect and discover tools
The host connects to the MCP servers and asks each what it offers. The servers advertise their tools — here get_weather and append_note — each with a description and a JSON schema for its arguments. Now the model knows what it can do.
2
The model chooses a call
Given the user’s request and the discovered tools, the model decides to call get_weather with the argument city="Tokyo". It proposes the call; the host mediates it (and could require approval for tools with side effects).
3
The server executes, result returns
The host routes the call to the weather server, which runs it and returns a structured result (18°C, cloudy). That result flows back into the model’s context — the model can now use it or make another call.
✓
Loop, then answer
The model calls append_note to save the result, the notes server confirms, and with everything it needs the model writes its final answer. One protocol handled discovery, both calls, and both results — no bespoke integration.
MCP is
a standard tool protocol
Server exposes
tools · resources · prompts
Model
proposes tool calls
Host
mediates + enforces
The code
# The MCP loop the host runs for the model
tools = []
for server in connected_servers:
tools += server.list_tools() # discovery: name, description, schemawhile True:
step = model.decide(user_request, context, tools)
if step.is_final_answer:
return step.text # model has enough — answer
result = route(step.tool_call) # host calls the right server
context.append(result) # result flows back into context# loop: the model may now call another tool or answer
Quick check
1. What problem does the Model Context Protocol (MCP) solve?
MCP is a single open standard for connecting an AI host to servers that expose tools, resources, and prompts. It turns an N×M integration problem (every app wired to every tool) into N+M: write one server and any MCP-aware host can use it — like a USB-C port for AI tools.
2. In the MCP flow, who decides which tool to call, and who actually runs it?
The model reads the request and the discovered tools and proposes a call with arguments. The host mediates — it can require approval for side-effectful tools and enforce permissions — then routes the call to the right server, which executes it and returns a result.
3. How does a tool’s result get used after the server runs it?
The result returns through the host into the model’s context. The model then decides whether it has enough to answer or needs another tool call — a single agent turn often loops through several calls before producing a final answer.
FAQ
What is the Model Context Protocol (MCP)?
An open standard for connecting AI applications to external tools, data, and prompts. A host (the app the model runs in) connects to MCP servers, each exposing tools (actions), resources (read-only data), and prompts (templates). The model discovers tools, proposes calls with arguments, and the host routes them to servers that execute and return results. It’s often called a USB-C port for AI: one protocol instead of a custom integration per tool, so any MCP-aware host can use any MCP server.
What is the difference between tools, resources, and prompts in MCP?
The three capabilities an MCP server exposes, differing in control. Tools are actions the model can invoke (call an API, write a file) — model-controlled. Resources are read-only data (a file, record, document) — application-controlled, so the host decides what to attach to context. Prompts are reusable templates/workflows — user-controlled, invoked explicitly (e.g. a slash command). This separation keeps the security model clear: the model proposes actions, but data and user intent are governed by the host and user.
How is MCP different from regular function calling?
Function calling is a model capability — the model emits a structured request to call a function you define — but you still implement, host, and wire up each function per application. MCP is the layer above: a standard protocol and transport for exposing and discovering tools across applications, so a tool built once as an MCP server works in any MCP-aware host without re-integration. Function calling is how the model expresses it wants a tool; MCP is how tools are packaged, discovered, permissioned, and connected. They’re complementary.
What are the security considerations with MCP?
The central risk is that tool results flow back into the model’s context, so a malicious server — or a poisoned document returned as a resource — can attempt prompt injection: hiding instructions in data to steer the model into unintended actions (exfiltration, destructive calls). That’s why MCP puts the host in charge of mediation: it decides which servers to trust, can require human approval before side-effectful tools run, and enforces permissions. Good practice: connect only to trusted servers, treat tool outputs as untrusted input not commands, sandbox servers, and keep a human in the loop for consequential actions.