Three tools with strong naming (verb-first: list_, get_, get_) and detailed descriptions (150-300 chars each). However, critical gaps: tool #2 and #3 have incomplete input schemas visible in source, get_case_type_format shows only case_type param, but get_agent_instructions shows agent_name with minimal type info. No output schemas documented anywhere. Descriptions are domain-specific and lengthy but lack LLM-optimized structure (e.g., 'CRITICAL:' warnings, acronym-mapping details buried in prose). No error handling guidance, no pagination, no field-level param descriptions. Tool #1 (list_case_types) returns a dict with 'acronym_to_case_type' but source shows ACRONYM_TO_CASE_TYPE is empty, response will be incomplete. Annotations present (readOnlyHint, destructiveHint, idempotentHint) but no per-tool error recovery patterns.

• Add enum constraints to agent_name parameter in get_agent_instructions: enum=['reader', 'format', 'drafter', 'verifier', 'refiner', 'overseer', ''] with description 'Agent persona to load, or empty string for full orchestration script.'
• Document output schemas for all three tools. E.g., list_case_types returns {case_types: string[], descriptions: {[key]: string}, acronym_to_case_type: {[key]: string}, note: string}. Include field types and descriptions.
• Add error handling guidance: 'If case_type is invalid, returns error with list of valid types. Call list_case_types() first to discover available case types.'
• Shorten descriptions to 50-150 chars and move domain context (statutory references, acronym mapping) into a separate 'context' or 'notes' field. E.g., 'Get the drafting format (SKILL.md) for a case type.' instead of the current 150-char prose.
• Populate ACRONYM_TO_CASE_TYPE dict with actual mappings (DRT→drt-original-application, DRAT→drat-appeal, etc.) or remove from list_case_types response.