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

Annotations only cover read-only and open-world, so the description carries the rest and does disclose non-obvious behavior: SSL verification is disabled, the summary mode strips French translations/archive codes/footnotes and caps members at 3 per dimension with _next_steps guidance, and typed exceptions are listed. It stops short of stating latency, payload size when summary=False, or any auth/rate-limit constraints.

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?

Front-loaded with the core purpose and the default-first summary recommendation, then siblings, then return/error details. Some slack: the summary paragraph duplicates the schema's own description of summary almost verbatim, and the Returns/Raises block plus the citation mandate add bulk that isn't about invocation.

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?

With no output schema, the description must cover returns, and it does at a high level (metadata object with dimension info, titles, date ranges, codes) plus failure modes. Field-level shape of the returned dict is left implicit, but an agent has enough to call it correctly and interpret a success.

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 coverage is 50%: summary is fully documented in the schema and the description largely restates it (adding only which noise is stripped). productId is undocumented in both places — the description says 'using its ProductId' but never states the format or where an agent obtains one (e.g., get_all_cubes_list).

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?

States a specific verb and resource ('Retrieves detailed metadata for a specific data table/cube') and names the exact identifier used to address it (ProductId). It also sketches the payload contents (dimension info, titles, date ranges, codes), so an agent knows this is a per-cube metadata fetch, not a search or data-query tool.

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?

Explicitly recommends starting with summary=True, explains the tradeoff for summary=False, and routes two adjacent needs to named siblings: get_sdmx_structure for dimension codes and get_series_info for coordinate-to-vectorId resolution. That is a complete when/when-not/alternative map.

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