RFC AI Tooling: 40x fewer tokens while reading the RFC corpus

Two ways to give an AI agent the IETF RFC corpus: a skill and an MCP server. Both run the same stdlib-only Python core, so they find, read and flag documents identically. No RFC text ships with either; documents come from the RFC Editor on demand.

• Obsolescence on every result. A superseded RFC says so in a banner the model can't miss:!! OBSOLETED BY: RFC 7230, 7231, ...
• Section reads. List an RFC's headings with line numbers, then read only the section that answers the question.
• Search. By title out of the box, or across the full text of all ~9,800 RFCs once you sync a local mirror.
• Clean text. Page headers, footers and form feeds are stripped.
• A guard on oversized reads. A read over 1500 lines that isn't a named section is refused, with its size and how to narrow it.

The numbers behind the chart #

RFC and section	Whole RFC	One section
RFC 9110 HTTP Semantics, §15.5.5 404 Not Found	125.7k	177
RFC 9000 QUIC, §19.3 ACK Frames	100.9k	1,742
RFC 8446 TLS 1.3, §4.1.2 Client Hello	78.1k	1,865
RFC 5321 SMTP, §4.2 SMTP Replies	52.8k	4,003
RFC 6749 OAuth 2.0, §5.2 Error Response	38.0k	935
RFC 9111 HTTP Caching, §4.2 Freshness	21.1k	2,531

The median saving is 41x, the figure behind "40x fewer tokens". Tokens are approximated as bytes divided by 4, measured from rfc.py 0.5.0 output. assets/charts/context_sizes.json has the raw measurements.

Agents cite dead specifications with confidence. RFC 2616 has been obsolete since 2014, and it's still the first thing most models reach for on HTTP. Every result here carries the RFC index's obsolescence field, so the agent follows the replacement before it quotes anything.

This project replaces mcp-server-ietf, which is unmaintained.

	rfc-ai-tooling	mcp-server-ietf	Model fetches rfc-editor.org
Flags obsoleted RFCs	On every result	No	Only if it reads the header
RFCs below 1000, like IP and TCP	Yes	No, its index parser expected zero-padded numbers	Yes
Full titles	Yes	Cut at the first period, so RFC 2616 is "HTTP/1"	Yes
Newly published RFCs	Index refreshes	Index downloaded once	Yes
Read one section	By number or heading	Line ranges only	Whole document
Full-text search	Ranked by section, with a downloaded index	Titles only	No
Install	One config line, or none for the skill	Clone and pip install	Nothing

Use the one that matches where your agent's tools run.

Your client	Use	Why
Claude Code, Codex CLI, OpenClaw, Cursor, Zed, or anything that runs commands on your machine	The skill	The agent gets the whole shell, including rg over the corpus, instead of three fixed tools
Claude Desktop	The MCP server over stdio	Desktop has no shell, but it spawns MCP servers on your machine
claude.ai on the web, Cowork, other cloud sessions	The MCP server over HTTP, hosted by you	A cloud session can't reach a process on your machine

There's no public instance of the server, and none is planned.

Install from this repo with skills:

npx skills add shbernal/rfc-ai-tooling

The skill is a single stdlib-only Python script, with nothing to pip install.

Add this to your client's MCP configuration. uvx fetches mcp-server-rfc from PyPI on first run.

{
  "mcpServers": {
    "rfc": {
      "command": "uvx",
      "args": ["mcp-server-rfc"]
    }
  }
}

I've tested it end to end in Claude Desktop on Linux. macOS and Windows should work, but I haven't checked them. docs/desktop-verification.md shows how to tell whether Desktop really called the tools.

Self-host over HTTP for cloud sessions #

The same binary serves HTTP:

mcp-server-rfc --transport http --host 0.0.0.0 --port 8080

mcp/Dockerfile and mcp/fly.toml deploy it as a container:

docker build -t mcp-server-rfc mcp/ && docker run --rm -p 8080:8080 mcp-server-rfc

