Two tools with clear, action-verb names (search_apps, find_zap_templates) and solid descriptions (194 and 180 chars respectively). Input schemas are well-formed with Zod validation, proper type constraints (min/max), and parameter descriptions. However, output schemas are completely undocumented, responses are JSON-stringified text with no declared structure. Error handling is basic (try/catch wrapper returns error message as text). No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions are adequate but lack dependency hints (e.g., 'Use returned slugs with find_zap_templates' is in tool description, not param description). Missing guidance on pagination behavior and result limits.

• Document output schemas explicitly. Define the structure of search_apps results (e.g., array of {title, slug, description, url, categories}) and find_zap_templates results (e.g., array of {title, description, steps, create_url, url}). Return structured objects, not JSON strings.
• Add tool annotations to both tools: set readOnlyHint=true and idempotentHint=true in the schema to signal retry safety and lack of side effects.
• Enhance error handling with recovery guidance. Catch specific HTTP status codes (401, 404, 5xx) and return actionable messages: 'Invalid client_id. Verify ZAPIER_CLIENT_ID is set correctly.' or 'App not found. Try search_apps() to discover available apps.'
• Add dependency hints to parameter descriptions. In find_zap_templates, change 'App slugs, e.g. ["slack", "notion"]' to 'App slugs from search_apps results, e.g. ["slack", "notion"]. Use search_apps() first to discover available apps.'
• Document pagination and limits. Clarify that search_apps and find_zap_templates both cap results at the limit parameter (max 50). If the API supports pagination, add next_cursor or offset/limit guidance.