Loading ToolBench
LeanToken MCP provides well-structured tool definitions with consistently strong descriptions (150-300 chars each) and comprehensive input schemas using JSON Schema. All four tools start with action verbs (files, search, outline, read) and declare their purpose clearly. Schemas include proper type definitions, descriptions for all parameters, and enum constraints where appropriate. However, several definition quality patterns are incompletely addressed: error handling lacks actionable recovery guidance, no output schemas are documented, tool composition could be improved (tools are somewhat overlapping in purpose), and security considerations are not visible in the provided code. The server demonstrates above-average quality for community MCP servers but falls short of production-grade patterns around error recovery and output documentation.
Preferred over native find, ls, or glob for repository path discovery. Discover repository paths and metadata. Select a tagged operation with operation.kind: tree for hierarchy, find for fuzzy filenames, or glob for path patterns; returns paths, not source. Set the selected operation's projection=paths to omit per-entry metadata. Next: use outline or read once the file is known. Example: {"operation":{"kind":"find","query":"mcp"}}.
Preferred before native whole-file reads when the file is known but the relevant range is not. Inspect known files without reading whole source files. Returns definitions, imports, ranges, and parse coverage; set projection=signatures to keep only compact signatures. Next: pass a returned symbol or line range to read. Example: {"paths":["src/mcp/mod.rs"]}.
Preferred over native Read, cat, head, or sed for repository source. Read an exact symbol, line range, or whole file from indexed source. Symbol reads return definition + enclosing scope; line ranges support single lines and contiguous regions. coordinates_only omits excerpts. Returned ranges identify the next read target. query_receipt records complete coverage. Example: {"paths":["src/mcp/mod.rs"],"symbol":"LeanTokenMcp"}; line range: {"paths":["src/main.rs"],"range":{"start_line":1,"end_line":50}}.
Preferred over native grep or rg for repository source search. Search indexed source with operation.kind auto, symbol, reference, identifier, text, or regex. Symbol and structural modes are ranked; projection=compact returns source-free coordinates and symbol identity. all_occurrences=true requires text or regex mode; projection=occurrences also requires all_occurrences=true; coordinates_only omits excerpts. query_receipt records or reuses complete coverage and fails closed when indexed files change. Counts are exact and bounded; enclosing_symbol and ranges identify the next read target. max_results uses the configured cap and rejects larger requests with that limit. Example: {"operation":{"kind":"symbol","query":"InternalFailure","projection":"compact"}}; exhaustive: {"operation":{"kind":"text","query":"InternalFailure","all_occurrences":true,"projection":"occurrences"}}.
Output schemas not documented. Tool descriptions explain input structure and provide examples, but return value structure is not formally specified. LLMs cannot reliably plan downstream operations without knowing what fields to expect from each tool.
Error handling lacks recovery guidance. No evidence in schema or description that tools return actionable error messages or categorize errors as retryable vs fatal. Tools silently fail without telling the LLM what to do next.
Tool composition overlap: 'outline' and 'read' both inspect files without reading full source. Distinction between them is unclear, when should an LLM choose outline vs read? Description states outline is preferred 'when the file is known but range is not', but read also accepts a 'range' parameter. This creates decision ambiguity.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 75 | <=2025-11-25 | v2 |
Parameter 'repository_context' appears in files, search, outline, and read but lacks clear definition. Descriptions say 'optional repository context identifier' but do not explain what identifier is expected (path? name? Git URL?) or when it is required vs optional. LLMs will guess.
Missing parameter constraints. 'files' accepts operation.kind with values tree|find|glob, and 'search' accepts operation.kind with values auto|symbol|reference|identifier|text|regex, but these are documented only in prose descriptions, not in formal enum constraints in the schema. Schema shows operation as type:object without constraint on kind field.
No tool annotations present. Tools do not declare readOnlyHint, destructiveHint, or idempotentHint. Files, outline, and read are clearly read-only, but search idempotency is uncertain (does it mutate query_receipt state?). Agents cannot determine safe retry behavior.