RFC AI Tooling gives developers a choice between an installable agent skill and an MCP server for searching roughly 9,800 IETF RFCs. Both use the same standard-library-only Python core to find documents, read individual sections and flag specifications that have been obsoleted, according to the project’s GitHub README.
The MIT-licensed project addresses a practical problem in AI-assisted development: an agent may need a few paragraphs about HTTP caching or TLS, but retrieve an entire specification, or cite a superseded one. RFC AI Tooling makes the retrieval smaller and puts obsolescence information directly in the results.
The important choices are operational. A local coding agent can use the skill through its shell. A desktop client can launch the MCP server locally. A cloud session needs a reachable HTTP deployment, and that server has no built-in authentication.
Choose the Interface Based on Where Tools Run
The skill and MCP server share their retrieval core, so the main decision is how the agent accesses tools, not which interface has better RFC coverage.
The README recommends the following arrangement:
| Agent environment | Recommended interface | Practical requirement |
|---|---|---|
| Command-capable clients such as Claude Code, Codex CLI, Cursor or Zed | Installable skill | The agent must be able to run commands on the machine |
| Claude Desktop | MCP server over stdio | The client launches a local server process |
| Cloud sessions such as claude.ai | Self-hosted MCP server over HTTP | The session needs a reachable endpoint with appropriate access controls |
A local shell gives an agent more flexibility than a fixed set of MCP tools. The README specifically points to using shell utilities such as rg over the downloaded corpus. For an agent that already runs commands, I’d start with the skill: adding a network service would introduce deployment work without changing the underlying RFC lookup behavior. That is a workflow judgment based on the documented architecture, not a hands-on comparison. Source: project README
The documented skill installation command is:
npx skills add shbernal/rfc-ai-tooling
This installs the repository’s skill. Its RFC lookup script uses Python’s standard library and requires no separate pip installation.
For an MCP-capable desktop client, the README provides this configuration:
{
"mcpServers": {
"rfc": {
"command": "uvx",
"args": ["mcp-server-rfc"]
}
}
}
With uvx available, the client launches mcp-server-rfc; the README says uvx fetches the package from PyPI on first run. These are the project’s documented setup examples, not commands executed for this article.
Section Retrieval Makes the Savings Explainable
RFC AI Tooling lets an agent list a document’s headings with line numbers, then retrieve a section by number or heading. It also strips page headers, footers and form feeds from the text.
A size guard reinforces that workflow: a read exceeding 1,500 lines is refused unless it is a named-section read. The refusal reports the size and explains how to narrow the request. This is a guard against oversized reads, not a universal context limit. A sufficiently long named section can still pass through. Source: retrieval documentation
The project’s headline efficiency claim comes from six published examples:
| RFC and selected section | Whole-document estimate | Section estimate |
|---|---|---|
| RFC 9110, §15.5.5: 404 Not Found | 125,700 | 177 |
| RFC 9000, §19.3: ACK Frames | 100,900 | 1,742 |
| RFC 8446, §4.1.2: Client Hello | 78,100 | 1,865 |
| RFC 5321, §4.2: SMTP Replies | 52,800 | 4,003 |
| RFC 6749, §5.2: Error Response | 38,000 | 935 |
| RFC 9111, §4.2: Freshness | 21,100 | 2,531 |
These are the author’s approximate token counts, calculated as bytes divided by four from rfc.py version 0.5.0 output. They are not tokenizer-specific measurements. The author reports a median reduction of 41 times across these examples. Source: published measurements and methodology
The spread is more useful than the headline alone. Using the rounded figures in the table, the reduction ranges from about eight times for caching freshness to about 710 times for the short 404 section. The result depends heavily on how narrow the question is and how much of the document answers it.
That supports a practical conclusion: section-level retrieval is especially valuable for focused implementation questions. It does not demonstrate a universal 41-fold reduction in an agent’s total token use. Search results, tool instructions, follow-up retrievals and the model’s answer also consume context.
My view is that selecting the right evidence is the stronger benefit. A small section gives the agent a specific passage to cite. It still needs surrounding definitions or related sections when the question depends on them; the published size comparison does not measure answer accuracy or whether each selected section was sufficient.
Obsolescence Warnings Add a Separate Guardrail
RFC AI Tooling attaches obsolescence information from the RFC index to every result. A superseded document receives a prominent banner identifying its replacements.
The README uses RFC 2616 as its example: the HTTP specification has been obsolete since 2014. A sensible agent workflow is to search, inspect the obsolescence metadata, follow the replacement documents where appropriate, list their sections and retrieve the relevant passage. Source: obsolescence behavior and example
Putting that information in each result matters because an agent may never read a document’s opening header. A warning delivered during discovery can affect which document it opens next.
An obsolescence flag is still a signal that needs interpretation. The documented mechanism reports the index’s obsolescence field; it does not prove that every unflagged RFC is the right authority for a particular implementation. Historical behavior may also require reading an older specification deliberately.
For developers evaluating the tool, I’d check two things separately: whether the agent noticed a replacement warning, and whether its final citation points to the section that supports its answer. Retrieving fewer bytes cannot compensate for choosing the wrong document.
Full-Text Search Needs a Local Index
Title search works without downloading the full-text section index. Searching inside the RFC corpus requires an additional sync step.
For the MCP server, the documented command is:
uvx mcp-server-rfc sync --index
The skill has a corresponding command, with <skills-dir> replaced by the directory where it was installed:
python3 <skills-dir>/rfc-lookup/scripts/rfc.py sync --index
Both write to the same directory, so one download can serve both interfaces on the same machine. The README describes a SQLite file containing compressed RFC documents and an FTS5 index organized by section. Full-text searches therefore return sections as results. Source: full-text search setup
Successful title lookup does not mean full-text search is ready. On an HTTP deployment, the section index must exist on the server; the README says full-text search returns an error without it. Other operations need only the roughly 2 MB RFC index.
The section index is useful when a developer knows a concept but not the document title. It can take the agent from a phrase inside the corpus to a candidate section, after which the same obsolescence check and focused read still apply.
Frequently Asked Questions
3 questions
1Does RFC AI Tooling Bundle the RFC Corpus?
No. The README says neither distribution ships RFC text; documents come from the RFC Editor on demand. Full-text search requires downloading the local section index.
