mcp-server-rfc
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_rfcsA | 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. |
| list_sectionsA | 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. |
| get_rfcA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: list_sections maps document structure, get_rfc reads selected content, and search_rfcs finds RFCs or sections. The descriptions explicitly describe complementary workflows and warn about overlapping usage patterns such as line ranges versus section selection.
All tools follow a consistent verb_noun snake_case pattern: list_sections, get_rfc, search_rfcs. The naming is predictable and immediately readable.
Three tools is well-scoped for an RFC reading and search server. Each tool has a distinct, necessary function: inspecting structure, retrieving content, and searching.
The core lifecycle of finding, navigating, and reading RFCs is covered, including status and obsoletion metadata. Minor gaps exist around richer metadata or bulk RFC listing, but agents can work around these using search and section navigation.