Loading ToolBench
An MCP (Model Context Protocol) server that indexes code repositories into a SQLite property-graph knowledge graph for code intelligence
This Zig-based MCP server has two tools with minimal definition quality. Both tools have descriptions but they are extremely generic and lack actionable context. Input schemas are defined in code (repo_path and project parameters visible) but lack proper type information, parameter descriptions, and validation constraints. The code shows a comptime tool registration system in src/mcp/tool.zig with a ToolMeta struct, but the schema generation helper schemaWithStringParam() is stubbed out and returns an empty schema, meaning actual schemas are not being built. Tool descriptions do not explain WHEN to use each tool, WHAT happens on invocation, or WHY one would choose this tool over alternatives. No output schema documentation exists. Error handling is minimal, the codebase shows basic error classification but no recovery guidance. The server demonstrates a disciplined Zig architecture with proper memory management and JSON-RPC 2.0 handling, but tool definitions fall well short of production quality.
Index a repository into the knowledge graph
Get the indexing status of a project
Input schemas are not properly constructed. The schemaWithStringParam() helper in tool.zig is stubbed and returns emptySchema(), meaning no actual parameter type information, constraints, or descriptions are being attached to tool definitions. Tools only have parameter names visible in code, not formal JSON Schema with types, descriptions, or validation rules.
Tool descriptions are too generic and lack critical context. 'Index a repository into the knowledge graph' does not explain: WHEN to call this (before what?), WHAT happens to the repository (storage, indexing strategy), or WHETHER it modifies state (appears to be write operation but not stated). 'Get the indexing status of a project' omits WHAT fields are returned or HOW to interpret the status.
No parameter descriptions exist. The 'repo_path' parameter in index_repository and 'project' parameter in index_status have no descriptions explaining: expected format, valid values, whether absolute or relative paths, what identifies a 'project', or how to obtain a project name.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
No output schema documented. The handleToolsCall code accepts tool execution but the source does not show what these tools return (structure, fields, types). Without documented return types, LLMs cannot plan downstream tool calls or extract the right data from responses.
Error handling provides no recovery guidance. The server implements error reporting (ErrorCode enum visible) but error messages sent to LLMs likely provide error codes without actionable next steps. E.g., a missing project should return 'Project not found. Try index_status() to see available projects' rather than a bare 404.
Parameter naming is ambiguous. 'repo_path' could mean relative, absolute, git remote, or local directory, the description omission leaves this to guessing. Similarly, 'project' in index_status could mean project name, ID, slug, or path.
No indication whether index_repository is idempotent. If called twice with the same repo_path, does it re-index (data loss), append, or skip? Agents retry on ambiguous failures, non-idempotent tools risk duplicate side effects.