Discovery surface
WASM MCP exposes capabilities so the runtime can inspect what exists before trying to build a workflow.
What is WASM MCP in UMA?
In the UMA reference experience, WASM MCP is the discovery and invocation surface through which the runtime learns what capabilities are available. It matters because it makes capability availability explicit instead of hiding it inside custom integration code or one-off runtime assumptions when compute can happen in many places and the system needs a visible way to decide where logic runs.
The short answer
WASM MCP is the capability-facing control surface in the Chapter 13 model. It exposes what capabilities exist, how they can be described, and how the runtime can interact with them. That makes it easier for the runtime to discover, validate, and compose work without hardwiring every path in advance.
The important point is not the acronym by itself. The important point is architectural: a modern system needs a visible, inspectable way to surface capabilities if it wants runtime composition to stay governed instead of ad hoc.
This fits the same UMA summary as the rest of the site: not “write once, run everywhere,” but “write once, run where it makes sense,” with discovery staying explicit instead of hidden.
Why this layer exists
A runtime cannot compose workflows from capabilities it cannot see. In simpler systems, those capabilities are often hidden behind internal calls, framework-specific bindings, or undocumented operational knowledge. That may work for a static path, but it becomes weak as soon as discovery, ranking, or dynamic selection enters the picture.
WASM MCP exists in the UMA story to make that surface explicit. It tells the runtime what is available without forcing the runtime to treat every capability as an opaque guess.
Why it is not just another protocol page
This page is not trying to turn UMA into a protocol discussion. The key idea is not that one acronym is fashionable. The key idea is that runtime discovery needs a real interface. If a system claims to compose work from capabilities dynamically, it should be able to show how those capabilities are surfaced, described, and made available for runtime governance.
In that sense, WASM MCP is valuable because it keeps discovery visible. It gives the runtime a clear place to ask what is available before the planner proposes or the runtime approves a path.
Invocation bridge
It supports calling into capability providers through a visible, structured boundary instead of hidden glue code.
Runtime support
The runtime can pair capability discovery with compatibility checks, policy evaluation, and final approval.
Architectural evidence
Readers can see where capability availability comes from instead of assuming the workflow path was magically known.
How it fits with capability, planner, and runtime
The capability is the unit of behavior. The planner can help interpret the goal and rank possible paths. The runtime remains authoritative over what is approved. WASM MCP sits earlier in that chain: it is the surface that makes available capabilities visible to the rest of the system.
That is why it matters in the reference app. `WASM MCP` is not just a decorative box in the graph. It marks the point where capability discovery becomes explicit and inspectable.
What problem it solves in practice
Without a discovery surface like this, teams often end up with dynamic behavior that is only dynamic inside implementation code. The runtime “knows” about capabilities because somebody programmed a list, a registry, or a service map in one local place. That makes the system harder to understand and harder to audit.
WASM MCP improves that by turning availability into something more explicit. The system can expose what exists, then let the planner and runtime reason over that availability instead of operating on hidden assumptions.
A concrete proof point
In the reference app, the `WASM MCP` node matters because it shows where discovery begins. The runtime does not simply know what to call. It sees available capabilities through an explicit surface, and that makes the rest of the workflow easier to inspect and trust.
Why this matters for SEO and reader understanding too
Readers who see `WASM MCP` in the live app or Chapter 13 CLI output will naturally ask what it means. If the site does not answer that, the reference experience feels more advanced than it really is. This page exists to close that gap: it explains the term at the architectural level instead of forcing the reader to reverse-engineer it from the demo.
That also makes the book more valuable, not less. The page explains the concept clearly enough for orientation, while the book can still provide the fuller model and broader implications.
What WASM MCP is not
- It is not the runtime itself.
- It is not the capability itself.
- It is not the planner.
- It is not a substitute for runtime validation or trust enforcement.
- It is not valuable just because it exists; it matters because it makes discovery explicit.
A practical design test
If your system claims to support runtime composition, ask where the runtime learns what capabilities exist. If that answer is hidden in internal code or tribal knowledge, the architecture still lacks a proper discovery story. A visible discovery surface is one of the signals that the system is becoming more governable.
A second good question is whether a reader can point to the discovery layer separately from the planner and the runtime. If those three roles blur together, the system becomes harder to explain.
Frequently asked questions
Is WASM MCP required for UMA?
No. UMA as an architectural model is larger than one discovery surface. But Chapter 13 uses WASM MCP because it is a strong way to make capability discovery and invocation visible in a runtime-centered workflow.
Why not let the runtime keep an internal registry instead?
It can, but an explicit discovery surface is easier to inspect, explain, and evolve. It keeps capability availability from becoming a hidden implementation detail.
Does WASM MCP replace runtime authority?
No. It helps expose what exists. The runtime still decides what is valid and what can actually run.
The easiest way to understand WASM MCP is to place it beside the other UMA roles: capability, planner, runtime, and final workflow. The live reference app and the concept pages around it make that chain visible step by step, while the book takes the same discovery surface into the broader execution model behind it.