Buscando PAC

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

With no annotations the description carries the full behavioral burden, and it does disclose useful traits: the data is public, the required-entity constraint, and the exact shape of each row (entidad, ubigeo, última versión, cantidad de procesos, valor en Soles). What it omits is operational detail such as read-only/safety confirmation, result limits, or pagination.

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 purpose, then cleanly separated Args and Devuelve sections; each sentence earns its place, including the detalle_pac pointer. Slightly verbose in the return dict enumeration, but no genuine padding.

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 two-param search tool with no output schema and no annotations, describing the return dict and the required-entity constraint is appropriately thorough. The remaining gap is the absence of any hint about result volume/pagination for a search that can return many rows.

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 must compensate and it does: entidad is 'nombre o parte del nombre' with the example 'SEDAPAL' plus the reason it is required, and año carries an example ('2026') plus the valid catalog range 2019..2026. Both parameters are fully documented beyond the bare schema types.

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) plus a precisely scoped resource: PAC (planes anuales de contrataciones) públicos del SEACE, filtered por entidad y año. It also enumerates the returned per-row fields and names the drill-down sibling (detalle_pac), so an agent can separate it from buscar_acf, buscar_contratos, or detalle_pac without opening another 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?

Explains the operational constraint that drives usage (the PAC searcher obliga a elegir institución o ubigeo, hence entidad is required) and points to detalle_pac for the process listing. It lacks explicit when-not guidance versus other search siblings like buscar_acf or buscar_procesos, but the context is clear.

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