Signpost is a stateless capability resolver for WebMCP. Providers declare what their sites can do; an agent asks for one capability, and Signpost points to the sites that offer it. It never holds the plan — the agent does.
Each lookup is independent and stateless. Signpost never receives the user's full request, never remembers a previous lookup, and never decides what should happen next. It matches one declared capability to the sites that offer it, and stops there.
Once a site is found, the agent works with that site's own WebMCP tools directly. Signpost is out of the loop.
// one capability in, matching sites out — no objective, no session, no next step resolve_surface({ capability: "book a haircut" }) → { matches: [ { surface_url: "https://chairandcomb.studio", capability: { id: "book_appointment" } } ] }
Choosing what to do next doesn't authorize the agent to execute it. On the sites where an action is consequential — placing an order, booking an appointment — the provider gates execution behind an authorization of the exact terms.
Authorization requires a trusted browser activation on the provider's own page. Synthetic page-script activation is rejected before authorization state is created.
If a term changes after authorization — a different time, a higher total — the action is blocked and re-authorization is required.
The evidence view keeps discovery and execution facts separate. Signpost emits capability-resolution evidence; participating consequential providers emit authorization and provider-execution evidence. An allow decision is not proof of execution; provider calls are recorded separately.
Evidence comes from participating browser surfaces and is attributed using the browser-set Origin header. It is not authenticated provider evidence. Events are append-only at the collector API surface. See the live evidence →
deckhouse.coffee — order coffee for pickup · chairandcomb.studio — book a hair appointment · hexregistry.dev — check a hex color against a palette (read-only; no authorization gate).