Skip to main content
Glama
shbernal

mcp-server-rfc

by shbernal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

search_rfcs

Read-only

Search IETF RFCs by title or full text to locate relevant sections and check obsolescence status, returning only matching passages to reduce context.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
regexNo
scopeNotitle

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: fulltext prerequisites, backend-dependent result shapes, ranking behavior, obsolescence ordering, truncation semantics, and error behavior for missing index/mirror or empty queries. This is exactly the kind of information an agent needs to invoke the tool correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although dense, every sentence adds operational detail needed for a search tool with multiple backends and no schema descriptions. Scope behavior is front-loaded, and the length is justified by the complexity of the result and pagination semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameter descriptions in the schema, the description nevertheless explains result fields, ranking, snippets, status/obsolescence ordering, count/total/truncated handling, and error cases. It is complete enough for an agent to use the tool without guessing at return semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: scope values are explained, regex is tied to mirror-only pattern matching, limit is capped at 200 with truncation guidance, and query semantics differ explicitly between index word-based search and mirror literal-string search.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Search RFCs') and immediately clarifies the two scopes. It also tells the agent that matching sections should be passed to get_rfc, making the search-vs-retrieve boundary clear, even though list_sections is not named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit conditions for scope selection, fulltext prerequisites, regex limitations, and pagination/truncation handling. The main gap is that it does not explicitly contrast this tool with sibling tools like list_sections or get_rfc beyond noting that a section can be passed to get_rfc.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools