Blindspot provides 9 tools with complete input schemas and descriptions, but quality is uneven. All tools are READ_ONLY (good security posture), but descriptions are inconsistent in depth and actionability. Tool names follow verb_noun convention (search_code, get_symbol_body, build_deep_index), which is correct. However, parameter descriptions lack detail on constraints, formats, and valid ranges. For example, search_code's 'regex' parameter has a null default with no explanation of when to use it. Output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is absent from visible code. The server targets code analysis (a narrow domain), which limits tool count but also means each tool must be exceptionally well-defined to guide LLM reasoning about complex codebase operations.

• Document output schemas for all tools. For search_code, specify: {matches: [{file: string, line: number, column: number, text: string, context: string}], total_count: number, truncated: boolean}. This enables LLMs to extract and chain results.
• Add min/max constraints to numeric parameters. E.g., context_lines: 'Number of context lines (0-50, default 0)'; file_pattern: 'Glob pattern (e.g., **/*.py, src/**/*.js)'.
• Clarify tool selection logic in descriptions. E.g., get_symbol_body: 'Returns the full source code of a function, class, or method. Use this to read implementation details. For line ranges or edit-safe regions, use get_edit_region instead.'
• Add error recovery hints. E.g., set_project_path: 'If path is invalid or inaccessible, verify the directory exists and you have read permissions. Common issue: relative paths, use absolute paths.'
• Implement and document result limits. E.g., search_code: 'Returns up to 50 matches. If truncated=true, refine your pattern or use file_pattern to narrow scope.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry