Listando palabras clave

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that filtering is LOCAL (backend doesn't filter), that comparison is case-insensitive and accent-insensitive, the 100-per-page size, and the 1..3 consecutive-pages cap with a 'nota' on truncation. It omits any permission/auth context, but for a read-only catalog this 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?

Front-loaded with the purpose, then cleanly separated into Args and Devuelve sections, so an agent can scan to the parameter it needs. It is information-dense rather than padded, though 'filtrado LOCAL' is repeated and the return-block detail is somewhat redundant given an output schema exists.

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?

Covers the essentials for a 4-param, 0%-coverage tool: filtering semantics, pagination limits, truncation behavior, and the id-based chaining into busqueda_avanzada. Because an output schema exists, the Devuelve block is a bonus rather than a necessity; the definition is complete enough to invoke correctly.

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 0%, so the description must compensate, and it fully does: all four parameters are documented with meaning beyond the schema — letra as initial letter with example, contiene as a substring with accent/case rules, page as the page of the FILTERED result, and paginas as consecutive pages in one call with a 1..3 bound. This is exactly what a 0%-coverage schema needs.

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 resource ('Catalogo de PALABRAS CLAVES del TC') with a concrete scale (29 603 exactas) and the operations (local filtering by initial letter or content). An agent immediately knows this returns a keyword catalog. It doesn't explicitly contrast itself with sibling listers like listar_tesauro or listar_filtros, though the downstream reference to busqueda_avanzada clarifies its role.

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 clear downstream context: 'Usa los id en busqueda_avanzada(palabras=1,3)', which tells the agent exactly why and how to consume the output. It also warns that filtering is LOCAL and the backend does not filter, which shapes invocation. It lacks explicit when-not-to-use or sibling-alternative guidance.

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