isWebMCP

Browserbase · Browser sessions, Playwright, and replay evidence · Uncontacted prospect

Design independent evidence for what an agent actually did

Proposed research and integration partner: develop a bounded browser-evidence adapter. This addresses an important missing capability, but it is not an integration we can offer customers as complete today.

Documented by the company

What the official sources establish

Why this prospect: 7/10 editorial fit

Editorial inference, 7/10: selected for the missing independent-runtime-evidence layer, not immediate turnkey coverage. The explicit integration route is useful, but an adapter and privacy review are required; it ranks below Lovable on the distribution tie-break. This is our prioritization judgment, not a company-quality score or evidence of adoption.

Current product fit
1 / 2
Documented integration path
2 / 2
Reusable integration
1 / 2
Pilot feasibility
1 / 2
Future runtime fit
2 / 2
Read the selection method →

Proposed integration—not a validated connector

  • Begin with an owned fixture and a developer-run browser harness, not arbitrary enterprise sites. Collect a source report separately, then assert the visible result of one low-risk search in the browser.
  • Design an evidence envelope containing task version, browser version, permitted origin, exact assertions, timestamps, and outcome. A recording explains behavior but cannot substitute for an independent correctness assertion.
  • Test browser feature availability before attempting native WebMCP execution. Browser automation exposed through an MCP server is a different mechanism; missing native support must be reported as unsupported, not silently emulated.

What we can supply now

  • Existing source baselines, supplied-contract lint, and starter recipes can seed a carefully scoped fixture experiment.
  • The current source comparator can compare eligible source artifacts only; it cannot consume replay files or certify a browser task.

What needs development or partner agreement

  • A real browser adapter and independent outcome assertions, with cancellation, allowlisted origins, timeouts, and action approval.
  • Credential isolation, explicit recording consent, retention/deletion controls, cost caps, and a runtime evidence export format.

Proposed pilot · Not performed

A bounded way to test the hypothesis

Proposed scope: a small technical spike on one owned search fixture, using a consenting partner account and a pre-agreed spending cap. No production customer sessions.

Deliverables to produce

  • A runnable adapter prototype with failing, passing, cancelled, and unsupported test cases.
  • A scrubbed example evidence record plus introduction and quickstart drafts for eventual integration review.

Measures to collect—not results

  • Check that deliberately wrong search results fail the independent assertion even when the tool call succeeds.
  • Measure assertion reproducibility, artifact completeness, run duration, and actual browser cost; do not invent savings.

Stop or decline if…

  • Stop before execution if permission, recording policy, browser compatibility, or budget is unresolved.
  • Do not publish sessions, credentials, or third-party content; never enable anti-bot evasion to complete a test.

Risks and open diligence questions

  • A future runtime adapter needs significant work; treating this prospect as a shipped feature would mislead users.
  • Recorded sessions may contain sensitive data. A browser vendor capability is not an isWebMCP governance guarantee.

Public route for a future conversation

Public form asks for introduction, quickstart, and code links. Prepare those artifacts before a formal submission; no form has been filled or submitted. No message or application has been sent for this proposal.

Suggest a Browserbase integration ↗

Source and date ledger

Research reviewed 2026-09-05. Dates describe the source, not a company trial. An unavailable publication date is left unknown.