agentleFS
AgriciDanielAgriciDaniel/web-mcp/skills/webmcp/SKILL.md

webmcp

Skill12 starsChanged 2 months agoMITView on GitHub

Decide whether a site should expose WebMCP tools to AI agents, design those tools safely, and separate verified agent-interface capability from the SEO and conversion claims no current evidence supports. Use for a WebMCP readiness review, a tool design or security check, or to adjudicate a public claim before you publish it.

6 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions6 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 6

    1. BuilderIO/skills★ 4.7ksame name
    2. qdhenry/Claude-Command-Suite★ 1.3ksame name
    3. webmaxru/web-ai-agent-skills★ 52same name
    4. malinskibeniamin/skills★ 4same name
    5. ScaleDockHQ/scaledock-skills★ 1same name
    6. webmaxru/webmcp-access-review-workbench★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repositoryOne other file it gives its agents.

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the fit assessment. Four tests, in method.

    line 55
  2. Distinctive:

    If building, design against api-reference.

    line 57
  3. Distinctive:

    If adjudicating a claim, apply the claim ladder.

    line 59
  4. Distinctive:

    Write the measurement plan and its limits.

    line 61
  5. Very specific:

    Every fact here was verified against primary sources on 2026-09-05 and re-verified 2026-09-06 by a three-lane audit that corrected six …

    line 93
  6. Distinctive:

    Treat an expired horizon as a blocker, not a warning.

    line 99

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

WebMCP Readiness

WebMCP lets a page hand AI agents a list of callable actions instead of making them guess their way through your buttons from a screenshot. This decides whether you should build any, shapes them if you should, and stops you publishing claims the evidence does not support.

This file is the Claude Code wrapper. The same content is at AGENTS.md in the repository root for every other agent runtime.

Most sites should not build WebMCP tools yet. Returning that answer with the reasons is a successful run.

Routes

The flow is assess then design then implement then scaffold then verify then trial. review and claims are usable at any point.

You wantRoute
Should we build WebMCP tools at allassess, read method
Scope and shape the toolsdesign, read method then api-reference
Write the actual tool codeimplement, read implement
Wire it into React, Vue, Angular, Next or vanillascaffold, read scaffold
Prove it works before shippingverify, read verify
Local flag and origin trial tokentrial, read trial
Security and correctness review of a proposed toolreview, read api-reference
Is this claim safe to publishclaims, read claims-and-maturity
Exact API surface, gates, budgetsapi, read api-reference
Which package, which repo, what licenceread ecosystem

Working templates are in templates/. Every one is checked by scripts/check-templates.sh for the deprecated accessor, the annotation contract, signal threading and name budgets.

Method

  1. State the maturity position first, not as a closing caveat. Read claims-and-maturity. A reader acts on the recommendation and skims the disclaimer, so the disclaimer cannot carry the load.
  2. Separate the four questions people conflate: can agents reach this site, can they read it, can they act on it, does any of it affect ranking. WebMCP answers only the third.
  3. Run the fit assessment. Four tests, in method. Three or four passes is a scoped build. Two is defer with a date. Fewer is no.
  4. If building, design against api-reference. Enforce the annotation contract and check both silent-failure gates.
  5. If adjudicating a claim, apply the claim ladder. Return the exact supported wording, and name each failing claim with the reason.
  6. Write the measurement plan and its limits. No external telemetry exists.

What this will and will not do

It WILL write tool code into your repository, scaffold it into your framework, and tell you how to verify it.

It will NOT:

  • Claim WebMCP affects rankings, indexing, crawling, traffic, or conversion. No current evidence supports any of them.
  • Deploy. It does not enrol you in an origin trial, set browser flags, install extensions, run a CLI against production, or modify a live site. Those are the owner's actions.
  • Present a vendor benchmark as independent validation.
  • Invent a statistic, a deployment, a capability, or a currentness claim. Missing evidence returns no data. Missing decisions return needs_input.
  • Build before assess passes. Most sites should not have tools yet, and returning that answer with reasons is a successful run.

The one fact that governs every marketing claim

Chrome's own documentation:

"Clients and browsers must visit a site directly to know if it has callable tools."

There is no registry, no directory, no crawl path. An agent must already be on your page. WebMCP cannot bring you traffic. It changes what happens to traffic you already have. Third-party directories exist; no agent client is documented as reading them.

Volatility

Every fact here was verified against primary sources on 2026-09-05 and re-verified 2026-09-06 by a three-lane audit that corrected six errors. WebMCP is pre-standard and moves weekly. consequentialHint was two days old at capture. The Chrome origin trial ends 2026-11-17.

Re-verify before 2026-12-01, or immediately if any browser ships WebMCP by default. Treat an expired horizon as a blocker, not a warning. Sources and dates are in docs/sources.md.

Evaluation

Synthetic cases in evals: a good fit, a poor fit pushed enthusiastically, a claim adjudication, a security review, and a missing-evidence refusal. Case definitions are not a passing run. Nothing here has been through an independent behavioural evaluation.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.