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

With no annotations, the description carries the full burden and does reasonably well: it discloses that filters are case/accent insensitive, accept partial names, require all terms to be present, and that an empty filter set returns the most recent norms. It omits any note on result volume limits or upstream source behavior, but the observable call semantics are covered.

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?

Purpose and global filter behavior are front-loaded before the Args list, and each param line is terse and example-driven rather than padded. Length is justified by 12 parameters, though the bullet-per-argument style is slightly verbose.

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 search tool with 0% schema coverage, the description supplies everything needed to invoke it correctly, and the existence of an output schema removes any obligation to document return values. Sibling differentiation is the only thin spot, which is a usage rather than a completeness gap.

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%, yet the Args block documents all 12 parameters with types, formats (AAAA-MM-DD), ranges (limite 1-100), defaults (ascendente false, most recent first), examples for the taxonomy filters, and pagination semantics for saltar. This fully compensates for the schema's lack of descriptions.

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 opening sentence states a specific verb (Busca) and resource (normas de la Junta de Andalucía publicadas en el BOJA), making the tool's scope unambiguous. It does not, however, explicitly distinguish itself from siblings like contar_normas or obtener_norma, so an agent must infer the boundary from the verb alone.

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?

"Sin filtros devuelve las normas más recientes" gives one concrete usage condition and the saltar param points at pagination via siguiente_saltar. But there is no guidance on when to prefer this over contar_normas (counting) or obtener_norma (single-record retrieval), leaving the choice to inference.

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

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

No annotations and the description adds nothing about behavior beyond the count itself. It doesn't say whether it requires auth, whether it's a live count or cached, or what triggers staleness. However, the tool is trivial (a count) with an output schema, so the burden is lighter.

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?

Single short sentence, front-loaded, zero waste.

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?

With an output schema present, return values need not be explained, and there are no params. The description is sufficient for a trivial count tool, though a note about catalog scope would help marginally.

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?

Zero parameters; baseline 4 per rules. The description correctly implies no filtering parameters affect the count.

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 clearly it returns the total count of norms in the catalog ('Número total de normas disponibles en el catálogo'). The verb+resource is identifiable (count of normas) and distinguishable from siblings like buscar_normativa or obtener_norma, though 'contar' being absent makes it slightly less explicit.

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?

No guidance on when to use this counting tool versus buscar_normativa or listar_valores_filtro. The agent must infer usage context entirely.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose real caveats: the text comes from the BOJA website, may omit images or tables, and the signed PDF (pdf_oficial) is the authentic version. Pagination behavior is also surfaced via desde/max_caracteres. It omits return-format details, but those are covered by the output schema.

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?

Content is front-loaded: purpose, then the important authenticity caveat, then per-argument documentation. Every sentence carries information. The Args block is slightly verbose for three simple parameters, but nothing is wasted.

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 paginated read tool with an output schema present, the description supplies what the schema cannot: the data provenance, the authenticity caveat, and how to page through long texts. Return values need not be explained because an output schema exists. Only the relationship to obtener_norma is left implicit.

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 entirely, and it does: enlace_o_id is explained as an id from buscar_normativa or a BOJA URL, desde as the character offset for pagination, and max_caracteres as the fragment size with the valid 1000-100000 range. All three parameters are semantically richer than the bare schema.

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 (lee), resource (texto íntegro de una disposición) and source (BOJA), so an agent knows immediately this returns full text rather than metadata. It does not explicitly distinguish itself from the sibling obtener_norma, which is presumably the metadata counterpart, so it falls short of a 5.

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?

Usage is implied rather than stated: the id is sourced 'de buscar_normativa' and pagination params exist for long texts, which signals when to use this tool. However there is no explicit when-not or direct comparison against siblings like obtener_norma. Adequate but leaves routing to inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that contiene matching is case- and accent-insensitive, but says nothing about permissions, error behavior for invalid tipo, or result limits. The output schema covers return format, lowering that requirement.

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?

Purpose is front-loaded in a single sentence, followed by a compact Args block. No filler or redundancy, though the tipo line ("filtro a consultar") borders on restating the field 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?

For a simple two-parameter enum lookup with an output schema, the description covers enough to invoke correctly. It is missing routing guidance versus sibling search tools and any error/edge-case behavior, but nothing critical for a correct call is absent.

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. It explains both parameters, adding the non-obvious matching semantics of contiene (case/accent insensitive) that the schema does not convey; tipo's valid values are already covered by the enum in the schema.

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 (Lista) and resource (valores existentes de un filtro de búsqueda), so the agent knows it enumerates valid filter values. It does not explicitly differentiate itself from siblings like buscar_normativa, but the purpose is unambiguous.

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?

Usage is implied by the purpose: you call it to discover valid values for a search filter. There is no explicit when-to-use statement, no mention of alternatives such as buscar_normativa, and no prerequisites or exclusions.

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

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, and it discloses almost nothing beyond the read-and-return intent. It does not say whether the operation is read-only, what happens when the id does not exist, or whether any permission is needed.

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?

A single front-loaded sentence with no filler; the retrieval action and its key are both stated immediately.

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 one-parameter lookup with an output schema covering return values, the description covers what the tool does and what the input is. Only failure behavior and sibling routing are absent, which are minor for this shape of tool.

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%, but the description names the single parameter and ties it to the field "id", giving the agent some semantic anchor. It adds no format guidance (e.g., what an id looks like) beyond the schema's bare string type.

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 and resource: "Devuelve la ficha completa de una norma" and the retrieval key ("a partir de su identificador"). This distinguishes it from contar_normas (counting), buscar_normativa (searching) and leer_texto_boja (reading raw text), though it never names those siblings explicitly.

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?

Usage is implied by "a partir de su identificador": you call this when you already have an id. There is no explicit when-to-use vs buscar_normativa, no statement of prerequisites, and no exclusions.

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