Server defines a single tool 'create-wom-ticket' with comprehensive schema and detailed descriptions. Tool name starts with action verb (create_), parameters are well-documented with type constraints and length limits. Input schema is complete and properly structured. However, output schema is not documented, callers cannot predict response structure. Error handling is present in code but not communicated via description. Tool description is lengthy (500+ chars) but clearly explains WHAT, WHEN, and use cases, aligning with pattern:tool-description. No parameter examples contaminate descriptions (good practice). Missing output documentation and error guidance pull score down from 80+ range.

• Add explicit output schema to tool description: 'Returns a JSON object with code (string), message (string), data (object with ticket_id, status, created_at), and any additional ESB-specific fields.' Include field types and meanings.
• Prepend tool description with: 'WRITE operation: Submits an irreversible work order to the ESB. Cannot be undone. Agents should request confirmation before calling in high-stakes scenarios.'
• Document error scenarios in description: 'Errors: ESB_URL not configured (fatal, configure server); API request failed (retryable, wait and retry); invalid input (user-fixable, review required fields). On user-fixable errors, LLM should validate inputs and retry.'
• Add optional 'requiresConfirmation' field to tool definition or wrap in a confirmation pattern: separate 'draft_wom_ticket' (read-only, shows what will be submitted) and 'submit_wom_ticket' (WRITE, actually submits).
• For 'name' and 'email': clarify in descriptions that these are fallback contact channels. If omitted, state: 'Will default to employee directory lookup via empNo if available; otherwise work order will have no direct contact info.'