Every technical course faces the same opening problem: the field’s words and the practitioner’s words are not the same set. This course is unusually exposed to that problem, because it teaches an open industry protocol (MCP) and the proprietary layer one organization built around it (the Mukadra agent gateway). If you cannot tell which words travel and which words are local, everything after this module gets harder. So before any mechanism, this module does one thing: it names the universal concepts the course is about, gives our term for each, and tells you honestly how portable each term is.
Where these names come from
A note on sources, because this course practices what it teaches about provenance. The holdings shared lexicon (kukamanga/docs/governance/shared-lexicon-v1.md) governs vocabulary across the organization, but its v1 covers the design-system domain only — the agent-primitives terms below are not yet lexicon entries. The interim source of truth for them is the agent gateway framework contract (mukadra/docs/contracts/agent-gateway-framework-contract-v1.md), cited per row in the table. Extending the lexicon to this vocabulary is an active reconciliation campaign (JUNE-146 design lane, “Agents Are APIs”); when it lands, this module re-syncs — that commitment is recorded in the source outline’s Freshness Covenant.
The move
You arrive at this module with the course artifact already connected — the Pre-Course Setup had you install @runsnative/mcp-server and run a live exercise before you knew the vocabulary for what you were doing. Now make the move that anchors everything:
With the server connected, ask your agent host to list the server’s tools, then run one, and then name every layer that call just crossed.
The rest of this module is the naming. Keep your own session open as you read; every row in the table below is observable in what you just did.
The vocabulary
| Universal concept | Our term | Portability of the word |
|---|---|---|
| Open protocol connecting agent hosts to capability servers | MCP (Model Context Protocol) | Industry standard — open spec, travels everywhere |
| A callable capability with a typed schema | tool | MCP-standard — travels across hosts |
| Readable context a server exposes | resource | MCP-standard |
| Invocable prompt/procedure a server offers | prompt (MCP) / skill (ours) | “prompt” travels; skill is our gateway-layer term — the gateway maps skills onto MCP prompts (mukadra/docs/contracts/agent-gateway-framework-contract-v1.md §5.2) |
| The wire protocol a service speaks | transport binding | Ours (mukadra/docs/contracts/agent-gateway-framework-contract-v1.md §5); industry says “transport” |
| The four capability surfaces of an agent | endpoint families — tools · skills · surfaces · intent | Mukadra coinage (mukadra/docs/contracts/agent-gateway-framework-contract-v1.md §3) |
| Declaration the serving runtime is generated from | capability manifest | Mukadra coinage (mukadra/docs/contracts/agent-capability-manifest-v1.md) |
| The generated serving layer itself | agent gateway | Ours — industry “MCP gateway” means a narrower proxy/router (our deployed Worker is one of those; the framework is more) |
Read the third column carefully — it is the honest part. Three of these words (MCP, tool, resource) will mean the same thing in any agent ecosystem you ever work in. One (prompt/skill) has both an industry name and a local name, and the mapping between them is a defined contract clause, not a vibe. The remaining four are Mukadra coinages: useful, precise, and not what the rest of the industry says. When this course uses one of ours, you can always trace it to the contract that defines it — and you should expect to translate it when you leave this course’s context.
The layer model — the map of the whole course
Agent gateway (generated from the capability manifest)
├─ Endpoint families — tools · skills · surfaces · intent (contract §3)
└─ Transport bindings (contract §5)
├─ HTTP/REST (§5.1)
├─ MCP/JSON-RPC (§5.2) ← Part 1 lives here; Part 2 ends here
└─ CLI (§5.3, placeholder)Section references in the diagram are to mukadra/docs/contracts/agent-gateway-framework-contract-v1.md.
This diagram is the whole course in one picture. Part 1 teaches the MCP binding from the consumer seat — the generic, industry-portable layer: what the protocol is, how transports differ, how remote auth works, and when MCP is the right choice at all. Part 2 climbs the diagram: you author a server by hand, and then see why Mukadra generates them from manifests instead of hand-writing N of them.
Notice what the diagram claims about MCP’s place in the world: MCP is one transport binding among several, not the architecture itself. A capability surface can speak REST and MCP simultaneously; an agent does not have “an MCP version and an HTTP version of itself” (mukadra/docs/contracts/agent-gateway-framework-contract-v1.md §5 preamble). That framing is doing real work — it is the course’s answer to a question you will meet head-on in Module 1.4, When MCP vs a Plain API.
Exit
Before moving on, test yourself against this module’s exit bar: pick any term used so far — say, tool, transport binding, or agent gateway — and answer two questions. Is it MCP-standard or Mukadra vocabulary? And if it is ours, which contract defines it? If you can do that for every row in the table, you are oriented; Module 1.1 starts the mechanism.