Loading ToolBench
MCP retrieval toolkit for coding agents - provides code indexing, search, git integration, and grammar management
Veil demonstrates solid foundation with 24 well-organized tools, explicit tool annotations, and comprehensive parameter schemas. Descriptions follow a consistent pattern ('Use when you need...') that is adequate but formulaic. Most tools have full input schemas with proper type definitions and parameter descriptions. However, descriptions lack context about WHEN to prefer one tool over another and how tools compose. Output schemas are not documented in source code. Error handling guidance is absent. Parameter descriptions are minimal (8-15 chars), meeting the floor but not best practice. The server exhibits good naming discipline (verb_noun), proper schema structure, and thoughtful tool composition, but falls short of production-grade documentation expected in enterprise settings.
Use when you need a full index rebuild.
Use when you need full content for one chunk id.
Use when you need cache or latency diagnostics.
Use when you need one broad triage pass because intent is unclear before narrowing.
Use when you need markdown-first page content from a URL.
Use when you need file path matches.
Use when you need GitHub issues, PRs, checks, or repo bootstrap.
Output schemas not documented in source code. While input schemas are comprehensive, there is no visible documentation of return types or output field structures. This forces LLMs to infer result shapes and blocks planning of downstream tool chaining.
Parameter descriptions are minimal (8 - 15 characters), meeting floor but not best practice. Baseline for A+ tools is 72 chars average. Format/range constraints (e.g., 'timeout_ms timeout in milliseconds, max 10000') are present but terse. Consider expanding with use-case guidance: 'Specify full or changed mode to rebuild only modified files (faster, requires prior full build).'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Use when you need diff content for changes.
Use when you need commit history context.
Use when you need commit details for one revision.
Use when you need branch or dirty-tree context.
Use when you need to enable parser IDs.
Use when you need parser availability and enabled state.
Use when you need parser improvement suggestions for unsupported or disabled language coverage.
Use when you need to disable parser IDs.
Use when you need explicit, approved runtime package install for parser IDs.
Use when you need parser metadata refresh.
Use when you need ranked natural-language context across files, symbols, and code chunks.
Use when you need to rebuild index state.
Use when you need exact indexed text or keyword matches.
Use when you need index status or staleness.
Use when you need symbol name matches.
Use when you need MCP package and skill update status.
Use when you need external docs or web references.
Descriptions lack composition guidance. Tools like veil_files, veil_symbols, and veil_search are similar, descriptions do not clarify when to prefer one over another or how they should be chained. E.g., 'Use veil_discover for broad triage before narrowing with veil_symbols.' Current descriptions assume the LLM already knows the intent.
No error handling or recovery guidance visible in source. Tool descriptions do not indicate what errors are possible, when they are retryable, or what the LLM should do next. E.g., 'If index is stale, veil_refresh will update it' is not stated anywhere.
Tool annotations are present (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) and correctly categorized (LOCAL_READ_ANNOTATIONS, INDEX_WRITE_ANNOTATIONS, etc.), which is excellent. However, source does not show whether annotations are actually attached to tool schemas in the McpServer registration, verify that tool definitions include annotations in their CallToolResult or tool schema metadata.