Loading ToolBench
MCP server for fetch deepwiki.com and turn content into LLM readable markdown
The server defines 2 tools with reasonable parameter schemas and descriptions, but falls short of production-grade quality. Both tools have documented input parameters with types and constraints, but descriptions lack LLM-optimization depth and output schemas are not explicitly documented. Tool naming is clear and action-oriented (deepwiki_fetch, deepwiki_search), but descriptions mix implementation details with user intent. Error handling and recovery guidance are absent from both tool definitions.
Fetch a deepwiki.com repo and return Markdown
Download pages from a deepwiki.com, look for a case-insensitive substring, and return up to maxMatches short snippets with the match wrapped in **bold**. Required: • url – root Deepwiki repo • query – plain text (literal string) Optional: • maxDepth – crawl depth (default 1, like deepwiki.fetch) • maxMatches – limit on snippets (default 10) • mode – "aggregate" | "pages" (affects link rewriting only) • verbose – log progress to stderr
No documented output schema for either tool. LLMs cannot plan downstream operations or extract required fields without knowing the response structure (e.g., what fields does deepwiki_fetch return? Is it raw markdown? A structured object? What metadata is included?).
deepwiki_fetch description (126 chars) lacks actionable context. It does not explain WHEN to use this tool vs deepwiki_search, what happens on errors, or what the output format is. Description should follow the pattern: What does it do? When should LLM call it? What does it return?
Parameter 'url' in both tools accepts multiple formats (URL, owner/repo, 'owner repo', or library keyword) but lacks validation guidance. Description says 'should be' but does not state what happens if an invalid format is passed, or provide examples of valid forms the LLM should try.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 17 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 64 | - | v1 |
No error handling guidance. If a URL is invalid, a repo does not exist, or network timeout occurs, the tools do not document recovery paths. LLMs need to know: should they retry? Try alternative formats? Ask the user? This is especially critical for network-dependent tools.
deepwiki_search description includes implementation details ('Download pages from a deepwiki.com, look for a case-insensitive substring') rather than user-facing intent. It also lists 'Required' and 'Optional' parameters in the description instead of letting the schema declare this via required array.
deepwiki_search tool is commented out in src/index.ts (line 23: '// deepwikiSearchTool({ mcp } as McpToolContext)'). This tool is defined but not registered with the server. Either register it or remove the dead code.
Parameter descriptions are terse. 'mode' is described as 'Conversion mode' with enum values 'aggregate|pages' but does not explain when to use each mode or what the difference is for the LLM's decision-making.