Ver serie de un indicador diario del BCE

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower, and the description still adds real behavioral context: a hard 366-row cap on results and the fallback rule that ultimos_n governs when no date range is supplied. It doesn't disclose pagination or what happens when both a range and ultimos_n are provided, but the added row cap is a useful operational constraint beyond the annotations.

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?

A single dense sentence with the resource, the source of the identifiers, and the retrieval modes all front-loaded; no filler. It is compact enough that nothing could be cut without losing information, though the nested parenthetical slightly crowds the core statement.

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?

For a read-only series fetch with no output schema, the description plus schema are nearly sufficient: the format parameter in the schema covers the text/json return shape, and the description covers scope and the result cap. The only gaps are precedence when both a date range and ultimos_n are given and whether 366 rows truncates silently, which are minor for a read tool.

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 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains the interplay between ultimos_n and the desde/hasta range, and imposes a 366-row ceiling that applies to results regardless of the parameter combination chosen. That is genuine semantic value on top of the fully documented 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?

States a specific verb and resource: retrieves a single BCE daily/monthly indicator series, with a clear scope ('one' series, capped at 366 rows). It distinguishes itself from list_catalogo by naming it as the source of the required identifiers, but it does not differentiate from the nearby siblings get_indicador_bce or search_indicadores_bce, which an agent could easily confuse with this 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?

Implies usage through the prerequisite 'archivo and codigo from list_catalogo(fuente='bce_diarios')', which tells the agent where the required identifiers come from, and clarifies that ultimos_n applies when no date range is given. However, it offers no explicit statement of when to pick this tool over get_indicador_bce, search_indicadores_bce, or get_serie_internacional, leaving the routing decision to inference.

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