--- title: "Model Context Protocol: how AI apps plug into tools and data" description: "Watch JSON-RPC messages flow between an MCP host and its servers as the client discovers tools, invokes them, and streams results back to the model." published: 2026-04-24 updated: 2026-06-14 canonical: https://protrailblazer.com/posts/model-context-protocol-explained/ tags: [mcp, ai-agents, tool-use, protocol, demo] --- # Model Context Protocol: how AI apps plug into tools and data **Answer:** Model Context Protocol is a small open standard that lets an AI app ask a set of tiny programs called MCP servers what they can do, then call those tools during a conversation. It turns a model that only knows words into an app that can read your files, query your database, and post to Slack without a custom integration per service. The interactive below shows a Model Context Protocol host talking to six local servers on an isometric pixel grid. Auto-loop fires realistic prompts on a timer. Toggle any server off in the lower-right panel and watch the animation route around it. Drag empty space to rotate, scroll or pinch to zoom, and tap any cube to see the tools it exposes. *Interactive demo: [open the mcp protocol demo](https://protrailblazer.com/demos/mcp-protocol/)* ## What does the demo show? The red cube in the middle is the MCP host, the process that runs the AI model and speaks the protocol. The six cubes around it are MCP servers. Each server is a small program that advertises a handful of tools. The gray cube off to the side is you, the user, sending a prompt into the host. The tiny red cubes hopping along the grid are JSON-RPC messages. When the user (or the auto-loop) fires a prompt, the host decides which servers can answer, dispatches a `tools/call` to each, waits for a result, then replies back up to the user. The host flashes on every message it handles. Each server flashes when one of its tools runs. A few things to try in the demo: - **Toggle servers off.** Disable Slack or Weather in the lower-right panel. Prompts that needed them now return a no-servers response from the host, and the dotted edge to that server dims out. - **Fire a compound prompt.** Click "Summarize PRs to Slack" or "Free time today?" The host dispatches to two servers in parallel and only replies to the user after both have answered. - **Rotate and zoom.** Drag the grid to spin the view, scroll to zoom, or pinch on a phone. The cubes stay legible at any angle so you can watch messages from a different side. - **Crank the fire rate.** Drop it to under a second and multiple tool calls overlap in flight. That is what a busy agent session actually looks like. ## How does MCP work? Every MCP connection follows the same lifecycle. On startup the host opens a stream to each server and sends an `initialize` request. The server answers with its protocol version and a capability list. The host then calls `tools/list`, `resources/list`, and `prompts/list` to learn what that server actually exposes. At inference time the host builds a combined tool catalog from every connected server and hands it to the model. When the model decides to call a tool, the host routes a `tools/call` JSON-RPC request to the correct server, awaits the response, and feeds the result back into the next turn. If a server is toggled off, it vanishes from the catalog and the model cannot use it at all that turn. The demo reflects this: disabled servers never receive a request. Transport is either **stdio** (the server runs as a child process of the host and they exchange JSON-RPC messages over pipes) or **HTTP with server-sent events** (the server runs out of process, often remote). The wire format is JSON-RPC 2.0 in both cases, so the host needs no per-server client code. That is the whole point: add a new server, and no client changes. Servers are isolated processes on purpose. The host runs the model and holds any API keys. A server only sees the arguments it was handed and returns a result. A crashed or malicious server can fail its own call, but it cannot reach into the host's process memory or read the user's prompt history. That separation is the protocol's security story. Latency is the other design constraint. Every enabled server is a potential round trip per turn, and each tool call waits on the real external system behind it (a database, an API, a disk read). Production agent workflows usually whitelist a small default server set and enable the heavy ones only for the tasks that need them. MCP is the connective tissue behind most tool-using [agent workflows](https://protrailblazer.com/posts/agentic-workflow-smb-guide): the model works out what it needs as it [generates its response](https://protrailblazer.com/posts/how-llms-generate-text), and the protocol gives it a uniform way to reach the tools that can deliver. ## Frequently asked questions ### What is the Model Context Protocol? The Model Context Protocol (MCP) is a small open standard that lets an AI app discover and call external tools at runtime. The app, called the host, asks each connected MCP server what it can do, then invokes those tools during a conversation over JSON-RPC. It gives a model a uniform way to read files, query databases, or call APIs without a custom integration per service. ### What problem does MCP solve? Before MCP, every AI app needed bespoke glue code for each tool or data source it wanted to use. MCP replaces that with one protocol: write a server once, and any MCP-capable host can use it with no client changes. It standardizes the connection between models and the outside world the way a common port standardizes hardware. ### What are MCP tools, resources, and prompts? They are the three primitives a server can expose. Tools are actions the model can take, such as sending a message or running a query. Resources are content the model can read, such as files or records. Prompts are templated workflows the server offers. The host discovers all three with list calls when it connects. ### Is MCP secure? The protocol's security comes from process isolation. The host runs the model and holds any API keys, while each server is a separate process that only sees the arguments it was passed and returns a result. A crashed or malicious server can fail its own call but cannot reach into the host's memory or read the user's prompt history. You still vet which servers you enable. ## Key takeaways - MCP is a discovery protocol, not a hardcoded API. The host asks each server what it offers at runtime, which is why a new server plugs in without any client code changes. - The host runs the model, servers run the integrations. They talk over JSON-RPC on stdio or HTTP, so a failing or malicious server cannot reach into the host's process. - Tools, resources, and prompts are the three primitives. Tools are actions the model can take, resources are content it can read, prompts are templated workflows it can invoke. - Every enabled server adds a potential round trip per turn. Good agent workflows keep the active set small and enable the expensive servers only when the task actually needs them.