What MCP Is

You have already used MCP. The Pre-Course Setup had you wire @runsnative/mcp-server into your agent and run a live exercise — that was this module’s lab, run before you knew its vocabulary. This module names what you already did. There is deliberately no new lab here.

The host / client / server model

MCP (Model Context Protocol) is an open protocol connecting agent hosts to capability servers. Three roles, and the names matter because the industry uses them precisely:

The host is the agent application you interact with — Claude Desktop, Claude Code, any MCP-capable agent surface. It owns the conversation and the model.
The client is the protocol endpoint the host runs, one per connected server. You never operate it directly; the host manages it.
The server is the capability provider — in this course, @runsnative/mcp-server (runsnative/packages/mcp-server/), a production npm-published server, not a tutorial toy.

Underneath, the message layer is JSON-RPC 2.0. Every interaction between client and server — listing tools, calling one, reading a resource — is a JSON-RPC request/response pair. The protocol revision this course teaches is MCP spec rev 2025-03-26 — the revision the deployed mukadra-mcp-gateway implements (per the header comment of mukadra/infrastructure/cloudflare/mcp-gateway/src/index.ts), so every claim here is checkable against a running system rather than against documentation alone.

The server-side primitives

An MCP server can expose three kinds of things, and you can observe all of this live by asking your connected agent to list what the course artifact offers:

Tools — callable capabilities with typed schemas. This is the primitive you used in setup, and the one this course spends most of its time on.
Resources — readable context a server exposes: things the host can fetch and place into the model’s context.
Prompts — invocable prompts or procedures the server offers. (Module 0’s table flagged this one: the Mukadra gateway layer maps its “skills” onto MCP prompts, per mukadra/docs/contracts/agent-gateway-framework-contract-v1.md §5.2.)

A server need not implement all three. The course artifact is tool-centric — when you listed its capabilities, what came back was its tool inventory.

What the host does with `tools/list`

Here is the part that makes MCP interesting rather than just another RPC scheme. When the host’s client sends tools/list, the server answers with each tool’s name, description, and parameter schema. The host then hands those to the model — and from that moment, the schemas are the agent’s affordances. The model decides what it can do by reading what the tools say they do.

This has a consequence that sounds odd until you have authored a server, and obvious forever after: tool descriptions are UX for a model. Nobody human reads them in normal operation. A vague description produces an agent that ignores the tool or misuses it; a precise one produces an agent that reaches for it correctly without being told. (Part 2, Module 2.2 turns this observation into a design discipline; for now it is enough to notice that the text you saw when listing tools was written for your agent, not for you.)

When a protocol earns its existence

Why does MCP deserve to exist at all? The honest economic answer: a protocol earns its place when it converts N bespoke integrations into one standard one.

Without MCP, every capability provider writes a custom integration for every agent host it wants to reach — N providers × M hosts. With MCP, a provider implements one server, and every MCP-capable host can connect to it; a host implements one client, and every MCP server is reachable. You experienced this directly: nothing in @runsnative/mcp-server knows which host you used in setup, yet the integration worked with a one-block config.

Keep this framing — it cuts both ways. The same logic that justifies MCP when you don’t control both ends tells you when a plain API is the better choice because you do. That decision framework is Module 1.4’s whole subject.

Trace it end to end

Close the module the way the outline prescribes: trace one real call all the way through. Ask your agent to run the artifact’s list_components tool and account for every layer:

Config block — your MCP client config names the server and how to start it (the README’s quick-install block you pasted in setup).
Host spawns the server — on session start, the host launches @runsnative/mcp-server and its client performs the MCP handshake.
JSON-RPC over the transport — your request becomes a tools/call JSON-RPC message; the server executes list_components and answers in kind. (Which transport carried it — and what your options were — is exactly Module 1.2.)
Result in the agent’s context — the tool result lands in the model’s context, and the agent uses it to answer you.

If you can narrate those four steps and name the host, client, server, and message layer as you go, you have met this module’s exit bar.

What’s next