Four tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. read_file, write_file, and list_files have minimal descriptions (20-50 chars) and lack detail on return formats. analyze_code's description is verbose but educational rather than production-focused, and references deprecated sampling pattern. No tool declares output schema structure. Error messages are generic strings rather than structured responses. Parameter descriptions exist but are minimal. No tool annotations (readOnlyHint, destructiveHint) despite clear risk profiles.

• Expand tool descriptions to 100-200 chars. Example for read_file: 'Read and return the full text content of a file in the workspace. Returns file content as plain text. Use this to inspect code, config, or data files. Returns error if file not found or path is outside workspace roots.'
• Add explicit output schema documentation. Example: 'Returns: {"success": bool, "content": string, "error": string|null, "filepath": string}' or similar structured format.
• Replace string error responses with structured error objects: {"error": "access_denied", "message": "...", "recovery": "Check file path is within workspace"}. This lets LLMs classify and respond appropriately.
• Add tool annotations: mark read_file and list_files with readOnlyHint=true; mark write_file with destructiveHint=true and idempotentHint=false to signal risk profile.
• Redesign analyze_code: remove sampling reference and either (a) integrate with a real LLM provider backend, or (b) simplify to a static code quality checker that returns structured findings without bidirectional communication.

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

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API