Three tools with clear healthcare domain purpose and reasonable descriptions (150-200 chars each). All tools have input schemas with Zod validation and type definitions. However, parameter descriptions lack specificity on constraints, formats, and error recovery guidance. Output schemas are not documented, LLMs cannot predict response structure. Error handling returns text responses but lacks actionable recovery steps or categorization. Tool names follow verb_noun pattern but could be more specific (e.g., 'CheckAuthStatus' vs 'get_prior_auth_status'). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only operations.

• Document output schemas for each tool. Define response object structure (e.g., CheckAuthStatus returns {status: string, medications: [{name, id, status, indication}], claimResponses: [{outcome, disposition, id}]}). This enables LLMs to chain tools and extract required fields.
• Add format constraints to parameters. E.g., patientId: 'Patient identifier (alphanumeric, 1-20 chars, e.g., PAT-12345)'; denialReason: 'Reason for denial (enum: step_therapy_required, prior_auth_expired, medical_necessity_not_met, formulary_restriction, other)'.
• Enhance error responses with recovery guidance. Instead of 'Could not retrieve MedicationRequest resources', return 'MedicationRequest lookup failed (retryable). Ensure patient ID is valid and FHIR server is accessible. Try: (1) verify patient exists, (2) check FHIR server connectivity.'
• Rename tools to snake_case verb_noun convention: CheckAuthStatus → check_prior_auth_status, GenerateAppeal → generate_appeal_letter, GetAppealPdf → format_appeal_summary. This aligns with LLM naming expectations and production baselines.
• Add tool annotations. Mark all three tools with readOnlyHint=true to signal they are safe to retry and have no side effects. This guides agent planning and error recovery.