Skip to content

scope.md

Latest commit

 

History

History
76 lines (51 loc) · 7.74 KB

scope.md

File metadata and controls

76 lines (51 loc) · 7.74 KB
Raw

Scope

cf-webmcp is a Cloudflare Worker that adds WebMCP to a website. It is not "the agent-ready everything Worker". This page lists what's in scope and what isn't, so feature requests get clear, fast answers.

For the security boundary cf-webmcp does and does not enforce, see docs/security.md.

In scope

  • WebMCP manifest at /.well-known/webmcp
  • In-page tool registration via injected <script> and <link rel="webmcp">
  • HTTP Link header with rel="webmcp" on every response
  • /mcp landing page for desktop MCP client pairing
  • Fallback widget (jasonjmcghee/WebMCP) for desktop bridge clients
  • Five executor types for server-side tool calls: sitemap_filter, rss_feed, dom_extract, http_json, http_get
  • Form attribute injection stamping W3C declarative form attributes onto matching <form> elements via TOML config
  • /llms.txt augmentation (merge with origin's file, marker-block idempotency)
  • /robots.txt augmentation (marker-block, blocks the Worker's private namespace)
  • /.well-known/agents.md publication with /AGENTS.md and /agents.md 301 aliases
  • /.well-known/api-catalog (RFC 9727) publication pointing at the WebMCP manifest
  • /.well-known/agent-skills/<slug>/SKILL.md publication (Anthropic-format Agent Skill) with case-variant 301 aliases
  • /.well-known/agent-skills/index.json publication (Cloudflare Agent Skills Discovery RFC v0.2.0) with a build-time SHA-256 digest of the SKILL.md
  • ARD publisher catalog (/.well-known/ai-catalog.json) - lists the site's Agent Skill as an ARD entry; advertised via robots.txt Agentmap directive, rel="ai-catalog" Link header and link tag, and llms.txt. Default OFF (ARD v0.9 draft). See docs/ai-catalog.md.
  • Build-time SSRF allow-list validation
  • Per-IP and per-tool rate limiting
  • /_webmcp/health operational endpoint

That's the surface. Each item exists because it's part of how a WebMCP-aware agent (browser-native or desktop-bridged) finds and calls tools on a publisher's site.

Out of scope

The following are real, useful things, but they are not WebMCP and would dilute the project if bundled in. They belong elsewhere - in the publisher's CMS, in a separate Worker, or in a different project entirely.

Alternative protocols

  • MCP server cards. MCP is a JSON-RPC protocol distinct from WebMCP. cf-webmcp does not publish MCP server descriptors (/.well-known/mcp/server-card.json) and does not run a streamable HTTP MCP endpoint. Desktop MCP clients bridge into a WebMCP site via the fallback widget, which is a runtime concern, not a discovery one. Publishers running cf-webmcp and a separately-deployed MCP JSON-RPC endpoint at POST /mcp should be aware that cf-webmcp claims GET /mcp for its landing page by default; the two paths share a URL but differ by method. cf-webmcp's current router does not split on method, so a publisher needing both should move the landing page ([webmcp_landing].path = "/pair") to free /mcp for the MCP JSON-RPC endpoint.
  • A2A agent cards. Agent-to-Agent is a JSON-RPC protocol for agent-to-agent communication; its /.well-known/agent-card.json discovery file presupposes a running A2A endpoint. cf-webmcp publishes browser-side WebMCP, not an A2A endpoint, so emitting the card would be misleading. Publishers running A2A alongside can publish the card from origin.
  • (Removed in v0.3.0) Agent Skills (Anthropic). Originally listed as out-of-scope on the grounds that the manifest covered the same ground. Reversed in v0.3.0 after observing real-world adoption (Cloudflare Browser Run docs, isitagentready.com audits) and that the operational hints niche - "when to use which tool", "common pitfalls" - was not actually covered by either the structured manifest or the prose agents.md. cf-webmcp now publishes a SKILL.md at /.well-known/agent-skills/site/SKILL.md. See docs/agent-skills.md.
  • OpenAPI / AsyncAPI generation. The WebMCP manifest already describes our tools in a WebMCP-native shape. cf-webmcp does not project that into OpenAPI.
  • ARD registry REST API (/search, /explore, /agents). cf-webmcp publishes the ARD publisher catalog (the document a site serves at /.well-known/ai-catalog.json) but does not run a registry. The registry is a separate centralised service that aggregates publisher catalogs.
  • ARD JWS signing / attestations. cf-webmcp does not attach cryptographic claims to ARD entries.
  • ARD DNS-based discovery. cf-webmcp does not generate or manage DNS TXT records for ARD catalog URLs.

Authentication

  • OAuth Authorization Server metadata (RFC 8414), OAuth Protected Resource (RFC 9728). cf-webmcp's tools are public reads by design. Authenticated tools are out of scope. Publishers needing auth should front the Worker with their own auth layer or wait for a future cf-webmcp version that supports it.

Bot policy

  • AI-bot UA rules in robots.txt (User-agent: GPTBot, ClaudeBot, etc.). Publisher policy. cf-webmcp only augments robots.txt to disallow its own private namespace; it does not opine on whether GPTBot is allowed to crawl your homepage.
  • Content Signals. Publisher content policy, including the use=immediate|reference|full extension that Cloudflare's managed robots.txt writes (Content-signal: search=yes, ai-train=no, use=reference). Belongs in the CMS, the origin, or Cloudflare's zone settings. cf-webmcp's robots.txt merge mode preserves any Content-Signal lines already present; it does not emit its own. See the "Cloudflare AI crawler defaults" section in docs/deployment.md for how those zone defaults interact with a cf-webmcp deployment.
  • Web Bot Auth. Bot signs requests; server verifies. Server-side verification is a security policy concern, not a WebMCP discovery concern.

Origin

  • API discovery for the publisher's other APIs. cf-webmcp does not crawl your origin to find other APIs and add them to the catalog. If you have OpenAPI documents or other APIs, you publish them in /.well-known/api-catalog yourself; cf-webmcp's merge mode preserves what's there.
  • Markdown content negotiation. If origin serves HTML, that's what gets proxied. cf-webmcp does not convert pages to Markdown on the fly.

Commerce

  • x402, MPP, UCP, ACP, or any agentic-commerce protocol. Distinct space. Not WebMCP.

General-purpose stuff

  • Image transformation, A/B testing, analytics, edge auth, geo-routing. Worth doing, not by cf-webmcp.

Adjacent agent-readiness surfaces

The broader "agent-ready website" landscape includes surfaces beyond WebMCP discovery: markdown source endpoints with Accept: text/markdown negotiation, AI-crawler preferences via robots.txt Content-Signal, A2A agent cards, MCP server cards, web-bot-auth, schemamap, DNS-AID. specification.website (Joost de Valk) documents and ships these as a worked example. cf-webmcp deliberately covers only the subset that is WebMCP discovery; publishers wanting the rest can layer them on top of the proxied origin, or take them straight from that reference.

How feature requests get triaged

If a proposed feature is on the in scope list above, file an issue and let's discuss.

If it's on the out of scope list, the answer is "not here, but you can do it in your own Worker or origin." We're happy to suggest where the right place is.

If it's adjacent to WebMCP and you think it belongs, make the case in an issue and we'll evaluate against the "is this WebMCP discovery?" test. The bar to expand scope is high - tightly-scoped projects stay maintainable; sprawling ones don't.