RFC lookup

io.github.shbernalPublished by GitHub account shbernalv0.6.1Updated Oct 30, 2026

40x fewer tokens while reading the RFC corpus and flag obsoleted specs.

Overview

AI-generated overview

Lets an assistant search IETF RFCs, list an RFC's sections and read one section at a time, flagging specs that have been obsoleted.

What you can do
  • Search RFCs by title, or full text when a section index or local mirror is present
  • List an RFC's numbered headings with line numbers and section lengths
  • Read a single section by number or heading text, or a line range, with a size cap on unscoped reads
  • Show each response with a status banner warning when a spec has been obsoleted by newer RFCs
When to use it
Useful when you ask an assistant about internet standards, protocols or HTTP details and want answers grounded in the actual RFC text rather than recalled from memory, especially for clients like Claude Desktop that cannot run shell commands themselves.
Requirements
Runs locally over stdio, launched with uvx from the mcp-server-rfc PyPI package, so Python and uv are needed. Title search and section reads work with no setup; full-text search needs a section index or mirror downloaded separately with the sync command, about 270 MB or 512 MB. Optional environment variables RFC_MIRROR, RFC_CLI, RFC_TRANSPORT, HOST and PORT adjust paths and transport.
Before you install
The server has no authentication; if you host it over HTTP you must put authentication in front of it, or it becomes an open proxy to a volunteer-run mirror. Full-text search without an index falls back to fetching from the RFC Editor. Downloading the index or mirror puts hundreds of megabytes on disk and is left to the user, not the model.

Installation

In SourceWeft

  1. Open RFC lookup in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

mcp-server-rfc

An MCP server that reads the RFC corpus with 40x fewer tokens and flags obsoleted specs.

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

No clone, no virtualenv, no path. That is the whole installation. Your client spawns the server on your machine and talks to it over stdin and stdout.

A client showing the server as connected has not necessarily used it, and a model will happily answer an RFC question from memory instead. On Claude Desktop the per-server log records only the handshake, so it cannot tell you either way — docs/desktop-verification.md says where the evidence actually is.

Tools

ToolWhat it does
search_rfcsSearch titles, or the full text of every RFC, ranked by section, if the section index is present
list_sectionsAn RFC's headings with line numbers — the cheap first call
get_rfcRead one section, or a line range

With the section index, a full-text query is words, and each result is one section ranked by BM25, carrying the section number to pass to get_rfc and the line that best matches. Without it, full-text search falls back to rg or grep over a synced mirror, where the query is a literal string and results are whole RFCs; regex=true opts into pattern matching there and in titles. The payload names the backend in tool. Title results put current RFCs before superseded ones, so a page cut short at limit keeps the document you want rather than the one it replaced.

get_rfc refuses any read of more than 1500 lines that is not a named section, answering with its size and a pointer to list_sections rather than filling the context with a specification the model had one question about; a start_line of 1 does not get around it. full=true overrides it. A section you asked for by name is never refused: list_sections reports how long each one is, and max_lines caps any read, so the choice is informed rather than blocked.

Every response carries a banner with the RFC's status and, when it applies, a warning that it has been superseded:

RFC 2616 — Hypertext Transfer Protocol -- HTTP/1.1  [DRAFT STANDARD]!! OBSOLETED BY: RFC 7230, 7231, 7232, 7233, 7234, 7235

That warning is the reason to use this rather than let a model fetch rfc-editor.org itself. Models cite dead specifications with great confidence.

Full-text search

Works with no setup, fetching documents on demand. Full-text search additionally needs the section index, which the user downloads from a shell:

bash
uvx mcp-server-rfc sync --index

About 270 MB from this project's GitHub releases, checked against its published SHA-256. It ranks sections by BM25 and serves every read from disk, so the server stops fetching from the RFC Editor. uvx mcp-server-rfc sync instead copies the corpus as 512 MB of text files from the RFC Editor's volunteer-run rsync mirror, which is what rg and regex=true search.

The same command that runs the server runs its CLI: sync downloads, status reports what is present, and uvx mcp-server-rfc <command> --help covers the rest. It is also the command the server names in the error you get when full-text search is asked for without either.

Both are optional. The server deliberately does not expose a sync tool: hundreds of megabytes on someone's disk should be a person's decision, not a model's.

If an index or a mirror already exists — synced for the companion skill, say — this server picks it up automatically. It looks under the platform's data directory: $XDG_DATA_HOME/rfc-ai-tooling, or %LOCALAPPDATA%\rfc-ai-tooling on Windows, falling back to ~/.local/share/rfc-ai-tooling. Set $RFC_MIRROR to point at a non-default location — in a container with no home directory, that or --mirror is what to pass.

