Server has 2 tools with reasonable schemas but significant gaps in descriptions and parameter documentation. describe_data lacks any description entirely (0 chars). read_data has a description but it is generic ('Read data from Cube'). The read_data tool has a complex nested Query schema with good type definitions and enum constraints (granularity, order direction), but parameter descriptions are minimal or missing context about when to use ungrouped vs grouped queries. No error handling guidance, no output schema documentation, and no indication of what fields the response contains. Tool names follow verb_noun pattern (describe_, read_) which is good, but descriptions do not explain WHEN to call each tool or what the LLM should expect in responses.

• Add a description to describe_data: 'Retrieve metadata about available measures, dimensions, and time dimensions in Cube. Call this first to discover what data is queryable before calling read_data.'
• Expand read_data description to 100-150 chars: 'Execute a query against Cube data. Specify measures (aggregations), dimensions (grouping), time ranges, and limits. Returns rows with aggregated or raw data depending on ungrouped flag.'
• Document the output schema for read_data in the tool description or as a separate note: 'Returns {data: [{...}], annotation: {measures: {...}, dimensions: {...}}, error?: string}'
• Add parameter descriptions for ungrouped, limit, and offset explaining trade-offs: 'ungrouped=true returns all matching rows (slower, higher memory); ungrouped=false groups by dimensions (faster, aggregated).'
• Implement error recovery guidance: catch timeout errors and return 'Query exceeded 10s timeout. Try: reduce limit, add date range filter, or remove low-cardinality dimensions.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry