Server exposes 29 tools generated from OpenAPI spec with consistent naming (verb_noun pattern) and basic schemas. However, descriptions are uniformly terse (10-30 chars), parameter descriptions lack depth, and output schemas are not documented. Tool definitions are auto-generated from spec, reducing hand-written drift but also limiting LLM-optimized descriptions. No error recovery guidance, no pagination details, no composition hints. Schemas present but minimal, most parameters lack constraints (enums, ranges, formats). This is a typical auto-generated server: functional but not LLM-optimized.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and key output fields. Example: 'List all contacts in the system. Use this to find a contact by name before calling create_invoice. Returns contact_id, name, email, and address fields. Supports pagination via limit parameter.'
• Document output schemas for all tools. Add a 'Returns' section to each description listing key fields and types. Example: 'Returns: {contact_id: number, name_1: string, mail: string, created_at: ISO8601}'
• Add constraints to parameters: specify min/max for 'limit' (e.g., 1-100), document default values, and mark required vs optional. Use enums for fixed-choice fields (e.g., contact_type_id should list valid IDs).
• Add pagination details to list_* tools: document offset/cursor mechanism, total count field, and example of fetching next page. Update descriptions to say 'Paginated results; use limit and offset to fetch pages.'
• Implement confirmation pattern for destructive tools: add optional 'confirm=true' parameter or return a confirmation token that must be passed in a second call. Document this in tool descriptions.