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

With no annotations, the description carries the full burden and does add real behavioral context: it discloses the per-call cost ($0.01 USD via x402) and the shape of what comes back (aggregates plus a capped set of 10 recent contracts). It stops short of describing failure modes, empty-result behavior, or what the 10-contract cap implies for older ranges.

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?

Three short sentences, front-loaded with domain and scope, then result contents, then cost. No filler and no repetition of the tool name.

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, so the description must convey return values, and it does so adequately by naming the aggregate blocks and the 10 recent contracts. Cost is covered; only edge-case behavior (invalid or unknown NIT, date-range effects) is left unaddressed.

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 both 'nit' and 'desde' are already fully documented, including the default 2022-01-01 and the natural-person exclusion. The description adds nothing about parameter semantics, so the 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 the resource and domain precisely: contracting history for a supplier in SECOP II (Colombia), and enumerates what is returned (totals, main entities, modalities, 10 recent contracts). It does not explicitly name the sibling radar_secop__riesgo as the alternative for risk scoring, so differentiation is implied rather than stated.

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 frames the tool as a history/lookup radar, which implies when to use it, but gives no explicit when-not conditions or comparison to radar_secop__riesgo or verificador_rues__verificar. The natural-person exclusion only appears in the schema, not in the description.

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