Loading ToolBench
MCP server for Zig language intelligence — diagnostics, formatting, hover, go-to-definition, references, completions, symbols, and build via ZLS
Server has 8 well-named tools with explicit Zod schemas and descriptions. All tools follow verb_noun naming (zig_diagnostics, zig_format, zig_hover, etc.). Descriptions are present and reasonable (avg ~110 chars). However, there are significant gaps: (1) output schemas are NOT documented, tools return generic text responses without specifying what fields/structure the agent should expect; (2) error handling is minimal, errors return raw message strings with no recovery guidance or categorization; (3) parameter descriptions lack constraint details (e.g., 'Absolute path' but no format validation guidance); (4) no pagination support for multi-result tools (completions, references). Tools are functionally defined and syntactically valid, but lack the depth needed for reliable agent composition.
Run `zig build` in a project directory and return the build output
Get completion suggestions at a specific position in a Zig file via ZLS
Go to definition — find where a symbol is defined in a Zig codebase via ZLS
Get diagnostics (errors, warnings) for a Zig source file via ZLS
Get the document symbol outline (functions, structs, variables) of a Zig file via ZLS
Format Zig code using `zig fmt`. Provide either a file path to format in-place, or a code string to format and return.
Get type information and documentation for a symbol at a specific position in a Zig file via ZLS
Output schemas not documented. All tools return generic { content: [{ type: 'text', text: result }] } without specifying what the text response contains. Agents cannot plan downstream operations or extract structured data. E.g., zig_references should document it returns a list with filename, line, column, context; zig_completions should document completion objects with label, detail, kind.
Error handling returns bare error messages with no recovery guidance. E.g., if ZLS fails, agents receive 'Error: connection refused' with no hint to check if ZLS is running, restart it, or try a different tool. Errors should categorize (retryable vs user-fixable) and suggest next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Find all references to a symbol at a specific position in a Zig file via ZLS
Parameter descriptions lack specificity. 'Absolute path to the .zig file' does not explain validation rules (must exist? must be readable?) or format constraints. Descriptions should include: 'Absolute path to an existing, readable .zig file (e.g., /home/user/project/src/main.zig)'.
Multi-result tools (zig_references, zig_completions) lack pagination. If a symbol has 500+ references or 100+ completions, results will be incomplete or truncate output. Should support limit + offset parameters (already present for completions but not enforced as pagination protocol) and document max result limits.
zig_format has mutually exclusive parameters (file_path vs code) but does not validate that exactly one is provided. If an agent passes both (or neither), behavior is undefined. Description should state: 'Provide exactly one of file_path or code, not both.'
zig_build tool description states it runs `zig build`, but does not document what constitutes success vs failure, what a non-zero exit code means, or how to interpret build output. Should clarify: 'Returns the full build output. Exit code 0 = success; non-zero = build failed. Examine output for compilation errors or linker warnings.'
Tools implicitly depend on ZLS being installed, running, and configured correctly, but this is not documented anywhere. If ZLS is unavailable, agents will encounter repeated failures with no clear root cause. Tool descriptions should state prerequisites: 'Requires ZLS (Zig Language Server) v0.x+ to be installed and accessible in PATH.'