Precios del Campo

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the description is free to add the one thing they cannot: the exact shape of the payload (id, ámbito, unidad, frecuencia, fuente, último precio con fecha). Nothing is contradicted, though result-count behavior and empty-result handling are left unstated.

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?

Two sentences, front-loaded with the action and scope, then the return payload. The parenthetical examples are dense but each demonstrates a distinct query pattern (variedad, producto, producto+provincia), so no sentence is wasted.

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 carries the return contract and does so adequately, listing the fields an agent needs to pick a series id. It stops short of covering the limit/cap of 20 and what an empty match looks like, which matters for a free-text search over a fixed catalog.

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?

At 75% schema coverage the baseline is 3, and the description adds only illustrative value: examples like «gasóleo zaragoza» show that texto can combine product and province in free text. The `limite` parameter has no description in either schema or description, and ámbito/fuente distinctions are left to the 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 (busca) and resource (series de precios) with scope qualifiers — producto, variedad o provincia — and four concrete query examples. The return clause (identificador, ámbito, unidad, frecuencia, fuente, último precio) implicitly separates it from price-returning siblings like precio_ultimo, but no sibling is named explicitly.

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?

Usage is only implied: returning series identifiers suggests this is the discovery step that feeds historico/plazos/precio_ultimo, but neither the siblings nor the when-to-use condition are stated. The agent must infer routing from the sibling list alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds meaningful behavior: prices include taxes, are retail sale prices, are aggregated averages, and come with a province ranking plus cheapest/most expensive of the day. It does not state the unit (e.g., €/litro) or what happens on days with no publication.

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 that front-loads the subject (price of gasóleo B) and then enumerates scope, geography and included statistics. No filler, no repetition of the title.

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?

There is no output schema, and the description compensates well by enumerating the returned figures (means, ranking position, cheapest/most expensive). Minor gaps remain: measurement unit and behavior for provinces outside the peninsula/Balearics scope.

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 100% and the single param is documented with examples, so the baseline is 3. The description adds value beyond the schema by indicating that omitting the province still returns national and regional averages, clarifying the optional-parameter behavior.

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 names a specific resource and scope: average price of gasóleo B (agricultural) from the last published day, broken down by Spain, Comunitat Valenciana and an optional province. It is clearly a read/lookup tool and distinct from 'historico' and 'precio_ultimo', but it never explicitly contrasts itself with those siblings.

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?

Usage is implied by 'último día publicado' (use this for the latest day's figure, use 'historico' for series), but no alternative is named and there is no explicit when-not guidance. An agent must infer the routing from sibling names alone.

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

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds real behavior beyond them: truncation to the most recent points when exceeding max_puntos, default 104 and hard cap 520, the CSV escape hatch for the full series, and that values are data points rather than weeks/days so off-season gaps exist.

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 purpose, then coverage details, then truncation behavior; every clause carries information an agent needs. The parenthetical per-source frequency list is dense but justified, since it tells the agent what resolution to expect.

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 carries the burden of describing returns, and it does: data points within a range, capped to the N most recent, with a CSV link for the whole series. What it does not describe is the shape of each point (date/price fields), which is the main remaining gap for a 4-parameter 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 coverage is 75%, and the description compensates for the rest: it supplies the semantics of max_puntos (default and truncation-to-most-recent behavior the schema does not state) and of serie (id obtained from buscar_producto). The 'puntos con dato, no semanas ni días' note clarifies what desde/hasta actually select, adding meaning beyond the plain date formats.

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+resource: price series for an identifier between two dates, with the coverage granularity per source (weekly/daily, start years). It cleanly separates itself in substance from precio_ultimo and gasoleo_hoy by being a ranged series, but never names those siblings explicitly.

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?

Gives clear context: the identifier comes from buscar_producto, and 'para un periodo, se usan desde y hasta' tells the agent when to supply the range. It also explains the fallback when too many points exist (most recent returned, full series in the linked CSV), though it states no explicit when-not-use case.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive behavior, so safety is covered. The description adds what is returned (event meaning + official source), but says nothing about how far ahead the dates run, how many are returned, or coverage completeness.

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 front-loaded sentence with the resource, the topical scope, and the return content — no filler or redundant restatement of the title.

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?

No output schema exists, so the description must carry the return-value burden; it does so only partially by naming meaning and source but not ordering, horizon, or volume. For a zero-required-parameter informational tool this is adequate but leaves real questions open.

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 100% and both parameters (tema: «PAC»/«Impuestos», desde: AAAA-MM-DD, default today) are documented in-schema. The description mentions the same topics but adds no syntax or filtering nuance beyond the schema, so baseline 3 applies.

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 resource (próximas fechas oficiales para el campo) and even the payload (qué pasa ese día y su fuente oficial). It is unmistakable next to price/product siblings, though it doesn't explicitly contrast them.

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 domain (PAC, impuestos trimestrales) implies when to call it, but there is no explicit 'use this when…' or exclusion vs. siblings. An agent must infer that this is the calendar tool and the others are price tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it enumerates the payload (price, date and week, previous value, up/down/flat trend, source, license, link with chart and history), which is important since no output schema exists.

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?

One front-loaded sentence that leads with what is returned and then enumerates the fields; no filler. The return-field enumeration is dense but each item is informative, so little is wasted.

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?

Reasonable for a 4-param read tool, and the missing output schema is compensated by the field list. However, with zero required parameters it never says what happens when called with neither serie nor producto, nor how the two modes interact, which is a real ambiguity for an agent deciding how to invoke it.

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 75%, so the baseline is 3. The description reinforces the serie vs. producto distinction (identifier vs. text match), but says nothing about ambito (geographic scope) or limite (result cap, default 5, max 20), both of which an agent must discover from the schema alone.

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+resource (retrieves the last published price) and covers both lookup modes: by series identifier or by matching product text. It never names or contrasts the sibling tools (buscar_producto, historico, gasoleo_hoy), so an agent cannot tell from the description alone why to pick this over buscar_producto for a text query.

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?

Usage is implied: use it when you want the latest price, with the identifier route preferred over free-text search ("por su identificador" vs. schema's "si no sabes el identificador"). There are no explicit exclusions — nothing says to use historico for time series or gasoleo_hoy for fuel-specific queries, leaving overlap with siblings unresolved.

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