Revisamos el Coche

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered; the description adds real behavioral context on top — it normalizes loose user phrasing and deliberately abstains on ambiguity rather than guessing. It does not describe the shape of the returned list.

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 tight sentences, front-loaded with the normalization purpose and followed immediately by the fallback rule. No filler and nothing that could be cut without losing information.

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 one-parameter read-only lookup with no output schema, the description covers purpose, input interpretation, and the ambiguity fallback. The only gap is a hint about what the returned revisions list looks like, which a caller might want since no output schema exists.

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 parameter is self-documenting, so baseline is 3. The description adds value by giving concrete examples of the free-text input ("un Golf", "una furgoneta") and confirming the parameter is verbatim user speech, which the schema only states abstractly.

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: it translates a free-text vehicle mention into a catalog vehicle type and returns the available revisions. This is clearly distinct from pricing, booking, and availability siblings, though it never names an alternative 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 a clear usage context (the person described their vehicle informally) and an explicit when-not: if the vehicle can't be determined with confidence, do not guess and return the list instead so the agent can ask. No sibling alternatives are named, which keeps it short of a 5.

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, closed-world. The description adds real value on top: the returned value is authoritative and matches the website exactly, so the agent must not round or recompute it. It omits what happens on invalid province/vehicle inputs, keeping it from a 5.

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 short sentences with the price definition front-loaded and the 'don't recompute' constraint following. Efficient and well-ordered, with no filler.

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 query with no output schema, the description implies a single numeric return ('el mismo número que enseña la web') and covers the core inputs, but leaves several parameters unexplained and gives no error/fallback behavior. Adequate but with visible gaps.

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 only 33% (6 params, 2 documented inline), so the description must compensate. It identifies the three inputs that drive the price (vehicle, reports, province), which helps, but says nothing about ciudad_id or token_perito, leaving gaps in both sources.

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 specific resource and result: the price of the revisión for a given vehicle, reports, and province. It distinguishes the operation from transactional siblings like crear_reserva or estado_reserva, though it does not name those alternatives 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: the 'no lo calcules tú ni lo redondees' instruction strongly nudges the agent to call the tool for prices rather than deriving them, but there is no explicit when-to-use/when-not or routing to a sibling. This is a minimum-viable signal, not real guidance.

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 readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: an empty resumen_confirmado causes nothing to be created and instead returns the summary for the agent to read back. It does not describe what a successful call returns or any auth/rate characteristics.

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?

Four short sentences, zero filler. The most important fact (the only tool that creates anything) is front-loaded, followed by the precondition and then the failure mode of the confirmation field.

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 19-parameter, 10-required creation tool with no output schema, the description covers the critical confirmation gating and the empty-resumen behaviour well, and annotations cover the safety profile. However, a large share of required parameters remain unexplained anywhere, and the success return value is left implicit, so more guidance would help.

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 42%, so the description should carry more weight than the baseline. It does add real meaning for resumen_confirmado (must contain exactly what was read to the person; empty means no creation) and enumerates its expected content, but the remaining undocumented parameters (nombre, email, tipo_vehiculo_id, tipo_informe_ids, acepta_condiciones, autorizacion_vendedor, etc.) 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+resource ('Da de alta la solicitud de revisión') and explicitly differentiates itself from every sibling by declaring 'Es la ÚNICA herramienta que crea algo'. An agent can immediately tell this apart from buscar_servicio, consultar_precio or estado_reserva without opening any schema.

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 a concrete, hard precondition for calling it: the person must have been told out loud what they are contracting (vehicle, report, province, price) and must have said yes. This is clear when-to-use context, though it does not name alternative tools or describe failure/retry paths, so it falls just short of a 5.

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, closed-world), but the description adds real behavioral context beyond them: both the reference and the creating email are mandatory, and the reference alone will not resolve. That composite-key requirement is exactly the kind of detail annotations cannot carry.

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 short sentences, purpose front-loaded, prerequisite second. No filler and nothing repeated from the schema or annotations.

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?

Adequate for a simple read tool: with no output schema the description needn't explain the return shape, and annotations already establish safety. The only missing piece is any hint about what the status response contains, which is minor.

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?

With 0% schema description coverage, the description does the heavy lifting by mapping the bare parameters (token_reserva, email) to concepts and stating that the email must be the one used at creation. It stops short of giving the token's format or where to find it, but compensates well for undocumented params.

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?

Names a specific verb (obtener el estado) and resource (una solicitud ya hecha), so an agent knows exactly what this returns. It does not explicitly contrast with siblings like crear_reserva or consultar_precio, but the distinction is inferable from the resource.

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: this is the tool to use once a reservation already exists. No alternative tool is named and no explicit when-not condition is given, which is the main gap for routing against crear_reserva.

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, closed-world), and the description adds real behavioral context beyond them: the check is an absence test over a range, not a slot lookup, and exact scheduling happens out-of-band. This corrects the misleading name and prevents an agent from over-promising. It stops short of describing the result format, but that gap is minor.

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?

Four short sentences, purpose front-loaded, followed by the caveats that matter. 'No prometas una hora' partially restates 'no tiene agenda por horas', but as a directive to the agent it earns its place. No padding otherwise.

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 3-parameter read-only tool with no output schema, the essential missing piece is what the return means, and the description addresses that directly (presence/absence over a range rather than concrete slots). Combined with annotations, an agent has enough to call it and interpret the answer without over-committing.

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 67%: 'desde' and 'hasta' carry AAAA-MM-DD format hints, while 'token_perito' is undocumented in both schema and description. The description refers to the two dates and 'ese perito' only in natural language and adds no format or identity semantics, so it neither compensates for the gap nor detracts. Baseline 3 is appropriate.

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: it checks whether a given expert ('ese perito') is available between two dates. It also preempts a likely misreading of the name 'huecos_disponibles' by clarifying that no hourly slots exist. It does not explicitly contrast itself with booking siblings like crear_reserva, but the purpose is unambiguous.

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?

Provides operational guidance on how to treat the result ('la fecha concreta se acuerda después con el perito', 'no prometas una hora'), which is genuinely useful. It does not, however, say when to call this versus siblings such as crear_reserva or consultar_precio, so the routing decision is left to inference.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral rule beyond that – experts on vacation are excluded from the results – but says nothing about ordering, empty-result behavior, or what the rating/price fields represent.

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 short sentences, front-loaded with what is returned and followed by the one exclusion rule. No filler, though it is arguably too terse for the low schema coverage it is compensating for.

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 query with no output schema, the description does say what comes back (experts with valuation and price). It still leaves gaps an agent needs: how provincia and provincia_id interact, what the required tipo_vehiculo_id expects, and result ordering or pagination.

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 33%: provincia has a description warning not to invent ids, while provincia_id and the required tipo_vehiculo_id are undocumented. The description maps its two filters onto provincia/provincia_id and tipo_vehiculo_id conceptually, but does not explain the id-vs-name relationship or clarify anything the schema leaves blank.

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 concrete verb-and-resource: it returns the peritos (experts) covering a given province and vehicle type, together with their rating and price. That is enough to distinguish it from consultar_precio and buscar_servicio, though it never names a sibling to contrast against.

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: an agent can infer this is the lookup for finding available experts for a province/vehicle combination, but there is no explicit when-to-use, when-not, or routing to alternatives such as buscar_servicio or consultar_precio.

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