Two tools with minimal descriptions (both under 50 chars) and no documented output schemas. Input schemas are present but sparse (single string param each, no constraints). No error handling guidance, no parameter validation rules, no recovery paths. Tool names lack clarity on what structure/validation they perform. No tool annotations (readOnlyHint, etc.). Descriptions do not explain WHEN to use each tool or what the LLM should do with results.

• Add explicit output schema to both tools. scan_docs_structure_tool should document: {type: 'array', items: {type: 'string', description: 'Absolute path to markdown file'}, description: 'List of all markdown files found in repo'}. validate_structure_tool should document the dict structure: {file, score, errors, warnings} with field types and descriptions.
• Expand tool descriptions to 150-250 chars. Example for scan_docs_structure_tool: 'Recursively scan a repository directory and return all markdown (.md) files found. Skips .git, node_modules, and __pycache__. Use this first to discover documentation files before validating them. Returns absolute file paths.'
• Add parameter constraints and format guidance. For repo_path: 'Absolute or relative path to the repository root directory. Must be readable and exist on the server filesystem.' For file_path: 'Absolute or relative path to a markdown file. Must end with .md and be readable.'
• Document error cases and recovery. Example: 'If repo_path does not exist, returns empty list. If file_path is unreadable, returns {file, error: <reason>}. Check the error field in the response and ask the user to verify the path.'
• Add readOnlyHint: true to both tool schemas in FastMCP registration to signal to clients that these tools do not modify state and are safe to call repeatedly.

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

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