Loading ToolBench
Ever been told to RTFM only to find there's no FM to R? MCP-RTFM is the solution - it helps you CREATE the F*ing Manual that people keep telling everyone to read! Transform your non-existent or unreadable docs into an intelligent, searchable knowledge base that actually answers those 'basic questions' before they're asked.
This server has 9 tools covering documentation lifecycle management. All tools are explicitly registered in src/index.ts with names, descriptions, and input schemas. However, there are systematic gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names are action-verb based (initialize_, read_, update_, search_, apply_, analyze_, get_, validate_, export_) which is good. Descriptions are present but brief (mostly 100-180 chars) and lack specifics about when to use each tool relative to others. Input schemas have type definitions and some field descriptions, but output schemas are entirely undocumented, LLMs cannot predict what fields these tools return. Error handling is minimal; tools will fail without guidance on recovery. The codebase shows competent implementation (markdown parsing, search, metadata tracking) but the tool interface is underspecified.
Analyzes the project codebase to extract key information and suggest documentation requirements
Generates a new documentation file using one of the available templates (standard, api, or workflow)
Exports documentation in various formats (markdown, html, json) for distribution or archival
Analyzes documentation to identify related documents based on shared tags, categories, and explicit references
Initializes documentation system for a project by creating .handoff_docs directory and generating default documentation files from templates
Reads and returns the content of a specific documentation file from the project's .handoff_docs directory
Searches across all documentation files using fuzzy search with caching support
No output schemas documented for any tool. LLMs cannot predict return structure, field names, or types. Forces agents to guess what fields are available, risking broken tool chains.
analyze_codebase and get_document_relationships lack clear descriptions of what they return and when to call them instead of other tools. 'Analyzes the project codebase' is too generic, does it extract imports, measure complexity, suggest missing docs, or something else?
No error handling or recovery guidance in any tool. If search_documentation returns no results, initialize_documentation fails on missing directory, or export_documentation hits invalid format, there is no actionable error message. LLMs receive failures with no guidance on next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Updates the content of a documentation file and regenerates metadata and search index
Validates documentation for completeness, consistency, and adherence to standards
Parameter 'overrides' in apply_template is typed as 'object' with no schema or description of valid keys/structure. LLMs cannot know what fields this object accepts or what values are valid.
search_documentation 'useCache' parameter defaults to true but caching behavior is undocumented. How long is cache valid? What triggers invalidation? Can an agent rely on consistent results across calls?
validate_documentation 'strict' parameter defaults to false but tool description does not explain what strictness means or when to enable it. LLMs cannot reason about trade-offs.
export_documentation 'format' parameter includes 'pdf' in enum but tool description never mentions PDF generation or its prerequisites. Is a PDF renderer required? Can it fail?
All tools accept 'projectPath' as a string with no validation rules. What format is expected? Absolute or relative? Unix or Windows paths? Must it exist? Can LLMs pass arbitrary strings?
apply_template 'fileName' parameter description says 'default: title converted to camelCase' but camelCase conversion rules are not specified. What if title contains special chars, numbers, or non-ASCII?
analyze_codebase 'depth' parameter ranges 1-3 but reasoning for these limits is not explained. Why not 0 or 5? What changes between depth levels?