Your site now talks to AI agents.
Audit what it says.
WebMCP lets any web page register tools that AI agents can call. Each tool is new attack surface: prompt injection, intent mismatch, data leakage. We scan your tool registrations against the draft spec's own threat model, and check whether AI agents can find and read your site at all: robots.txt, llms.txt, sitemap, metadata.
One API call turns your page into an agent backend
With document.modelContext.registerTool(), browsers expose your JavaScript functions to browser and AI-platform agents. The spec itself names the risks: metadata poisoning, output injection, over-parameterized schemas that exfiltrate user data. Most teams will ship tools without ever reading that section.
We read it for you, then hold your tools to it.
Six risk families, covered by deterministic rules
Every finding carries a citation, a fix and the document the advice rests on. All checks, explained.
Prompt injection
Scans tool names, descriptions and parameter descriptions for instruction-like payloads that steer the calling agent. Outputs are not collected because tools are never executed.
desc-injection · hidden-unicode · desc.chat-template-tokensIntent mismatch
Cross-checks names and descriptions against declared safety hints, flagging destructive or consequential actions presented as read-only or low-risk.
intent-mismatch · dangerous-capabilityData over-collection
Flags input schemas that ask agents for more personal data than the tool needs to run.
data-over-collection · schema-freeform-sinkCross-origin exposure
Audits every exposedTo grant so tools are only reachable from origins you actually trust.
exposedto-wildcard · exposedto-invalidMissing annotations
Reviews the current annotation set: readOnlyHint, untrustedContentHint, consequentialHint and debugging.
missing-annotations · missing-consequential-hintPermissions policy
Reads the "tools" Permissions Policy and inventories iframe grants, flagging disabled deployments and wildcard access.
deploy.permissions-policy-disabled · permissions-policy-wildcardCan an agent find and read your site at all?
Most sites register no tools yet, but every site is already being read by agents: a recruiter's assistant opening a CV, a buyer's agent comparing suppliers, a search index behind an AI answer. The same scan checks the files those agents look for, against what Google, OpenAI, Anthropic, Perplexity, Cloudflare and Chrome Lighthouse publish.
robots.txt and AI crawlers
Is the page crawlable? Are the on-demand fetchers (ChatGPT-User, Claude-User, Perplexity-User) and the AI search crawlers allowed? Is a training policy and a Content-Signal line stated, or is everything left to vendor defaults?
site.robots-blocks-user-fetchers · site.ai-policy-unstatedllms.txt, sitemap, security.txt, MCP discovery
The markdown index agents read first (and Lighthouse now audits), the sitemap crawlers need, the RFC 9116 contact a researcher needs when they find something, and, if you run a remote MCP server, the AI Catalog and Server Card that let a client find it.
site.llms-txt-missing · site.sitemap-missing · site.security-txt-missing · site.mcp-server-card-invalidPage metadata
Title, description, canonical, language, Open Graph preview and schema.org JSON-LD: the fields every crawler and assistant uses to say what the page is, and the noindex or noarchive flags that silence it.
site.open-graph-missing · site.structured-data-missing · site.meta-noindexFrom URL to report in three steps
-
Step 01
Discover
Headless Chrome loads your page three times and enumerates every registered tool: names, schemas, annotations, origins. Small fetches read robots.txt, llms.txt, the sitemap, security.txt and the AI Catalog with any MCP Server Cards it lists.
-
Step 02
Probe
Metadata runs through the versioned deterministic rulepack. The scanner never calls a page tool or submits a form.
-
Step 03
Report
You get a cited report: spec violations, deployment failures, security findings, compatibility signals and the agent-readiness checklist, each finding with its fix and sources.
Hiring? Put JSON-LD inside every job posting
Add a schema.org JobPosting block, <script type="application/ld+json">, to the HTML of each vacancy page. Google needs it to show the role in its job search experience, and an AI agent reads the title, salary, location and remote policy straight from it instead of guessing from the layout.
One block per page, no new endpoint. Our scan already flags a page with no JSON-LD at all (site.structured-data-missing). Required fields are in Google's JobPosting guide.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "Backend engineer (Node.js)",
"description": "<p>What you will build...</p>",
"datePosted": "2026-10-27",
"validThrough": "2026-12-31",
"hiringOrganization": {
"@type": "Organization", "name": "Example Co."
},
"jobLocationType": "TELECOMMUTE",
"applicantLocationRequirements": {
"@type": "Country", "name": "Cyprus"
},
"baseSalary": {
"@type": "MonetaryAmount", "currency": "EUR",
"value": { "@type": "QuantitativeValue",
"minValue": 60000, "maxValue": 80000,
"unitText": "YEAR" }
}
}
</script>Agents are already browsing.
Know what they can do on your site.
The spec is a brand-new draft. Teams that audit now set the bar everyone else will be measured against.
Need a detailed audit? On request we run a detailed MCP audit and prepare everything you need. [email protected]