Skip to main content
MCP is not “instantaneous” and AWP does not claim to be the only asynchronous protocol. MCP has progress, cancellation, and (experimentally) durable tasks. The difference is what those primitives are about. An MCP task is a unit of work the server performs for the caller. An AWP action is an intent applied to a shared, continuously changing environment, where the world keeps moving between your calls, other agents may hold other embodiments, physical limits apply to every command, and the observations you act on are already stale by the time you act. The combination AWP standardizes, and MCP does not: embodied semantics (frames, units, clocks, modalities), observation freshness as a first-class quantity, actions with duration and preemption over shared physical state, session authority over an embodiment, and a portable, replayable record of the session.

​
The full stack comparison

Building the same integration on MCP means: an MCP server for the discrete operations, a bespoke streaming channel for sensors (with your own framing, sequencing, and timestamps), a bespoke safety layer (limits, e-stop, approval), a bespoke session/authority model, and a bespoke log format. Each part is reasonable; none is standard, and the agent must be rewritten for every world. An AWP world provides all five in one negotiated session. Rule of thumb: if the thing you’re calling completes as a unit of work and you can wait for the result, it’s a tool (MCP). If you act within it over time while it changes around you, it’s a world (AWP). They compose both ways: an AWP world can expose MCP tools for its non-embodied surfaces (querying a warehouse database while controlling the arm), and an agent can appear as an MCP server whose tools open AWP sessions.