RFC lookup

Name: RFC lookup
Author: shbernal

本地服务

github.com/shbernal开发工具15 天前更新

代码仓库

关于 RFC lookup

用于查询 RFC 规范的 MCP 服务，支持按章节搜索，并提示规范是否已被取代。适合自身无法运行命令行的客户端。

主要功能

01搜索 RFC 标题和全文
02列出章节标题与行号
03读取指定章节或行范围
04标记已被取代的规范
05限制过长读取

适用场景

01核查 RFC 的当前状态
02先定位相关章节再阅读
03确认引用的规范是否已过时

MCP 相关

通过 stdio 或 HTTP 向 MCP 客户端提供 RFC 搜索、章节列表和文档读取工具。

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置

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

启动命令uvx mcp-server-rfc

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包

pypimcp-server-rfc0.6.0stdio

工具

收录的工具列表 · 更新于 5 天前

参数	类型	必填
limit	integer	否
query	string	是
regex	boolean	否
scope	string	否

详细介绍

mcp-server-rfc

一个读取 RFC 语料的 MCP 服务，所需令牌减少 40 倍，并标记已废弃的规范。

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

无需克隆、无需虚拟环境，也无需路径。这就是全部安装过程。客户端会在你的机器上启动服务，并通过 stdin 和 stdout 与其通信。

客户端显示服务已连接，不代表它一定用过该服务；模型也很可能直接凭记忆回答 RFC 问题。在 Claude Desktop 中，每个服务的日志只记录握手，因此无法据此判断是否实际使用了服务——docs/desktop-verification.md 说明了在哪里能找到实际证据。

工具

工具	功能
`search_rfcs`	搜索标题，或搜索每份 RFC 的全文；如果存在章节索引，则按章节排序
`list_sections`	列出 RFC 的标题和行号——开销最低的首次调用
`get_rfc`	读取一个章节或一个行号范围

有章节索引时，全文查询使用词语；每条结果对应一个章节，按 BM25 排序，并包含传给 get_rfc 的章节编号，以及最匹配的行。没有章节索引时，全文搜索会改用 rg 或 grep 搜索同步的镜像；此时查询是字面字符串，结果为整份 RFC；设置 regex=true 可在该搜索和标题搜索中启用模式匹配。tool 字段会标明后端。标题搜索会优先显示当前 RFC，再显示已被取代的 RFC，因此结果在达到 limit 上限时截断，也会保留你需要的文档，而不是它取代的文档。

get_rfc 会拒绝读取超过 1500 行且未指定章节名称的请求，并返回内容长度以及指向 list_sections 的提示，而不是将模型只问了一个问题的规范塞满上下文；将 start_line 设为 1 也无法绕过此限制。full=true 可覆盖此限制。按名称请求的章节绝不会被拒绝：list_sections 会报告每个章节的长度，max_lines 则限制任何读取的行数，因此你可以知情选择，而不是被直接拦下。

每条响应都会附带横幅，显示 RFC 的状态，并在适用时警告该文档已被取代：

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

这正是使用此工具、而不是让模型自行获取 rfc-editor.org 内容的原因。模型引用过时规范时，往往信心十足。

全文搜索

无需设置即可使用，按需获取文档。全文搜索还需要章节索引，用户可通过 shell 下载：

uvx mcp-server-rfc sync --index

索引约为 270 MB，来自此项目的 GitHub releases，并会根据其公布的 SHA-256 校验。它按 BM25 对章节排序，并从磁盘提供所有读取内容，因此服务不再需要从 RFC Editor 获取文档。uvx mcp-server-rfc sync 则会从由志愿者维护的 RFC Editor rsync 镜像复制语料，生成 512 MB 的文本文件；rg 和 regex=true 搜索的就是这些文件。

运行服务的命令也用于运行 CLI：sync 用于下载，status 用于报告已有内容，uvx mcp-server-rfc <command> --help 可查看其他命令。若在缺少索引和镜像的情况下请求全文搜索，服务返回的错误中也会列出这个命令。

两者都是可选项。服务有意不提供同步工具：是否在某人的磁盘上存放数百 MB 数据，应该由个人决定，而不是由模型决定。

如果索引或镜像已经存在——例如已为配套技能完成同步——此服务会自动使用它。它会在平台的数据目录中查找：$XDG_DATA_HOME/rfc-ai-tooling，或者 Windows 上的 %LOCALAPPDATA%\rfc-ai-tooling；如果这些目录不存在，则回退到 ~/.local/share/rfc-ai-tooling。若要指定非默认位置，请设置 $RFC_MIRROR；在没有主目录的容器中，应传入该变量或使用 --mirror。

HTTP 模式

上面的配置使用 stdio 传输，需要客户端在你的机器上启动一个进程。在云端运行的会话——网页上的 claude.ai、Cowork——无法做到这一点，也没有任何配置能解决这个问题。对于这些会话，必须将服务部署到它们能够访问的地方：

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

RFC_TRANSPORT、HOST 和 PORT 也会从环境中读取。仓库中包含用于此配置的 Dockerfile 和 fly.toml。此服务没有公开实例，也没有计划提供——如果你想要一个实例，就需要自行托管，并在其前面设置身份验证，因为此服务没有身份验证功能，否则任何人都可以通过它访问由志愿者运营的镜像。

全文搜索仅在章节索引位于服务端磁盘上时才能在托管环境中使用（在该处运行 sync --index）。没有索引时，托管实例会返回相应错误，而不是悄悄地将请求当作标题搜索处理。无论是否有索引，过时提示横幅、章节读取和未限定读取防护都能正常工作，因为它们只需要 2 MB 的 RFC 索引。

如果你的客户端有 Shell

改用技能即可——Claude Code、Codex CLI、OpenClaw、Cursor 和 Zed 都符合条件。它能以更少的环节完成同样的工作，并为 Agent 提供针对语料库的 ripgrep：

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

此服务面向没有提供 Shell 的客户端。Claude Desktop 是最典型的例子：它的聊天功能无法在你的机器上运行命令，但可以在那里启动此服务。

源码、问题反馈和技能：https://github.com/shbernal/rfc-ai-tooling

MIT。

支持 Markdown

登录后评论