AppsFlyer MCP has a basic structure with 2 tools, both with clear naming and documented schemas. However, there are critical gaps in error handling, output schema documentation, and parameter descriptions that prevent this from reaching a higher tier. Tool names follow verb_noun convention (get_aggregate_data, test_appsflyer_connection), which is good. Schemas are present and properly typed using Pydantic. However, descriptions are generic, output schemas are not documented, and error handling lacks recovery guidance. The server implements neither tool annotations nor advanced features. For a domain-specific API wrapper, this represents typical but mediocre quality.

• Document output schema for each tool. For get_aggregate_data, specify: 'Returns CSV-formatted text. Columns depend on report_type. Call test_appsflyer_connection first to verify credentials.' For test_appsflyer_connection, specify: 'Returns a status message string (success or error), not machine-parseable. Use as a health check only.'
• Enhance error messages with recovery guidance. E.g., instead of 'HTTP error occurred: {e.response.text}', return 'HTTP {status_code}: {message}. Check that app_id is valid and from_date ≤ to_date. Credentials may be misconfigured, call test_appsflyer_connection to verify.'
• Expand parameter descriptions. For report_type, document each enum value: 'daily_report (one row per day), partners_report (aggregate across partners), geo_report (by geography).' For dates, add: 'Range must not exceed 365 days. Format: YYYY-MM-DD.'
• Add context to tool descriptions. Rewrite get_aggregate_data as: 'Fetch raw analytics data from AppsFlyer for a given app and date range. Returns CSV-formatted report. Choose report_type based on analysis goal (daily trends, geo breakdown, partner performance). Call test_appsflyer_connection first to verify API access. Rate limited; batch multiple date ranges into one call if possible.'
• Declare tool annotations. Add destructiveHint=false and idempotentHint=true to both tools (both are read-only and safe to retry).
• Add pagination or result limits. Document max date range (e.g., 'Recommended max 90 days per call to avoid timeouts') and suggest strategies for larger ranges (loop with pagination, or batch by date).