Loading ToolBench
Analyzes git repositories and extracts business information such as rules, API contracts, and database schemas. Provides MCP tools for code context analysis and graph queries.
This server has 9 well-named tools with reasonable descriptions, but critical gaps in schema completeness and parameter documentation prevent higher scores. All tools are READ_ONLY which is appropriate. Tool names follow verb_noun convention (list_projects, get_class_context, search_project, graph_query) and are action-oriented. Descriptions are present and substantive (60-150 chars), explaining purpose and use cases. However, the majority of parameters lack type information in the visible code, input schemas are documented in the tool registration but do not include explicit 'type' declarations or enum constraints where applicable. Output schemas are entirely absent; LLMs cannot predict what fields to expect from responses. No error handling guidance is visible. The graph_query tool has a particularly opaque syntax that lacks validation rules or recovery hints. STDIO-only transport is a hard constraint that caps this server at 50 maximum for protocol readiness, but definition quality can be assessed independently.
Get detailed context information for a specific class including its dependencies, methods, and annotations
Get all dependencies of a specific class, including what it depends on and what depends on it
Get detailed context information for a specific method including its signature, parameters, and implementation details
Get a high-level overview of a project including its structure, main components, and statistics
Get the API specification for a service project including all HTTP endpoints and their contracts
Get context information for stack trace frames to aid in debugging and error analysis
Output schemas entirely undocumented. LLMs cannot predict response structure, field names, or types. Agents cannot plan downstream tool calls or extract results reliably.
graph_query tool uses an opaque colon-separated DSL syntax without explicit validation rules, constraint documentation, or error recovery hints. The syntax string alone ('project:target[:navigation]*[:+include]*[:?check]') lacks examples of valid/invalid queries, and there is no documented error response format explaining what happens on parse failure.
Parameters lack explicit type declarations and constraints. For example, 'query' in graph_query is a string but no maxLength, pattern, or enum is defined. 'limit', 'offset', or 'page_size' parameters (if present) have no min/max bounds, allowing LLMs to pass absurd values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | 2024-11-05+ | v1 |
Query the project dependency graph using a colon-separated syntax. Syntax: project:target[:navigation]*[:+include]*[:?check]. Keywords: endpoints, classes, entrypoints. Examples: order-service:endpoints, order-service:endpoints:+logic, order-service:UserService:methods:+logic, order-service:UserService:?createUser
List all indexed projects with their metadata
Search for classes within a project by name or keyword
No error handling guidance visible in any tool. There are no recovery hints, actionable error messages, or error classification (retryable vs user-fixable vs fatal). If a class is not found, agents have no hint about what to try next.
get_service_api description ('Get the API specification for a service project including all HTTP endpoints and their contracts') does not clarify output format. Will it return OpenAPI/Swagger JSON, markdown, plain text, or structured objects? Ambiguity forces LLM guessing.
No pagination or result limit guidance documented for tools that could return many results (list_projects, search_project, get_class_dependencies, get_stack_trace_context). Large result sets will blow token budgets and degrade LLM reasoning.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent. All tools are READ_ONLY, but this is not formally declared in a way the protocol can parse, so client safety logic cannot auto-detect them.