RFC MCP Server

Let AI agents read the RFC corpus with 40x fewer tokens, and flag obsoleted specs.

---

---

What it is

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.

Why

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.

Pick a surface

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

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

Install

Skill

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.

MCP server

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.

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

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

Quickstart

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.

Full-text search

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

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.

How it works

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.

More

• 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