Vibe Engines Learn
Vibe Engines
Handbooks  /  Model Context Protocol
AI Engineering~11 min readIntermediate
Deep Dive

The Model Context Protocol,
the USB-C for AI tools.

Every agent needs to reach the outside world — files, APIs, databases, other apps. MCP is the open standard that lets any model talk to any tool through one common port, instead of a snarl of one-off integrations. Here's what it is, how it works, and when to reach for it.

01

The M×N integration problem

Give a model tools and it becomes an agent — it can search, read a file, query a database, send a message. But every one of those connections used to be bespoke glue: this model's tool-calling format, that API's auth, a custom adapter in between. With M AI apps and N tools, you're on the hook for M × N integrations, each maintained by hand.

→ The core idea

MCP turns M × N into M + N. Each app learns to speak MCP once; each tool exposes an MCP server once; everything interoperates. It's the same move USB made for peripherals — a common port, so the laptop doesn't need a driver for every device.

Announced by Anthropic in late 2024 and adopted broadly since, MCP is an open protocol: not tied to one model vendor, one language, or one product. That neutrality is the whole point — an ecosystem only forms if the standard belongs to everyone.

02

Host, client, and server

MCP has three roles. The host is the AI application the user interacts with (a chat app, an IDE agent, a desktop assistant). Inside it, an MCP client manages a connection to each MCP server — a separate process or service that exposes some capability. One host can hold many clients, each wired to a different server.

One host, many servers
HostThe AI app the user sees — owns the model and the conversation.
ClientA connector inside the host, one per server, speaking MCP.
ServerAn external provider of tools / data / prompts — a filesystem, GitHub, a database, your own service.

Under the hood it's JSON-RPC 2.0 messages over a transport — typically stdio for a local server the host launches, or HTTP with Server-Sent Events for a remote one. The wire format is deliberately boring; the value is in the shared vocabulary on top.

03

The three primitives

Every MCP server exposes some mix of three capability types — the nouns of the protocol.

What a server can offer

Tools

  • Functions the model can call
  • Take actions with side effects
  • e.g. create a file, send an email
  • Model-controlled

Resources

  • Read-only data the app can load
  • Files, rows, API responses
  • Addressed by URI
  • App-controlled

Prompts are the third: reusable, parameterized prompt templates a server publishes and the user can invoke (a "/summarize" command, a code-review template). The split matters — tools are chosen by the model, resources are supplied by the app, and prompts are triggered by the user. Keeping those lines clear is also a security boundary.

→ Mental model

A tool is a verb the model may use; a resource is a noun the app may read; a prompt is a shortcut the user may run. Same server, three different kinds of capability, three different controllers.

04

How a session works

The lifecycle is short and predictable. The client and server first initialize, exchanging protocol versions and capabilities — a negotiation so each side knows what the other supports. Then the client discovers what's on offer (tools/list, resources/list, prompts/list) and presents the tools to the model.

Connect → discover → call
1initialize — agree on version and capabilities.
2tools/list — the client learns the available tools and their JSON schemas.
3model decides — it emits a tool call in its own format; the client maps it to MCP.
4tools/call — the server runs it and returns a result.
5observe — the result goes back into the model's context, and the loop continues.

Because discovery happens at runtime, tools can appear and disappear without redeploying the host — plug in a new server and its capabilities show up. That dynamic quality is what makes MCP feel less like an API client and more like plugging in a device.

05

When to use it — and the sharp edges

Reach for MCP when you want your agent to use tools that others can build and share, or to reuse a growing ecosystem of servers instead of writing every integration yourself. For a single hard-coded tool in one app, a direct function-calling schema is simpler; MCP earns its keep once integrations multiply or need to be swapped without a redeploy.

→ Security is not free

MCP is a transport, not a safety layer. A server can expose dangerous tools, and any content it returns is untrusted input that can carry a prompt injection. The usual defenses still apply: least-privilege tools, human approval for risky actions, sandboxed execution, and treating a third-party server as you would any external dependency you didn't write.

MCP is one station in building a real agent runtime — the connective tissue between the model and the world. The rest of that runtime (the loop, context, memory, evals, cost) is the AI Harness roadmap.

Put MCP to work
Tool Schema Designer — design a tool Lab — the agent loop MCP feeds Lab — the injection surface Design an AI Agent The AI Harness Roadmap
Frequently asked

Quick answers

What is the Model Context Protocol?

An open standard for how an AI app connects to external tools, data, and prompts. A host connects to MCP servers that expose capabilities through one uniform interface, so any MCP-compatible model can use any MCP server.

What problem does MCP solve?

It turns M×N bespoke integrations into M+N: each app speaks MCP once, each tool exposes a server once, and they interoperate — decoupling the model from the integrations like a common port decouples a laptop from its peripherals.

What are the primitives?

Tools (functions the model can call), Resources (read-only data the app can load), and Prompts (reusable templates the user can invoke). The client discovers them at connection time and offers the tools to the model.

Is MCP a security risk?

MCP is transport, not a safety guarantee. Servers can expose powerful tools and return content that carries a prompt injection, so least-privilege tools, human approval, sandboxing, and treating server output as untrusted all still apply.

Model Context Protocol (MCP) · AI Engineering · Vibe Engines · 2026
Finished this one? 0 / 29 Handbooks done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

AI Agents & Tools

More Handbooks

Explore more from Vibe Engines

Roadmaps →
System Designs →
AI System Designs →
Algorithms →
Labs →
Paper Breakdowns →