Loading ToolBench
MCP server that provides a portable and enhanced alternative to editor-specific documentation rules (like Cursor Rules). It allows you to define project documentation and context in standard Markdown files, making them usable across any MCP-compatible AI coding tool.
This server has 3 tools with moderate quality. Tool naming follows verb-first conventions (get_, reindex_, list_) which is good. However, descriptions are present but somewhat generic. Input schemas are explicitly defined using Zod for 2 of 3 tools, but parameter descriptions are sparse or missing. The get_relevant_docs tool has the most complete schema with typed array parameters, but lacks granular parameter documentation. reindex_docs and list_indexed_docs accept empty input objects, which is fine for their purposes. No output schemas are documented in the source code, descriptions don't explain what each tool returns or what structure the LLM should expect. Error handling is minimal: tool implementations return simple text responses without guidance on failures or next steps. The server reads markdown files and serves them via MCP, which is a narrow, well-defined domain, but the tool definitions could be significantly improved to guide LLM usage.
Get relevant markdown docs inside this project before answering the user's query to help you reply based on more context.
Print a full count & summary of the docs in the index. Also shows the usage instructions for the `get_relevant_docs` tool. Useful for debugging. Will only show the first 20 docs in each category & a small preview of the content.
Reindex the docs. Useful for when you want to force a re-index of the docs because there were changes to the docs or the index
Output schemas not documented. Tool implementations return structured responses (text content arrays), but the source code contains no description of what fields, types, or structure the LLM should expect. LLMs cannot plan downstream operations or extract specific data when return types are undocumented.
Parameter descriptions are minimal or absent. The get_relevant_docs tool has two array parameters (attachedFiles, projectDocs) with basic descriptions, but they lack detail on format expectations, how to use them together, or what happens if both are omitted. LLMs rely on parameter descriptions to reason about when and how to invoke tools.
reindex_docs and list_indexed_docs accept empty input schemas ({}). While correct, the descriptions do not explain what these tools do when called, what triggers a reindex, whether it's safe to call repeatedly, or what the output will look like. Descriptions are under 150 characters and lack actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No error handling or recovery guidance. Tool implementations do not validate inputs, document failure modes, or return structured error messages. If an invalid file path is passed to get_relevant_docs, the LLM receives a generic error with no guidance on how to correct it.
No indication of which parameters are mutually exclusive or dependent. The get_relevant_docs tool accepts both attachedFiles and projectDocs as optional arrays, but the description does not clarify how they interact, whether both should be passed together, or what happens if only one is provided.