In a container, uvx on the host would write to the wrong disk. Keep the mirror in a named volume, fill it through the image, and set $RFC_CLI so the server's errors name that command instead of uvx mcp-server-rfc:

bash
docker build -t mcp-server-rfc mcp/docker run --rm -it -v rfc-mirror:/mirror mcp-server-rfc mcp-server-rfc sync --indexdocker run --rm -i -v rfc-mirror:/mirror -e RFC_TRANSPORT=stdio \  -e RFC_CLI="docker run --rm -it -v rfc-mirror:/mirror mcp-server-rfc mcp-server-rfc" \  mcp-server-rfc

HTTP mode

The config above is the stdio transport, which needs a client that can spawn a process on your machine. A session running in the cloud — claude.ai on the web, Cowork — cannot, and no configuration fixes that. For those, the server has to be deployed somewhere they can reach:

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

RFC_TRANSPORT, HOST and PORT are read from the environment too. The repository carries a Dockerfile and a fly.toml that do this. No public instance of this server exists and none is planned — if you want one, you host it, and you should put authentication in front of it, since the server has none and would otherwise be an open proxy to a volunteer-run mirror.

Full-text search works hosted only where the section index is on the server's disk (sync --index there). Without it, a hosted instance returns an error saying so instead of silently answering a title search. The obsolescence banner, section reads and the unscoped-read guard work either way, because they need only the 2 MB RFC index.

If your client has a shell

Use the skill instead — Claude Code, Codex CLI, OpenClaw, Cursor and Zed all qualify. It does the same things with fewer moving parts and gives the agent ripgrep over the corpus:

bash
npx skills add shbernal/rfc-ai-tooling      # from the repo, into .claude/skills/clawhub install @shbernal/rfc-lookup        # or the last released version

This server is for clients that give the model no shell of its own. Claude Desktop is the clearest case: its chat cannot run a command on your machine, but it will spawn this server there.

Source, issues and the skill: https://github.com/shbernal/rfc-ai-tooling

MIT.

Source: mcp/README.md at commit e763589

Tools

3

search_rfcs

Search RFCs. scope='title' matches all query terms against RFC titles and always works. scope='fulltext' searches the text of every RFC and needs either the section index or a local mirror the user has set up; it returns an error explaining what to run if there is neither. With the section index ('tool' is 'index'), the query is words, not a phrase: each result is one section, ranked by BM25 with headings weighted, carrying its 'section' number (null for the front matter), 'heading', 'line' and how many 'lines' it runs to, and a 'snippet' quoting its best line. Pass that section straight to get_rfc. Without the index ('tool' is 'rg' or 'grep'), the query is a literal string, each result is one RFC ranked by 'matching_lines', and 'matches' quotes a few lines with the section each falls in. regex=true opts into pattern matching, which only the mirror can do, in the backend's dialect. Results carry each RFC's status and obsolescence, and title results put current RFCs before superseded ones, so a page cut short at 'limit' keeps the replacement rather than the document it replaced. A 'note' says when the index could not be used. 'count' is how many results this page holds and 'total' is how many matched; when 'truncated' is true, report 'total' and raise 'limit' (at most 200) rather than counting the results you were given. An empty query is an error.

Parameterslimitqueryrequiredregexscope

list_sections

List an RFC's numbered headings with their line numbers and how many lines each one runs to. Cheap, and the right first call when you need part of a specification: use it to pick a section, then pass that section to get_rfc. The line counts are there to be read — a section of a few hundred lines is a normal read, and one running to four figures wants a subsection or a max_lines cap instead. Some pre-1990 RFCs have no numbered headings, in which case this returns an empty list and get_rfc's line range is the way in.

Parametersnumberrequired

get_rfc

Read an RFC. Call list_sections first and pass a section — whole RFCs average 53 KB and run past 1.6 MB, and reading one in full is almost never what the question needs. section accepts a number ('9.3.1') or heading text ('Idempotent Methods') and includes that section's subsections. Any read of more than 1500 lines that is not a named section is an error naming its size, not a silent context-filling dump; pass full=true only when the entire text is genuinely what you need. start_line and max_lines are 1 or more. max_lines caps any read, including a section, and is the way to take the first part of one that list_sections showed is long. start_line is the fallback for RFCs without numbered headings and cannot be combined with section. Page headers and footers are stripped. The response carries a banner naming the RFC's status and, if it has been superseded, what replaced it.

Parametersfullnumberrequiredsectionmax_linesstart_line

Version history

3
  1. v0.6.1LatestOct 30, 2026
  2. v0.6.0Oct 25, 2026
  3. v0.5.2Oct 24, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts