buscar_articulos

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

No annotations are provided, so the description carries the full behavioral burden. It discloses performance, request-per-bulletin behavior, defaults and caps, return fields to check (truncado, total_bomes, bomes_sin_coincidencia), and detailed search semantics including case/accent-insensitive substring, AND within an article, and OR via terminos.

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 is dense but well-organized: purpose is front-loaded, and the following sentences pack semantics, performance, limits, alternative tool, and output hints without filler. Every sentence contributes actionable 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 12-parameter tool with no annotations and no output schema, this description is unusually complete. It covers matching rules, complex term syntax, performance trade-offs, limits, the alternative tool, and key output fields. Only minor details like date-string format and full return shape are absent, but the core calling contract is well specified.

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 0%, so the description compensates by fully explaining the complex terminos object (texto, operador 'y'|'o', modo 'contiene'|'no_contiene') and the caps/defaults for max_bomes and max_articulos. Other parameters like anio, desde, hasta, organismo, consejeria, numero_bome, departamento, and numero_articulo are only named in the schema; their formats and ID semantics are not explained, though meanings are largely inferable.

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 action and resource: live search of ARTÍCULOS by their sumario, opening each bulletin and returning matching articles. It clearly differentiates from siblings by naming buscar_en_indice as the faster indexed alternative.

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?

It explicitly warns that the tool is slow (~0.5s per bulletin) and bounded by max_bomes/max_articulos, then directs to buscar_en_indice when the local index is synchronized. It also notes a unique benefit (retrieves articles omitted by bulletin pages), though it does not enumerate formal when-not-to-use conditions.

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