Then add https://<your-app>/mcp as a custom connector in claude.ai, which needs a Pro, Max, Team or Enterprise plan.

• There's no authentication. A public instance is an open proxy in front of a volunteer-run mirror, so put it behind auth or keep the URL private.
• Full-text search needs the section index on the server. Runsync --index there, or it returns an error. Everything else needs only the 2 MB RFC index.

1. Install the skill or the MCP server.
2. Ask your agent a spec question, like "What does HTTP say about how long a cached response stays fresh?"
3. Check that it cites a current RFC by section, like RFC 9111 §4.2 , and not RFC 2616.

The agent runs the same loop you can run yourself: search, check obsolescence, list sections, read one.

Title search works with no setup. To search the text of every RFC, download the section index once.

For the skill, where <skills-dir> is where it was installed, like ~/.claude/skills:

python3 <skills-dir>/rfc-lookup/scripts/rfc.py sync --index

For the MCP server:

uvx mcp-server-rfc sync --index

Both write to the same directory, so one download serves both.

The index is a SQLite file holding every RFC, compressed, and an FTS5 index over each section. A search returns sections ranked by BM25, with the number to read next:

$ rfc search "how long can a cache serve a stale response" --fulltext
RFC 9111 — HTTP Caching  [INTERNET STANDARD]
   §4.2.4 Serving Stale Responses  (line 784, 17 lines)
   790: A cache MUST NOT generate a stale response if it is prohibited by an

Reads come from the index too, so nothing is fetched from the RFC Editor after that. On the retrieval eval it finds the answering section in its top 10 for more than half of the held-out questions; ripgrep over the corpus finds it for none.

Without the index, --fulltext falls back to rg or grep over a synced mirror of the corpus as plain files, which is also what --regex needs:

uvx mcp-server-rfc sync

	Download	On disk	Source
sync --index	About 270 MB	360 MB	This project's GitHub releases, checked against a published SHA-256
sync	512 MB, about 5 minutes	512 MB	The RFC Editor's public rsync mirror, capped at 2 MB/s by default ( --bwlimit )

Neither starts on its own, and the skill tells agents not to run them unasked. rfc index build makes the index from a synced mirror, in about two and a half minutes.

flowchart LR
    editor[("RFC Editor")]
    releases[("GitHub releases")]
    index[("Section index<br/>360 MB, optional")]
    mirror[("Local mirror<br/>512 MB, optional")]
    core["core/rfc.py<br/>stdlib only"]
    skill["Skill<br/>scripts/rfc.py"]
    mcp["mcp-server-rfc<br/>stdio or HTTP"]
    shell["Agent with a shell"]
    client["MCP client"]

    editor -- "HTTPS, on demand" --> core
    editor -. "rsync, when you run sync" .-> mirror
    releases -. "when you run sync --index" .-> index
    index --> core
    mirror --> core
    core -- "vendored copy" --> skill
    core -- "vendored copy" --> mcp
    skill --> shell
    mcp --> client

core/rfc.py is the only implementation. The skill and the MCP server each carry an identical copy, and CI fails if one drifts. The core parses the RFC Editor's index for titles, status and what obsoletes what, then fetches documents over HTTPS and caches them. With the section index, it reads from that file and ranks sections with SQLite's FTS5. With only a synced mirror, it reads from disk and searches with rg or grep.

• skill/SKILL.md : every CLI command and how the agent is told to use them
• mcp/README.md : the MCP tools and their arguments
• docs/desktop-verification.md : proving Claude Desktop called the tools
• CHANGELOG.md : breaking changes are listed there, so read it before upgrading
• CONTRIBUTING.md : layout, tests and release rules
• NOTICE : attribution, and the terms that apply to RFC text

source & further reading

github.com — original article A free, open-source WYSIWYG Markdown editor for macOS, Windows and Linux Papers with Code is now open-source Show HN: Eavesong – self-hosted product mention monitoring