23 read-only tools with consistent naming (verb_noun pattern: get_*, list_*) and complete input schemas. Descriptions are present but generic (avg ~80 chars, below 194-char baseline). All parameters have type definitions and descriptions. No output schemas documented. Error handling exists but lacks recovery guidance. Security is sound (API keys injected server-side via env vars). Composition is clean, each tool has one responsibility. Main gaps: output schemas missing, descriptions could be more LLM-optimized, no pagination guidance despite potential large result sets.

• Document output schemas for all 23 tools. For each, specify the response structure: e.g., get_campaigns returns {data: [{id, name, status, created_at, ...}], truncated: bool}. Include field types and which fields are safe to chain to downstream tools.
• Expand descriptions to 100-150 chars. Add context: 'Get a specific campaign by ID. Use after list_campaigns() to fetch details like send status, recipient count, and performance metrics.' This helps LLMs distinguish get_campaign from get_campaign_report.
• Add pagination to list-like tools. Introduce limit (default 20, max 100) and cursor parameters. Return total_count and next_cursor. Document in descriptions: 'Results are paginated; use cursor to fetch next page.'
• Enhance error messages with recovery hints. When account not found, return: 'Account "acme" not found. Available accounts: acme-us, acme-eu. Call list_accounts() to see all.' This enables agent self-correction.
• Clarify date parameter formats in reporting tools. Update descriptions: 'Start date in ISO 8601 format (YYYY-MM-DD or RFC 3339). Reporting data available from 2023-06-01 onward. Requests spanning >1 calendar year will be rejected by Klaviyo API.'