Loading ToolBench
A remote MCP server for IETF RFCs, Internet-Drafts, STD/BCP series and errata — running on Cloudflare Workers
Strong tool naming (all verb-prefixed), comprehensive parameter schemas with types and descriptions, and well-written descriptions (avg 150 chars, within 10-1024 baseline). All 9 tools have clear input schemas with proper JSON Schema structure. Output schemas are documented in descriptions. Error handling is present but generic. Main gaps: no explicit output schema definitions in code, no error recovery guidance, and missing idempotency/destructiveness annotations despite read-only risk classification.
Full text, windowed by offset/limit. For long documents, prefer list_rfc_sections followed by get_rfc_section.
Published errata with original and corrected text. Filter by status (Reported, Verified, Held for Document Update, Rejected, Verified, Closed) and type (Technical, Editorial).
Status, publication date, authors, abstract, keywords, STD/BCP membership and the obsoletes/updates relationships for one RFC. Start here before fetching any body text — the abstract alone often answers the question.
Obsoletes/updates chain to the current document. Follow the chain of updates to find the current RFC when an older one has been superseded.
Return the text of a single section, including its subsections. Accepts "4", "4.2.1", "Appendix A" or a front-matter heading such as "Abstract". This is the preferred way to read an RFC.
Return the section outline of an RFC: numbers, titles and sizes. This is the cheap way to navigate a long document — call it first, then pull only the sections you need with get_rfc_section.
No explicit output schema documentation in tool definitions. While descriptions mention what is returned, formal JSON Schema output types are absent from the tool registration code.
Error handling lacks recovery guidance. Tools return errors but do not suggest next steps (e.g., 'RFC not found, try search_rfcs() with a keyword').
Tool annotations (readOnlyHint, idempotentHint) are declared in FEATURES but not visible in tool definitions. All tools are read-only and idempotent, these should be explicitly marked in the schema.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 83 | 2026-07-28+ | v2 |
Expand BCP/STD/FYI numbers and draft names to their RFC equivalents. Accepts "BCP 14", "STD 97", "FYI 42" or a draft name like "draft-ietf-httpbis-semantics".
Work in progress, not yet published. Search for Internet-Drafts by title or abstract.
Find published RFCs whose title (optionally also abstract) contains the given text. Use this when you know roughly what a document is about but not its number. Matching is substring-based, not semantic, so prefer short distinctive terms such as "QUIC" or "OAuth" over full questions.
Pagination parameters (limit, offset) lack explicit guidance on behavior when results are exhausted or when offset exceeds total count.
Parameter 'rfc' accepts string|number but description does not clarify format variations (e.g., 'RFC 9110', '9110', 9110 all valid). Ambiguity may cause LLM to pass invalid formats.