Two tools with minimal documentation. Both have basic descriptions (60-80 chars, below the 194-char baseline) and input schemas present but sparse. No output schemas documented. No error handling guidance. No parameter descriptions beyond the query/patientId names themselves. Tool names follow verb_noun pattern (search_, get_) but lack context about when to use each. No evidence of idempotency, pagination, or composition patterns. Descriptions state WHAT but not WHEN or WHY to call the tool.

• Add output schema for each tool. Example for get_patient_context: {type: 'object', properties: {patientId: {type: 'string'}, allergies: {type: 'array', items: {type: 'string'}}, medications: {type: 'array'}, conditions: {type: 'array'}}}. Document what fields are always present vs. optional.
• Expand tool descriptions to 100 - 200 chars. For search_knowledge: 'Search the medical knowledge base for clinical guidelines, drug interactions, and treatment protocols. Use when the conversation mentions a clinical topic requiring evidence-based information. Returns ranked results with source citations.' For get_patient_context: 'Retrieve patient demographics, allergies, current medications, and active conditions. Use before prescribing or when checking for drug interactions. Returns null if patient not found.'
• Add parameter descriptions. For 'query': 'Medical search term (e.g., "hypertension management", "drug interaction warfarin aspirin"). Use specific clinical terminology; free-text searches may return irrelevant results.' For 'patientId': 'Patient identifier (UUID or numeric ID from the patient system). Required to retrieve accurate context.'
• Define error responses. E.g., search_knowledge: 'If no results found, try broader terms or check spelling. If timeout occurs, retry with a more specific query.' get_patient_context: 'If patient not found, verify the patientId. If access denied, check user permissions.'
• Add pagination to search_knowledge. Include limit (default 20, max 100) and offset/cursor parameters. Return total_count and next_cursor in response so LLM can fetch additional results if needed.