get_cube_metadata

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses a notable behavior: 'Disables SSL Verification.' It also explains the summary mode's behavior (strips French translations, shows 3 sample members, adds _next_steps) and explicitly warns about safe context window sizes. It lists exceptions and even adds a mandatory citation instruction. While it could explicitly state read-only intent, the retriever verb and non-mutating nature are clear enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably sized for the tool's complexity and front-loaded with the primary purpose. Each section (endpoint mapping, summary guidance, alternatives, return/raises, citation note) adds value. It is slightly verbose with repetitive emphasis (e.g., summary=True repeated), but overall well-organized and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description compensates well. It describes the return type (Dict[str, Any]), explains the summary vs. full modes, lists exceptions, and provides situational guidance (e.g., safe for all context window sizes). The mention of _next_steps guidance and citation requirements gives operational completeness. Nothing essential is missing for an agent to invoke and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% (summary is described, productId is not). The description goes beyond the schema by thoroughly explaining the summary parameter: 'strips noise (French translations, archive codes, footnotes) and shows only 3 sample members per dimension with _next_steps guidance.' The productId parameter is only mentioned as 'using its ProductId', but the endpoint mapping and citation note ('including the ProductId (pid) and the Title') give additional context. Given the strong added meaning for summary, this is above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear statement of purpose: 'Retrieves detailed metadata for a specific data table/cube using its ProductId.' It lists specific content (dimension info, titles, date ranges, codes) and maps to a concrete endpoint (POST /getCubeMetadata). Sibling differentiation is also explicit via references to get_sdmx_structure and get_series_info, making it easy to distinguish from related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Start with summary=True (default)... Set summary=False only if you need the full raw member list or all API fields.' It also names alternatives for adjacent tasks: 'To browse dimension codes... use get_sdmx_structure. To resolve a coordinate to a vectorId, use get_series_info.' This covers both usage context and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.