Server has 8 well-named, read-only tools with consistent verb_noun naming (list_*, get_*). All tools have descriptions (avg 120 chars, within baseline 34-392). Zod schemas present for all tools with typed parameters. However, parameter descriptions are minimal (e.g., 'webhook id, a uuid' lacks format/constraint details). Output schemas are undocumented, LLMs cannot predict response structure. Error handling is basic: get_template returns isError flag but others do not. No guidance on retryability, rate limits (Zoko's 300s throttle on /customer), or pagination semantics. Caching logic is implementation detail, not surfaced to LLM. Missing: output schema documentation, error recovery guidance, and parameter constraint details (e.g., UUID format, page bounds).

• Document output schemas for all tools. Example: 'Returns array of template objects with fields: templateId (string), templateLanguage (string), status (string), body (string).' This enables LLMs to extract and chain data.
• Add constraint details to parameter descriptions. Change 'webhook id, a uuid' to 'webhook id (UUID format: RFC 4122, e.g. 550e8400-e29b-41d4-a716-446655440000)'. Change 'page number' to 'page number (1-based, default 1, max ~10 pages due to 10-min cache).'
• Add error recovery guidance. Document that list_customers is rate-limited (1 req/300s) and pages are cached 10 min. For get_* tools, add: 'If not found, try list_* to discover valid IDs.' For network errors, state: 'Retryable with exponential backoff (server implements 1 retry on JSON parse failure).'
• Add tool annotations to schema. Set readOnlyHint: true for all tools to signal safety. Example: server.tool('list_templates', ..., { readOnlyHint: true }).
• Enhance list_customers description to state: 'Returns one page of 100 customers. Zoko enforces 1 request per 300 seconds; pages are cached 10 minutes. Fetching all pages is impractical. Returns total count if available.' This sets expectations and prevents retry loops.