Server provides 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (list_, screen_, validate_, generate_, log_). Descriptions are adequate (50-150 chars) but lack LLM-optimized guidance on WHEN to use each tool or dependencies between them. Parameters are typed and mostly described, but lack constraints (enums, ranges, patterns) that would guide LLM input. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance. The validate_matter tool accepts a large object with 24 optional fields but provides no guidance on which are critical vs. optional, forcing LLMs to guess. log_triage_record is a write operation but lacks confirmation/dry-run pattern.

• Document output schema for each tool. E.g., list_practice_areas returns {practice_areas: [{name: string, description: string}], total: number}. LLMs need this to plan downstream calls.
• Add enum constraint to response_format parameter in all 4 tools that use it. Change from free-form string to explicit enum: ['markdown', 'json'].
• Enhance validate_matter description to clarify which fields are required (counterparty, matter_type, our_role, jurisdiction, practice_area, source, severity, likelihood) vs. optional context fields. Add: 'Required fields: counterparty, matter_type, our_role, jurisdiction, practice_area, source, severity, likelihood. Optional fields depend on matter type.'
• Add dependency hints to tool descriptions. E.g., validate_matter: 'Call screen_parties first to check conflicts before validating.' generate_followup_email: 'Call validate_matter first to identify missing fields.'
• Implement dry-run or confirmation pattern for log_triage_record. Add optional 'dry_run' boolean parameter (default false) so LLMs can preview the log entry before committing.

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

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