MCP server for fast local llms.txt search and documentation management
Two tools with detailed schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, error handling, and composition guidance. The 'find' tool has comprehensive input parameter documentation with proper constraints (enums, ranges), but the 'blz' tool lacks detailed descriptions for several parameters and has ambiguous parameter relationships. Output schemas are not formally documented. Descriptions are adequate in length (both >100 chars) but lack actionable guidance for LLM selection and recovery. Tool names are clear but composition lacks explanation of when to use each tool or how they chain together.
Manage documentation sources: list, add, remove, refresh, validate, get info, view history, and lookup registry entries
Search, retrieve snippets, or get table of contents from indexed documentation sources
Output schemas not documented. Neither 'find' nor 'blz' include documented return types showing what fields LLMs will receive. This forces LLMs to guess at response structure and prevents downstream tool chaining.
'blz' tool description (127 chars) lacks actionable guidance. Does not explain WHEN to use 'blz' vs 'find', what distinguishes source management from searching, or what the LLM should expect from each action. 'Manage documentation sources' is generic, LLM cannot infer when to call this.
'blz' tool parameters lack descriptions for several fields: 'kind', 'query', 'reindex', 'all', 'limit', 'targetAlias' have no descriptions in the input schema. Without param descriptions, LLM cannot understand what values to pass or what effects they produce.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter relationships undocumented. 'blz' has conditional logic (e.g., 'alias' is required for add/remove/refresh/info/validate/history but not for list/lookup). No documentation states these dependencies, forcing LLM to guess or trial-and-error.
No error handling guidance in either tool. LLM receives no context about what to do if a source add fails (e.g., invalid URL, network error, or source already exists). No recovery suggestions or error classification (retryable vs user-fixable).
'find' tool has many optional parameters with interdependencies not documented: context, linePadding (alias), contextMode work together but relationships are silent. 'snippets' and 'query' appear mutually exclusive but descriptions don't state this.
'find' description does not explain when to use 'search' vs 'get' vs 'toc' action. 'action' is marked optional with inference from parameters, but the inference logic is hidden, LLM cannot reason about whether it should pass action explicitly or rely on inference.
Tool composition not explained. No description tells LLM the workflow: 'use blz list to discover sources, then find to search them' or 'blz add registers a source before find can query it'. Multi-tool workflows are silent.
No result limit enforcement documented in 'find'. Parameter 'maxResults' defaults to 10, but description does not state the hard cap or explain why limits matter for LLM token consumption. 'maxLines' is unbounded, can LLM request 10000 lines?
Source filter parameter ('source') uses oneOf with string | array but description does not clearly explain when to pass string vs array, or what 'all' means vs omitting the parameter.