buscar_proveedores

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'Busca'; it does not state that results are paginated, whether filters can be combined, whether matching is exact or partial, or any read-only/safety cues. This is a significant gap for a tool with zero annotation coverage.

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 a single concise sentence with the verb and resource front-loaded. There is no filler, no repeated schema infomation, and every word contributes to understanding what the tool does.

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 moderate-complexity search tool with an output schema and self-descriptive optional parameters, the description is minimally viable: an agent can likely invoke it with at least one of the named criteria. However, with no annotations and no guidance on pagination/filter semantics or when to prefer obtener_proveedor, it is not fully complete.

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 partial compensating work by listing the main search parameters in plain language: nombre, RUC, categoría, and sancionado. It omits the two pagination parameters (pagina, items_por_pagina), though those are reasonably self-evident from their names/defaults. It adds no detail on optionality or how multiple filters interact.

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?

Identifies a specific action ('Busca') and a clear resource ('proveedores del Estado'), and enumerates the key search criteria (nombre, RUC, categoría, sancionado). This makes it distingushable from most sibling tools, which target processes, convocantes, catalogo, etc. It does not explicitly contrast with obtener_proveedor, but the verb difference makes that distinction usable.

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?

There is no when-to-use guidance, no mention of alternatives, and no exclusion such as 'use obtener_proveedor if you already have a RUC'. The description implies this is the search entry point for suppliers, but leaves all selection logic to inference.

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