Loading ToolBench
MCP server for code indexing and retrieval. Walks a workspace, parses source files using tree-sitter, extracts symbols (functions, structs, classes, etc.), stores them in SQLite, and provides tools for searching, inspecting, and analyzing code structure.
astrolabe-mcp demonstrates solid definition quality with well-structured, verb-prefixed tool names and comprehensive input schemas using JSON Schema. All 9 tools have explicit descriptions and parameter types. However, output schemas are not documented, descriptions are modest (80-150 chars), error handling lacks recovery guidance, and there is no per-tool classification of which operations are read-only vs. destructive. Tool composition is clean with no overlaps. The server correctly exposes a code symbol retrieval domain (no write operations), but the quality falls short of 'A' grade due to incomplete output documentation and minimal guidance on error recovery.
Searches for text patterns across all indexed files using regex
Retrieves the complete source code content of a file
Retrieves the outline of symbols in a specific file, with optional field projection and format selection (json or compact text)
Retrieves a summary of a file including its symbols and their documentation
Retrieves the full source text implementation of a symbol by its fully qualified name
Batch retrieval of implementations for multiple symbols by their fully qualified names, preserving input order
Output schemas not documented. LLMs cannot plan downstream operations or extract required fields when tool return types are unspecified. No documented structure for search_symbols results, file_outline structure, symbol implementation format, etc.
Error handling lacks recovery guidance. Errors return McpError with minimal context. No guidance to LLM on retryability, availability of alternatives, or next steps. E.g., 'file not found' should suggest how to discover valid file paths.
Descriptions are minimal (60 - 75 chars) and lack context on WHEN to use each tool vs. alternatives. For example, get_file_outline vs. get_file_summary, the distinction is not explained. search_symbols vs. full_text_search, design intent not stated.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Reports token usage statistics and savings metrics from symbol retrieval operations
Provides a high-level overview of the workspace structure, listing symbols grouped by file
Searches for code symbols by name pattern, kind, language, or file path with optional field projection
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 9 tools are marked read-only in metadata but schema lacks formal annotation. Clients benefit from explicit hints to optimize caching, plan transaction boundaries, or warn before retry.
Parameter descriptions for 'fields' are generic ('Optional subset of fields to include'). Enumeration of valid field names not provided. LLMs must guess which fields are available (e.g., 'name', 'qualified_name', 'line_number', 'documentation', etc.).