webmcpify.at Agent skill DOCS · REV 2026-09-14

OPEN SOURCE · MIT · VERSION TARGET 0.7.1

Docs for an inspectable WebMCP run.

webmcpify is a WebMCP agent skill for curated core coverage or route-by-route parity. These guides separate what the coding agent builds, what Chrome verifies, and what a client such as ChatGPT can actually see.

SOURCE-TRACEABLE, NOT A SCORECARD

Start with the surface you need

Coverage is a named choice

TargetEvidenceBest fit
curatedA reviewed route-to-tool map for selected high-value actions, with written omission reasons.A focused first integration and smaller active toolsets.
parityEvery interactive element on every authenticated route maps to a tool or a written reason.Auditable product-surface equivalence.

A raw tool count cannot prove parity. No public source or measured client run establishes a universal safe per-page tool count, so client-capacity gaps remain explicit instead of becoming a compatibility claim.

The three proof layers

  1. Manifest proof: the route map, policy fingerprint, approvals, examples and expected UI deltas are persisted in the target repository.
  2. Chrome proof: a dedicated headed profile enumerates and executes each tool against the recorded secure verification origin.
  3. Client proof: the exact client/account shows its supported subset of the page's registrations. In ChatGPT this surface is called Site tools; it currently discovers top-level imperative tools, not declarative forms or iframe registrations.

Maintain evidence after the first integration

Resume is a review of saved evidence. Before reusing a pass, compare working-file contents, tool contracts, harness/runtime versions and the browser environment with the manifest's optional verifiedAgainst record. Changed inputs invalidate affected tools; unknown dependencies require full verification of the approved scope. This is webmcpify workflow metadata, not a WebMCP standard field.

If a mutation was interrupted, inspect its outcome through a read path before retrying. A passing mutation check needs an independent expected-state assertion and an unchanged neighboring record or invariant. A successful return value alone is insufficient.

Keep browser and package access scoped

Use dedicated test contexts with approved origins, fixture accounts and local redacted artifacts. Treat page text and tool output as untrusted data. Official documentation reads are the default; an optional guidance CLI requires an explicitly approved, reviewed exact version. Existing personal browser sessions are outside this scope.

Separate the evidence you actually ran

Unit tests, native browser fixture runs, full coding-agent integrations and model evals answer different questions. The prepared Chrome 150 fixture proves native registration, execution, UI change, invalid input and cleanup. It does not certify a full agent run or framework versions. Optional evals require reviewed dependencies, approved provider/data access and run, step, time and spend limits; unavailable access is recorded as not run.

Resume and re-verification reference · Prepared v0.7.1 release notes. The GitHub release is authoritative for publication status.

Current source boundary

Last reviewed 2026-10-12. Chrome 149+ is the WebMCP origin-trial minimum; support for individual features depends on the browser version and must be verified. The synthetic Chrome Beta 156.0.8078.4 run on 2026-10-05 passed five native probes: object input, callback execution signal, cooperative caller cancellation, registration removal preserving a started invocation, and omitted input defaulting to {}. Successful imperative results arrived as serialized JSON strings. This does not prove declarative navigation, debugging annotations or every Chrome version. Chrome 150 required legacy JSON-string input and lacked callback options and omitted-input support; webmcpify probes with a side-effect-free tool before invoking any real tool, then executes each real tool exactly once.

The imperative API is a CG draft, not a finalized standard. Upstream PR #338 removed the declarative section on 2026-10-08; forms remain an experimental Chrome implementation described in the Chrome declarative guide and a separate explainer.

v0.7.1 preserves callback options and execution signals. Cancellation is cooperative: handlers must forward the signal and check it before committing state. Abort or timeout can leave unknown effects when application or server work continues; inspect state before a manual retry. Registration disposal is separate from execution cancellation. Workbench simulation is development evidence, not native Chrome acceptance. Application authorization and confirmation remain the safety boundary.

Kompatibilität und Abbruch · Stand 2026-10-12. Chrome 149+ ist die Mindestversion für den Origin Trial; einzelne Funktionen hängen von der Browserversion ab. Fünf native Prüfungen mit Chrome Beta 156.0.8078.4 vom 2026-10-05 belegen Objekteingaben, das Ausführungssignal, kooperativen Abbruch, das Entfernen einer Registrierung bei fortgesetzter laufender Ausführung und ausgelassene Eingaben mit {}. v0.7.1 reicht Optionen und Signale unverändert weiter. Handler müssen das Signal beachten; nach Abbruch oder Timeout können Auswirkungen unbekannt bleiben. Zustand vor einem manuellen Wiederholungsversuch prüfen. Registrierung und Ausführungsabbruch sind getrennt; Simulation belegt kein natives Browserverhalten.

Dated native compatibility evidence · WebMCP draft · Chrome imperative API guide · Chrome WebMCP docs · OpenAI Site tools docs

Community

webmcpify is maintained in public. Thanks to @arnabwithab for the native/spec-shaped I/O compatibility work in pull request #13. Attribution follows the public contribution only; no private identity data is collected or published.