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

A new open-source project, rfc-ai-tooling, gives AI agents access to the roughly 9,800-document IETF RFC corpus through a skill and an MCP server that share a stdlib-only Python core, cutting token use by a median of 41x by reading single sections instead of whole documents. Measured from rfc.py 0.5.0 output, reading RFC 9110 §15.5.5 on 404 Not Found drops from 125.7k tokens for the whole RFC to 177 for the section, and RFC 9000 §19.3 on ACK Frames from 100.9k to 1,742. Every result carries the RFC index's obsolescence field so agents follow replacements before quoting, addressing cases like RFC 2616, obsolete since 2014, which the project says most models still reach for on HTTP; it replaces the unmaintained mcp-server-ietf.

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 https://github.com/shbernal/rfc-ai-tooling/blob/main/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 https://github.com/tizee/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 https://github.com/vercel-labs/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 https://pypi.org/project/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 https://github.com/shbernal/rfc-ai-tooling/blob/main/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 https://github.com/shbernal/rfc-ai-tooling/blob/main/mcp/Dockerfile and mcp/fly.toml https://github.com/shbernal/rfc-ai-tooling/blob/main/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. Run sync --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: bash $ 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 https://github.com/shbernal/rfc-ai-tooling/blob/main/docs/search-evaluation.md 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 https://github.com/shbernal/rfc-ai-tooling/blob/main/skill/SKILL.md : every CLI command and how the agent is told to use them - mcp/README.md https://github.com/shbernal/rfc-ai-tooling/blob/main/mcp/README.md : the MCP tools and their arguments - docs/desktop-verification.md https://github.com/shbernal/rfc-ai-tooling/blob/main/docs/desktop-verification.md : proving Claude Desktop called the tools - CHANGELOG.md https://github.com/shbernal/rfc-ai-tooling/blob/main/CHANGELOG.md : breaking changes are listed there, so read it before upgrading - CONTRIBUTING.md https://github.com/shbernal/rfc-ai-tooling/blob/main/CONTRIBUTING.md : layout, tests and release rules - NOTICE https://github.com/shbernal/rfc-ai-tooling/blob/main/NOTICE : attribution, and the terms that apply to RFC text