ClarusMCP defines 3 tools with basic descriptions and string-only parameters. All tools have descriptions (10-100 chars, meeting minimum), but parameter schemas are minimal, each tool accepts only a single string input with no type constraints, enums, or validation guidance. Output schemas are defined in schemas.py (ClinicalSummaryResponse, MedicationDetail, etc.) but are NOT visible in the tool registration itself; LLMs cannot infer return structure from the @mcp.tool() decorators. Tool names follow verb_noun convention (generate_, explain_) but are generic and lack specificity about domain or action. No error handling guidance, no pagination, no idempotent hints. Schemas exist but are decoupled from tool definitions, reducing discoverability.

• Attach output schemas directly to tool definitions using FastMCP's response_schema parameter or equivalent. LLMs need to see return types in the tool discovery response, not in separate files.
• Add validation constraints to string parameters: specify expected format (free text, comma-separated list, structured JSON), length limits, and examples of valid input. Use enums where applicable (e.g., risk_level: [low, medium, high]).
• Expand parameter descriptions to 50-100 characters. Include format hints: 'Raw patient text (free-form, 50-500 chars). Include symptoms, medications, allergies, and relevant history if available.'
• Add error handling guidance to tool descriptions. Document what errors can occur (e.g., 'If input is empty or malformed, returns {"error": "Invalid input"}. Retry with structured text.') and recovery steps.
• Rename tools to be more specific: 'generate_clinical_summary_from_patient_text', 'explain_medications_in_plain_language', 'identify_clinical_risk_signals'. This reduces LLM confusion when multiple tools are available.