This MCP server wraps a third-party Trends API client library. Tool definitions are inferred from method signatures in the wrapper class rather than explicitly registered with MCP schemas. No input schemas are visible in the source code, only parameter names and types are documented in docstrings. Descriptions are present but minimal (10-50 chars). The server does not show explicit tool registration, MCP protocol handlers, or structured output schemas.

• Create explicit MCP tool registration with full JSON Schema for each tool. Define input schemas with type, description, enum constraints, and defaults. Example: get_time_series should declare keyword (required, string), source (optional, enum: ['app downloads', 'google play', ...]), data_mode (optional, string).
• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it vs similar tools, and what it returns. Example: 'Retrieve historical download trends for an app keyword. Returns time-series data points with date and value. Use this to analyze app growth over time; use get_growth() for percent-change metrics instead.'
• Document output schemas for each tool. Specify the structure of returned objects (e.g., TimeSeries returns array of {date: string, value: number}; Growth returns {results: [{growth: number, direction: string}]}). Include field descriptions.
• Remove the get_trends alias. Keep only get_time_series. If users expect 'trends' terminology, add it to the description but do not duplicate the tool. This reduces LLM confusion.
• Add error handling guidance. Document what errors can occur (e.g., 'Invalid keyword format', 'API rate limit exceeded') and recovery steps. Example: 'If you receive a 429 error, wait 60 seconds and retry. If keyword is invalid, verify it matches the app package identifier format (e.g., com.openai.chatgpt).'