The three modules before this one were neutral about MCP — they described what it is, how its transports differ, and how its auth model works. This module is not neutral. It is the decision module: when does MCP earn its place, and when is a plain HTTP API the better call? The framing that gives you a durable answer is not about current vendor support or ecosystem momentum. It is about the transport-binding model.
MCP is a transport binding, not an architecture
This is the load-bearing claim of the module, and it comes directly from the agent gateway framework contract (mukadra/docs/contracts/agent-gateway-framework-contract-v1.md §5). Read it once before the corollary lands:
An agent does not have “an MCP version” and an “HTTP version” of itself.
A capability surface — a set of tools, skills, surfaces, and intent endpoints — speaks transport bindings. MCP/JSON-RPC is one binding. HTTP/REST is another. CLI is a third (placeholder in the current contract, §5.3). The same underlying capability can speak all of them simultaneously, because the bindings are orthogonal to the capability itself. The gateway contract’s §5.2 mapping table makes this concrete: MCP tools/list and tools/call map to the same tool endpoint family that HTTP/REST also reaches; prompts/list and prompts/get map to the skill endpoint family; resources/list and resources/read map to surfaces.
If you have internalized this framing, the “MCP vs plain API” question dissolves into a narrower one: which transport binding serves this consumer? That question has a clean answer.
The decision framework
Use MCP when the consumer is an agent host you do not control.
The economic argument from Module 1.1 applies directly here: without a standard, every capability provider writes N bespoke integrations, one per host. With MCP, one server implementation reaches every MCP-capable host. The leverage is the N×M-to-N+M conversion. If you do not control the consumer — if you are building a server that any Claude Desktop user, any Cursor user, any MCP-capable agent framework can reach — MCP gives you that audience for the cost of one conforming implementation.
Use a plain API when you control both ends.
If you control both the capability and the consumer, the protocol earns nothing. You would be adding the MCP wire format on top of an HTTP stack you already own and operate. The one-standard-integration leverage requires that the consumer already implements MCP; if you own the consumer, you implement whatever you like. The marginal cost of MCP drops to zero when you control both ends — and so does its benefit.
Two secondary pressures push toward a plain API regardless of who controls the consumer:
- Semantics MCP does not carry. MCP’s message model is tool-call/result, resource-read, and prompt-invocation. If a capability needs streaming responses, bidirectional events, or long-lived sessions with complex state, the MCP wire format is an awkward fit. A plain HTTP API with server-sent events or websockets serves those semantics directly. Do not bend the protocol to carry what it was not designed for.
- Tooling alignment. If the consumer’s development stack already has mature HTTP client tooling and the team has no MCP client experience, the integration cost tilts. This is a team-level consideration, not a protocol one — but it is real.
The cost of the wrong choice in both directions
Wrong call: MCP as the hammer. Every capability wrapped in an MCP server, including internal service-to-service calls between two systems you own and operate. The result: auth complexity everywhere (Module 1.3’s flow costs something to implement and operate), client-library dependency in every consumer, a JSON-RPC wire format where a plain function call or HTTP request would have zero overhead. MCP’s leverage evaporates when the consumer is not a third-party agent host; what remains is complexity.
Wrong call: bespoke per-host integrations. A capability built without MCP that then needs to reach Claude Desktop, Cursor, Windsurf, and three other agent hosts the team does not control. Each integration is a custom client library or connector — the N×M problem in full. When the protocol existed that would have bought a single implementation for all of them, not using it is a choice with a real and growing cost. The ecosystem’s adoption of MCP means the N grows over time.
The one-new-primitive principle
The honest foundation of all of this is Observation 33 from the Mukadra AI-first treatise (mukadra/docs/methodology/ai-first-observations-v4.1.md). Its most durable claim: AI introduces exactly one genuinely new primitive — the nondeterministic API (defined precisely in mukadra/docs/contracts/nondeterministic-api-contract-v2.md, and in the holdings shared lexicon kukamanga/docs/governance/shared-lexicon-v1.md Domain 2). Everything else — transport protocols, auth flows, API contracts, deployment infrastructure — is standard software engineering, inherited at no cost. MCP is not a new primitive in this sense; it is a standard protocol with a JSON-RPC wire format and an ecosystem of client libraries. Its value is in the integration economics, not in unlocking capabilities that were previously impossible.
A note for honesty: Obs 33 contains MCP-specific subsections whose claims about MCP’s place in the ecosystem (“MCP never enters”) contradict current practice — the agent gateway framework contract treats MCP as a first-class transport binding, four bespoke MCP services run today, and this course teaches MCP as the on-ramp. The gateway contract is the reconciled position; Obs 33’s text lags it. That reconciliation belongs to the AI-first SDLC course campaign (JUNE-146 design lane), not to this module. The observation’s core insight — one new primitive, everything else is inherited — is durable and this module depends on it.
Putting it together
The decision tree is short:
-
Does the consumer’s host implement MCP? (Or: are multiple hosts — some of which you don’t control — involved?)
- Yes → MCP transport binding earns its place. Use it.
- No / you own the consumer → plain API unless there’s a specific reason to add the protocol layer.
-
Does the capability need semantics MCP does not carry well? (Streaming, bidirectional events, long-lived sessions with complex state?)
- Yes → plain API; do not contort the protocol.
-
Is this a service-to-service call between two systems you own and operate?
- Yes → plain HTTP or whatever the team’s existing RPC pattern is. MCP adds nothing here.
Module 0’s layer diagram is still the map:
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)
└─ CLI (§5.3, placeholder)MCP and HTTP/REST are peers in that diagram. The capability surface is above both. That is the architecture. The Part 1 capstone asks you to use this framework on three concrete scenarios; it follows directly from this module.