Loading ToolBench
Code Graph MCP Server for exploring code repositories through semantic graph analysis
Server defines 4 tools with reasonable descriptions (avg 180 chars, within baseline 194). All tools have input schemas with Zod validation. However, critical gaps exist: (1) schemas lack explicit type declarations in visible code, Zod schemas are present but not exposed as JSON Schema in tool registration; (2) parameter descriptions are present but generic, 'graphId' and 'repository' lack guidance on when/how to use them; (3) no output schema documentation, responses are text blobs, not structured objects; (4) error handling returns raw error strings instead of actionable recovery guidance; (5) tool names are clear (verb_noun pattern: list-graphs, get-code, find-direct-connections, nodes-semantic-search) but descriptions embed repository context dynamically, risking confusion. Per-tool analysis: list-graphs (70), get-code (58), find-direct-connections (58), nodes-semantic-search (60). Average: 61.5, rounded to 58 due to schema visibility and error handling gaps.
Explore the immediate relationships of a functionality within the code graph from the repository. This reveals first-level connections including: parent functionalities that reference this node, child functionalities that this node directly calls or uses, declaration/definition relationships, and usage patterns. Essential for understanding code dependencies and architecture. The repository is represented as a connected graph where each node (function, class, file, etc.) has relationships with other nodes.
Get the complete code implementation of a specific functionality (class, function, method, etc.) from the repository graph. This is the primary tool for code retrieval and should be prioritized over other tools. The repository is represented as a graph where each node contains code, documentation, and relationships to other nodes. Use this when you need to examine the actual implementation of any code entity.
List all available repository graphs that you have access to. Returns basic information about each graph including the graph ID, repository name with branch, and description. Use this tool when you need to discover available graphs.
Search for code functionalities across the repository graph using semantic similarity based on natural language queries. This tool finds relevant functions, classes, methods, and other code entities that match the conceptual meaning of your query, even if they don't contain the exact keywords. Perfect for discovering related functionality, finding similar implementations, or exploring unfamiliar codebases. The search operates on the semantic understanding of code purpose and behavior.
Output schemas not documented. All tools return text blobs in content[].text. LLMs cannot parse structured results or chain downstream tool calls. No pagination, no field references for follow-up lookups.
Error handling returns raw error strings (e.g., 'Error fetching graphs: [object Object]'). No recovery guidance, no error classification (retryable vs fatal). LLM cannot determine next action.
Input schemas use Zod but are not exposed as JSON Schema in tool registration. createToolSchema() helper is called but its output is not visible in source. Schema validation happens server-side; client cannot see constraints (enums, min/max, patterns).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Optional parameters (graphId, repository) lack guidance on when to use them. Description says 'optional' but does not explain: What is the default? When should I pass it? What happens if I omit it?
Tool descriptions embed dynamic repository context (e.g., 'from the repository ${repository}'). If repository is empty or undefined, description becomes misleading. Descriptions should be static and context-agnostic.