A Model Context Protocol server for fetching ietf documents for LLMs
This MCP server provides three READ_ONLY tools for accessing IETF RFC documents. While the tools have basic descriptions and input schemas, significant quality gaps limit the score. Tool descriptions are present but lack actionable context (no guidance on when to use each tool, no error recovery hints). Parameter descriptions are minimal or absent. Output schemas are not documented. The server uses FastMCP framework with STDIO-only transport, limiting remote accessibility. No error handling patterns, no pagination guidance for potentially large result sets, and no tool annotations (readOnlyHint, idempotentHint) despite all three tools being read-only. Tool naming is reasonably clear (verb_noun pattern), but parameter naming could be more explicit (e.g., 'max_lines' vs 'limit'). The search tool returns unstructured results without pagination support, which could produce hundreds of matches for broad keywords.
Get an RFC document by its number in RFC editor Index with pagination support
Get the total number of IETF RFC documents available in RFC editor Index
Search for IETF RFC documents from RFC Editor Index by keyword in their titles
Missing output schema documentation. No tool documents what fields are returned or what structure the LLM should expect. LLMs cannot plan downstream actions or extract necessary data without knowing the response shape.
search_ietf_rfc_by_keyword lacks pagination. Returns unstructured list with no limit, offset, or cursor. A broad keyword search could return hundreds of matches, wasting context window and degrading LLM reasoning.
No tool annotations despite all tools being read-only and idempotent. Missing readOnlyHint and idempotentHint annotations that would guide agent planning and enable caching.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 12 | - | v1 |
Minimal parameter descriptions. 'start_line' and 'max_lines' lack explanation of their purpose, valid ranges, or interaction. Parameter 'keyword' in search tool has no guidance on partial vs full-word matching, case sensitivity, or performance expectations.
No error handling guidance. If RFC number is invalid, or network request fails, the LLM receives only a stack trace or generic error. No recovery hints (e.g., 'Try list_ietf_docs_number first to see available RFC numbers').
Tool descriptions lack context for LLM decision-making. When should an agent call search_ietf_rfc_by_keyword vs list_ietf_docs_number? The descriptions do not contrast or guide the choice.
get_ietf_doc description in docstring mentions 'number: str (e.g., "1234")' but function signature declares 'number: int'. Type mismatch in documentation creates ambiguity.