query_data

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

With no annotations present, the description carries the full behavioral burden. It does reveal an important trait: the response is capped at 400 cells. It does not explicitly state read-only behavior, stability, or any pagination/error behavior, though the verb 'Interroge' nudges the read-only interpretation. The 400-cell cap is real transparency, but more behavioral context would be needed for the description to be a strong standalone guide.

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 stays compact, bundles the syntax rule, gives an instructive example, and finishes with a clear alternative in one sentence. The example adds token length but earns its place because it disambiguates the filter syntax. The 'Réponse plafonnée à 400 cellules' detail is appropriately placed near the example.

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?

An output schema is present, so the return value shape does not need to be described. The description provides the essential context: what the tool queries, how filters are written, what the cell limit is, and which sibling is better suited for a certain use case. A small gap is the lack of explicit advice to use search_datasets to find valid dataset codes, but the example partially fills that gap.

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?

Parameter descriptions in the schema are absent (0% coverage), so the description reasonably compensates: it defines the filters syntax (dim: 'A+B') and offers a complete example covering dataset, filters, and time_from. time_to is not directly explained, but the example makes the time-range convention easy to infer. This is meaningful added value beyond the raw schema.

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 states a clear verb-resource pair: 'Interroge un dataset Eurostat au grain complet' (queries a Eurostat dataset at full grain). This conveys the core function distinctly from search-oriented siblings like search_datasets, and the example with nama_10_gdp reinforces the resource type. It could be a 5, but full differentiation from get_indicators is only implicit, not fully stated in the purpose line.

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 gives a clear routing rule: for combining with environmental or infrastructure indicators, prefer get_indicators instead. This is a useful when/not-when signal relative to a sibling. It does not cover all comparison scenarios against other siblings, but the example and framing make the main intended call pattern understandable.

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