All 9 tools have explicit names, descriptions, and input schemas visible in the TOOL_CATALOG. Naming follows verb_noun convention (get_, list_) and is clear. Descriptions are concise (40 - 90 chars) and state what each tool does. However, parameter descriptions are entirely absent, the schema declares properties but provides no guidance on what each parameter controls, valid ranges, or dependencies. Output schemas are not documented. No error handling guidance is provided. Tool annotations (readOnlyHint, openWorldHint) are present but minimal. This is a read-only analytics API with low mutation risk, but the lack of parameter documentation and output schema specification significantly limits LLM reasoning quality.

• Add descriptions to every parameter. For 'limit', specify: 'Maximum number of results to return (1 - 100, default 20).' For 'status', use an enum: ['active', 'completed', 'pending'] or document valid values in the description.
• Document output schemas for each tool. Specify the top-level structure (object, array) and key fields with types. E.g. 'Returns an object with fields: workspace_name (string), target_brand (string), active_prompts (number), competitors (array of strings), latest_window (object with id, timestamp, status).'
• Add pagination metadata to list_* tools. Specify whether results include total_count, next_cursor, or page info. Document the default limit and maximum allowed.
• Provide error recovery guidance. Document common errors (e.g. 'measurement_window_id not found', 'API key invalid') and suggest next steps: 'Call list_measurement_windows() to find a valid window ID.'
• Specify parameter constraints in descriptions. Use enums for status/category fields, min/max for numeric limits, and regex patterns for string formats. Replace free-form 'string' types with constrained alternatives.