One account. One booking system. Two ways in.
People use the page. Agents use tools provided by that same page. Both see the same saved bookings and compete for the same tables within your fictional sandbox.
How a booking travels through the app
In your browser · one signed-in session
HumanButtons & forms
Search, choose a time, and book through the interface.
AgentPage WebMCP tools
Call named actions with structured inputs and results.
search_restaurants
check_availability
create_reservation
↓↓
Shared page actionsBoth update the visible page and call the same booking API.
↓HTTPS + the browser’s session cookie
Agent requests also carry X-Agent-Session.
On Cloudflare
Worker · shared API
Checks the application domain, mutation origin, and request format; routes to the account’s storage.
GET /api/restaurantsGET /api/availabilityGET / POST /api/reservations
↓
One Durable Object per account
Validates the login session. Agent requests must also pass reference, expiry, endpoint permission, and quota checks.
SQLite storageSessions & grants · reservations · usage & activity
Atomic writes and unique constraints prevent double-booking. Idempotency keys make identical booking retries safe.
The saved result returns to the caller and updates the page, so people and agents can read back the same reservation.
For people
Keep a familiar booking interface and see what the agent did. Both routes use your account’s inventory. Signing out revokes that login session and its agent references.
For agents
Discover explicit actions, input schemas, availability, and saved results. Less reliance on interpreting screen layouts; no separate account or password in a tool call.
How authentication and limits work +
- The person signs in on the page. The browser sends a Secure, HttpOnly session cookie with API requests. Protected discovery tools register after sign-in; the public booking tool asks for sign-in if needed.
- The page obtains an agent reference. Before a protected tool request, it calls
POST /api/agent-session using the login cookie. The server issues a reference bound to that session for 15 minutes. The page adds it as X-Agent-Session; the password and reference are not included in tool results.
- The server applies the agent policy. Only restaurant search, availability, and reservation reads/creation are permitted. Invalid references are rejected instead of falling back to ordinary requests. New references do not reset account limits.
What this does and doesn’t establish: the header selects a request policy. It does not prove WebMCP use or identify an agent provider. A client can reproduce this request format; login and server validation still apply.
In this session
Request activity +
“App” means the application returned the response. “Upstream” alone does not prove a bot block; confirm with Cloudflare Security Events.