CodeScan has 4 tools with complete input schemas and descriptions. All tools follow verb_noun naming (scan_*). Descriptions are adequate (60-90 chars) but lack actionable context for LLM selection. Parameter descriptions are present but minimal. Output schemas are documented via Pydantic models (MCPScanResult, MCPIssue) with typed fields. Error handling is basic, no recovery guidance or categorization. No tool annotations (readOnlyHint, destructiveHint). Missing dependency hints and prerequisites.

• Expand parameter descriptions to 50-100 chars. Example: 'path: Absolute or relative file path to scan. Supports .py, .js, .java, .go. Required.' This matches baseline (72 chars avg) and guides LLM input.
• Add WHEN-to-use guidance to tool descriptions. Example: 'Use scan_file for targeted review of a single file. For repository-wide scans, use scan_directory. For branch-to-branch diffs, use scan_git_diff.' This disambiguates tool selection.
• Declare tool annotations via FastMCP. Add readOnlyHint=True and idempotentHint=True to all @server.tool decorators. This signals safety to agents and enables optimizations.
• Enhance error messages with recovery guidance. Example: raise ValueError(f'File not found: {path}. Verify the path exists and is readable. Use scan_directory() to scan multiple files.') This matches pattern:recovery-guide.
• Document output schema in tool descriptions. Example: 'Returns MCPScanResult with fields: scan_id, total_issues, issues_by_severity, issues (list of MCPIssue with title, severity, file_path, line_number, recommendation).' This helps agents plan downstream actions.

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

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