IETF RFC MCP Server

A Model Context Protocol server that gives an LLM first-class access to the IETF document corpus — RFCs, Internet-Drafts, the STD/BCP/FYI series and published errata — running on Cloudflare Workers.

Endpoint: https://rfc.banbanlab.xyz/mcp

claude mcp add --transport http ietf-rfc https://rfc.banbanlab.xyz/mcp

For Claude Desktop and other clients:

{
  "mcpServers": {
    "ietf-rfc": {
      "type": "http",
      "url": "https://rfc.banbanlab.xyz/mcp"
    }
  }
}

No authentication — the RFC corpus is public.

Tools

Tool	What it does
search_rfcs	Find RFCs by title, optionally also abstract
get_rfc_metadata	Status, date, authors, abstract, keywords, series membership
list_rfc_sections	Section outline with per-section sizes
get_rfc_section	One section including its subsections
get_rfc	Full text, windowed by offset/limit
resolve_reference	BCP 14 → RFC 2119 + RFC 8174; draft names → RFCs
get_rfc_relations	Obsoletes/updates, and the chain to the current document
get_rfc_errata	Errata with original text, correction and status
search_internet_drafts	Work in progress, not yet published as RFCs

RFCs are long — RFC 9110 alone is half a megabyte — so the intended path is list_rfc_sections then get_rfc_section, not get_rfc. The tool descriptions say so, which is what steers the model.

Design

Stateless, so no Durable Object

Cloudflare's own MCP guidance points at McpAgent, which is backed by a Durable Object. Every tool here is a pure lookup with nothing to remember between calls, so the state a Durable Object exists to hold does not exist. The server instead uses the MCP SDK's WebStandardStreamableHTTPServerTransport in stateless mode: Request in, Response out, a fresh server per request.

The practical consequence is that this runs on a plain Worker, with no Workers Paid requirement and one less hop per call.

The index is built offline, not in the Worker

Two things callers want have no per-document endpoint upstream — you can only download the whole dataset:

Dataset	Size	Provides
rfc-index.xml	~14 MB	STD/BCP/FYI membership, draft → RFC mapping
errata.json	~11 MB	every erratum ever filed

Parsing either inside a request would exhaust a Worker's CPU budget on every call. scripts/build-index.mjs therefore downloads and reshapes them on a laptop or in CI, and uploads the result to KV. The Worker only ever reads one small value per lookup and never writes.

Errata are sharded by RFC number in blocks of 100. That number falls out of two limits pulling opposite ways: one key per RFC would mean ~2,500 writes per rebuild, over KV's free-tier allowance of 1,000 writes/day, while a single key would put megabytes of JSON.parse back into the request path.

Text parsing is the hard part

The canonical plain-text rendering spans two incompatible eras:

• Pre-2019 RFCs are paginated — a footer, a form feed and a running header every 58 lines, landing in the middle of sentences.
• xml2rfc v3 RFCs have no page breaks but are much longer.

src/rfctext.ts normalises both. Splitting on the form feed makes the de-pagination exact: the footer is always the last non-blank line before the break and the header the first after it, so neither has to be pattern-matched against the whole document, where [Page 3] might legitimately appear inside a quoted example.

Section detection keys on headings sitting at column 0, since body prose is always indented. The earliest RFCs break that rule by centring top-level headings — RFC 791 sets 1. INTRODUCTION at column 28 while its body sits at column 2 — so centred lines are accepted too, but only when isolated between blank lines and free of column alignment. Without those extra conditions the rule swallows RFC 9110's status-code registry, RFC 791's bit-pattern tables and RFC 9293's ASCII diagrams.

The parser is checked against nine real RFCs spanning 1981 to 2022, not just synthetic fixtures.

Caching

Every upstream subrequest is pinned to the Cloudflare edge cache via cf.cacheTtl: 30 days for RFC text (immutable once published), 7 days for metadata, 1 hour for search and draft state. Parsed documents are additionally memoised per isolate, capped at four, because section browsing is inherently repetitive — list the outline, then pull two or three sections.

The RFC Editor and the Datatracker are volunteer-run. Being a polite consumer of them is a design requirement, not an optimisation.

Development

npm install
npm test              # parser unit tests
npm run typecheck
npm run dev           # local server at http://localhost:8787

Deployment

npx wrangler kv namespace create RFC_INDEX   # once; put the id in wrangler.jsonc
npm run push-index                           # build and upload the lookup index
npm run deploy

GET /health reports whether the index is present.

The index is refreshed weekly by .github/workflows/refresh-index.yml, which needs a CLOUDFLARE_API_TOKEN repository secret with Workers KV Storage: Edit permission, plus CLOUDFLARE_ACCOUNT_ID.

Data sources and attribution

Data comes from rfc-editor.org and the IETF Datatracker. This project is not affiliated with or endorsed by the IETF, the IETF Trust or the RFC Editor. RFCs themselves are published under the IETF Trust Legal Provisions.

Licence

MIT — see LICENSE.