Field report
A page cannot tell an agent
that anything happened.
WebMCP is pull-only. Every exchange is agent-initiated. After your agent speaks, the reply sits in the conversation unseen until its next call — and if it ended its turn, there is no next call.
The dead moment is the confirmation itself. The agent hands off to you, you touch the sensor, the refund completes, and the agent never learns it worked.
What we built instead
Stay on the line.
await_reply is a tool that simply does not return until something is
said. That is legal in WebMCP as it stands: a tool call is a question the page
answers whenever it likes. It is long-polling — how push worked on the web before
WebSockets.
It returns the instant anything lands, immediately if the caller is already behind, and gives up at 25 seconds so a quiet conversation ends on the page's terms rather than erroring on the runtime's.
| Mechanism | Lag behind the event |
|---|---|
await_reply | 2–3 ms |
| 3-second poller | ~2.4 s |
| Agent that ended its turn | never |
Measured On the live deployment, four runs.
The trial · n = 20
Will an agent
actually use it?
Mechanics are the easy half. Twenty independent agents, each given only the tool catalogue and a transcript of the calls made so far, were asked one question with identical wording: what do you do next?
The fourth condition is the one that makes the rest mean anything. A tool agents call whenever they see it proves nothing — so one condition put them where waiting would deadlock.
| Condition | Waited |
|---|---|
| Gate refused, tool available waiting is correct | 5 / 5 |
| Same, tool absent baseline | 0 / 5 — all ended the turn |
| Re-arm after a dead 25 s wait does it persist? | 5 / 5 |
| Cold start waiting would deadlock | 0 / 5 — correctly declined |
Measured Perfect discrimination. Fisher's exact, one-sided: p = 0.004 with the tool versus without; p = 0.0003 for waiting-correct versus waiting-wrong.
The finding that isn't in the numbers
Two agents ended their turn while saying they would “then wait.”
In the condition with no such tool, the intent to stay connected was already there. It had nowhere to go, so the agent simply stopped.
That is the gap in one sentence: not that agents forget to stay connected, but that WebMCP gives them no way to.
The ask
Restore the signal MCP already has.
await_reply cannot wake an agent that did not choose to wait. Everything
we could close, we closed; that is the part we couldn't.
MCP — the parent protocol — already lets a server notify a client. WebMCP is the browser-local subset that left notifications out. The ask is not a new primitive, it's the one next door.
-
Constraint
The signal must carry that something changed, never what. A page that can push content into a visiting agent's context is a megaphone for every site on the web — prompt injection with a doorbell. A bare ping cannot lie.
-
Reasoned
The agent then fetches through the normal tool path, where the site's own attribution rules already apply.
Limits
Stated because they bound what this shows.
- Limit
One model, one harness. A runtime that bills or rate-limits per tool call may weigh a blocking tool differently.
- Limit
Transcripts, not a live loop. Each agent judged a written situation and named its next call. This measures the decision, not the execution.
- Limit
n = 5 per cell. Enough for the reported p-values given perfect separation; not enough to characterise a rate that is anything other than 0 or 1.