Stagehand 3.6.0 Turns WebMCP, Action Caching, and Verifiers Into Browser-Agent Runtime Primitives

Browser agents are past the “can it click the button?” phase. The harder question is whether the runtime can expose page-native tools safely, avoid paying an LLM for the same action twice, and produce enough evidence to debug failure without archaeology. Stagehand 3.6.0, published by Browserbase on June 19 at 2026-06-19T00:33:51Z, is interesting because it works on all three.

The release adds first-class WebMCP support, turns on local Chrome WebMCP testing flags by default, normalizes ActCache URL keys by sorting query parameters, and ships a rubric-based verifier engine with normalized evidence. The compare from @browserbasehq/[email protected] to @browserbasehq/[email protected] spans 44 commits and 300 changed files. This is not a cosmetic wrapper release. It is Stagehand treating browser automation as an agent runtime with a control plane.

WebMCP makes the page a tool provider

The headline feature is first-class WebMCP support from PR #2178, which changed 12 files with 999 additions. Stagehand now exposes page.listWebMCPTools() to collect the current tool snapshot from WebMCP.toolsAdded, and page.invokeWebMCPTool() to invoke page-exposed tools with frame disambiguation, result promises, cancel support, timeouts, and early-response handling.

That API shape matters because WebMCP changes the browser-agent trust boundary. A web page is no longer only something an agent observes, parses, and clicks through. It can become a tool host. That is powerful: tool calls can be more semantic than DOM selectors, less brittle than visual guessing, and closer to the application’s own capabilities. It is also dangerous if the runtime treats page-provided tools as just another harmless affordance.

Stagehand’s tests around WebMCP are revealing. The PR covers snapshot collection, no stale tool reuse, unsupported browser errors, frame resolution, duplicate tool names, result routing, early responses, cancel, timeout, and close cleanup. These are not launch-demo details. They are the minimum controls you need once a page can register tools into the automation environment. If duplicate tool names are ambiguous, if stale tools persist after navigation, or if long-running calls cannot be canceled, the runtime is not operable.

The invocation semantics are particularly good. page.invokeWebMCPTool() returns once Chrome accepts the request; callers must await invocation.result to wait for the actual tool execution. That gives automation code a handle it can observe or cancel while work is running. A synchronous “invoke and hope” abstraction would hide exactly the state advanced users need when browser tools hang, navigate, close frames, or return early.

PR #2229 adds --enable-features=WebMCPTesting,DevToolsWebMCPSupport to default local Chrome launch flags, so local users do not have to remember them. Remote or existing browsers still need to be launched with the flags. That split is worth documenting in your own setup notes because “works locally, missing remotely” is the classic browser automation failure shape.

There is a current limitation: PR #2178 supports WebMCP tools in top-level frames/pages and does not handle tools registered in out-of-process iframes. If your targets rely heavily on embedded cross-origin application surfaces, test before assuming WebMCP coverage. Browser automation is already full of frame-shaped surprises. WebMCP gives those surprises a tool API.

Cache keys are cost controls, not implementation trivia

The most immediately practical change may be PR #2233, which fixes ActCache key derivation by sorting query parameters before hashing. The PR gives the obvious example: ?id=42&utm_source=email and ?utm_source=email&id=42 describe the same page for many workflows, but previously produced different cache keys and therefore missed the cache.

Stagehand’s docs make a strong claim about caching: repeated act() calls can return instantly with no LLM tokens when the cache hits, and expose cacheStatus as HIT or MISS. Local Cache can persist action and agent steps across script runs. That is not just performance; it is FinOps. Browser agents can become expensive quickly because every ambiguous action may involve model inference, page observations, retries, and verification. A cache miss caused by reordered UTM parameters is not a cute bug. It is preventable token spend.

The normalizer is deliberately conservative. It sorts parameters, preserves fragments and duplicate keys, and does not strip tracking parameters, normalize trailing slashes, or collapse semantically risky differences. That restraint is correct. Cache systems for web automation have to balance reuse against false equivalence. Treating every URL variation as different wastes money; treating distinct states as equivalent causes wrong actions on the wrong page. Sorting query parameters is the safe middle move.

Builders should use this release as a reason to make cache behavior part of CI. Run the same act() workflow against reordered query parameters and inspect cacheStatus. Stabilize viewport, auth state, prompts, selectors, and dynamic variables. If your browser-agent system only saves tokens on the one golden path from a demo script, you do not have a cache strategy. You have a lucky transcript.

Verifier evidence beats screenshot mysticism

The verifier work is where Stagehand starts looking more like an agent QA platform than a convenience layer around Playwright-like automation. PR #2132 adds canonical evidence normalization for screenshots, ARIA snippets, agent text, agent JSON, and native tool output, while keeping image reduction behind a dynamic sharp import so core installs remain dependency-light. PR #2133 adds a rubric verifier engine with rubric generation, relevance, per-criterion scoring, fused judgment, fused outcome, failure analysis, task validity, error taxonomy support, bounded first-point-of-failure parsing, and STAGEHAND_EVALUATOR_BACKEND=verifier wiring.

This is the right direction because browser-agent evaluation is not solved by screenshots alone. A screenshot may show the final page but not the wrong tool call that got there. ARIA can expose state the pixels obscure. Agent text can explain intent. JSON and native tool output can reveal whether the automation used the correct semantic object. Normalizing these into chronological evidence gives verifiers something closer to a case file instead of a pile of artifacts.

The rubric engine also reflects a useful shift from “did it work?” to “how did it fail?” Browser agents fail through navigation drift, auth expiry, stale elements, wrong frames, model overreach, tool timeout, unexpected modals, and pages that lie through loading spinners. If a verifier can identify relevance, task validity, per-criterion outcomes, and the bounded first point of failure, teams can fix systems rather than re-run prompts until the demo passes.

Stagehand also adds Claude Fable 5 support via PR #2231, including native structured outputs through an Anthropic SDK bump, adaptive thinking on agent paths, xhigh effort handling, server-side refusal fallback to claude-opus-4-8, and auto tool choice for the final done call on models that reject forced tool use. This is a reminder that an agentic browser framework is partly an abstraction over browsers, partly an abstraction over models, and mostly a catalog of integration edges users do not want to learn the hard way.

What practitioners should do with 3.6.0

If you use Stagehand, test the release around three axes. First, WebMCP: list tools, invoke duplicate names, cancel long-running calls, verify timeout behavior, and confirm whether your target tools live in top-level frames or OOPIFs. Treat page-provided tools like an authority surface, not a shortcut.

Second, cost: build a small regression around ActCache. Reordered query parameters should not turn repeatable automation into a fresh LLM bill. Make cacheStatus visible in traces and alerts. Cache misses should be explainable, especially on workflows you run every day.

Third, evaluation: enable the verifier backend on representative tasks and inspect the evidence bundle. If screenshots, ARIA, text, JSON, and native outputs are still insufficient to debug failures, add the missing instrumentation now. Browser agents will not scale if every failure requires a senior engineer to replay a session like a crime scene investigator.

The useful take on Stagehand 3.6.0 is simple: browser agents do not need more magic. They need handles, timeouts, deterministic cache keys, tool provenance, and failure evidence. WebMCP is exciting because it can make browser automation more semantic. It is also a new way for pages to participate in the agent runtime. Stagehand is doing the unglamorous work that makes that survivable.

Sources: Stagehand 3.6.0 release, WebMCP PR #2178, ActCache URL normalization PR #2233, Stagehand agent docs, Stagehand caching docs