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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful context that the corpus is limited to the Academia Judicial's good-practice guides across six subject areas, but says nothing about result format, ranking, 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?

A single, front-loaded sentence with no filler; the resource and its scope are stated immediately. It is appropriately sized for a simple two-parameter search tool.

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 read-only search tool with no output schema, annotations cover safety and the description covers source and subject scope. The main gap is routing: with ~70 siblings, nothing tells the agent when to pick this corpus over the many other jurisprudential search tools.

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 100%, so both parameters are already documented; baseline is 3. The description's parenthetical ('penal, determinación de penas, laboral, familia, ética, IA') loosely maps to the optional 'materia' parameter but actually lists more areas than the schema enumerates ('Penal', 'Laboral', 'Familia', 'Ética Judicial'), so it adds marginal, slightly inconsistent value.

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') and a specific, named resource ('Guías Oficiales de Buenas Prácticas Judiciales de la Academia Judicial de Chile'), which clearly distinguishes it from sibling search tools like pjud_search_jurisprudencia or doctrina_search. It does not, however, explicitly name or contrast those siblings.

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 / when-not-to-use guidance and no named alternative, despite a crowded field of sibling search tools (pjud_search_jurisprudencia, cgr_search_jurisprudencia, busqueda_universal). The parenthetical subject list implies topical scope but does not tell the agent when this source is the right one.

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?

Annotations declare readOnlyHint=true, but the description says it 'generates and exports' templates and the sole parameter is a target_dir described as 'Directorio destino para guardar los archivos de configuración' (destination directory to save the config files). Writing files to disk is a mutation of the environment, directly contradicting the read-only hint.

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 wasted words that names the output artifact and its destinations. It is efficient, though the compressed phrasing leaves the read/write nature ambiguous.

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 no output schema and one optional parameter, the description covers the output destinations well, but it never clarifies the write/export side effects (file creation, overwriting, permissions) that matter most for a tool touching the filesystem, leaving a meaningful 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 100% for the single optional target_dir parameter, so the schema already documents it. The description adds no extra parameter meaning (no defaults, formats, or overwrite behavior), so the baseline of 3 applies.

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 pair (generates and exports) and a concrete resource (legal subagent templates and profiles), naming the exact target formats/paths (.claude/agents/*.md, .cursor/rules/*.mdc). This is clearly distinguishable in intent from siblings like agent_list or agent_run, though it never explicitly contrasts itself against them.

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, when-not-to-use, or alternative-routing guidance. The description only says what the tool produces, leaving the agent to infer the triggering context on its own.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return contents (descriptions, competencias forenses, herramientas asignadas), which is useful given no output schema, but says nothing about pagination or the fixed count's stability.

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, though the hardcoded count "17" is a detail that can silently go stale.

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 zero-parameter list tool with no output schema, the description adequately enumerates what comes back. It is nearly complete, missing only whether the result is the full catalog or paginated.

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?

The tool takes zero parameters, so there is nothing to document beyond confirming it is a no-argument call. Baseline 4 applies.

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 a precise resource ("catálogo de los 17 agentes jurídicos especializados de Open Legal Chile") plus what each entry contains. An agent can distinguish it from agent_run, but the description never explicitly contrasts the two, so it stops short of full sibling differentiation.

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 and no mention of alternatives such as agent_run or agent_export_subagents. The discovery-then-run workflow is only implied, so an agent gets no explicit routing signal.

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?

Adds real context beyond annotations: autonomous coordination of suite tools and a 'determinista soberano' offline mode versus LLM mode. However, it does not disclose latency, cost, whether delegated tools can mutate state, or what the run returns — notable gaps for an orchestrator, and there is mild tension between 'autonomously coordinating tools' and readOnlyHint=true.

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 the verb leading, no filler or repetition. It is dense — the alias list and mode clause pack a lot in — but every element earns its place.

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 an open-world orchestrator with no output schema and a nested context object, the description is thin: no indication of return shape, synchronous vs long-running behavior, failure modes, or how mode='auto' resolves. The agent is left to discover critical runtime behavior on its own.

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 100%, so the baseline is 3. The description reinforces agent_name (alias list) and mode ('determinista soberano o LLM') but adds no syntax or format detail beyond what the schema already documents for task, context, and mode.

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 ('Ejecuta') and resource ('agente jurídico especializado'), with concrete agent aliases that map to the agent_name parameter. It reads clearly against siblings like agent_list or consulta_maestra, though it never explicitly names an alternative to distinguish itself from them.

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?

Implies usage for 'un objetivo legal complejo' and hints at the deterministic-vs-LLM choice, but gives no explicit when-to-use/when-not guidance or comparison to orchestrator siblings such as caso_ejecutar, consulta_maestra, or caso_analizar. The agent must infer the routing decision.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that – no indication of result volume, pagination, or what sources are actually returned – so it earns little credit on this dimension.

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 covering scope and sources with no filler. It is efficient, though the brevity comes at the cost of the usage and behavioral detail the tool would benefit from.

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 no output schema, the description should at least signal what a search returns, and it does not. For a two-parameter read-only search tool this is minimally adequate – the inputs are clear from the schema – but the return expectations are left entirely open.

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 100%, with both 'query' and 'tribunal' documented (including example values and the 1TA/2TA/3TA options), so the schema carries the parameter burden. The description repeats the tribunal list but adds no filtering syntax or format meaning beyond it; baseline 3 applies.

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') and a specific resource (jurisprudencia de los Tribunales Ambientales and Compendios Anuales), naming the three covered tribunals. It does not, however, differentiate itself from the overlapping sibling ambiental_consulta_maestra, so the agent cannot tell from the text alone which search surface to prefer.

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 when-to-use, when-not-to-use, or alternative-tool guidance is given, despite several sibling search tools (ambiental_consulta_maestra, pjud_search_jurisprudencia) that could compete for the same request. Usage is only implied by the verb 'Busca'.

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?

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses that the search is single-step across multiple corpora, that it returns a plan plus literal-text results with citations in a specific [Hugging Face - <archivo>] format, and that incluir_subgrafo triggers LegalGraphify with token savings.

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-loads the decisive routing cue ('PRIMERA consulta cuando... materia ambiental') before the source inventory. The enumeration of corpora and the citation/subgraph clauses are dense but each carries useful information; it is long but not padded.

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 no output schema, the description steps in to describe the return (plan, results with literal text, citations). All three parameters are documented and the read-only nature is clear from annotations. Minor gap: nothing about result limits behavior or how the plan is structured, but overall the agent has enough to invoke it 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 description coverage is 100%, so the baseline is 3. The description reinforces the meaning of incluir_subgrafo (subgrafo LegalGraphify + ahorro de tokens) and contextualizes the consulta parameter, but adds little about 'limite' beyond what the schema already says, so it does not exceed the schema-driven baseline.

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/consulta) and a well-defined resource: the 886 sentencias of the Tribunales Ambientales plus biblioteca and doctrina ambiental, and positions itself as the 'PRIMERA consulta' for environmental matters. It never names the closest sibling (ambiental_buscar_jurisprudencia) or other alternatives, so differentiation is implied by the breadth of scope rather than stated.

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 a clear trigger condition ('PRIMERA consulta cuando la consulta o el caso es de materia ambiental') and enumerates the qualifying subject areas (SMA, SEIA/RCA, daño ambiental, tribunales ambientales, humedales, LO-SMA). It also explains when to set incluir_subgrafo=true, but offers no when-not-to-use guidance and does not name the sibling tools to use for non-environmental queries.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context on the corpus boundary (which codes exist) and hints that omitting the article parameter yields structure rather than text, but says nothing about result size, pagination or full-text vs summary returns.

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 dense sentence that front-loads the verb and the queryable universe; no filler. The parenthetical enumeration is long but earns its place by defining valid inputs.

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 read-only lookup with annotations covering the safety profile and no output schema to explain, the definition supplies enough: corpus scope, input universe, and the article-vs-structure distinction. It lacks only operational details such as return format and pagination, which are minor here.

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 100% with only two parameters, and the description goes beyond the schema's illustrative examples by enumerating the complete valid set of code names plus the Constitución and Código Sanitario, effectively supplying the missing enum. The 'estructura' wording also clarifies what happens when 'articulo' is omitted.

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?

Names a specific verb ('Consulta'), the resource type (artículos o estructura) and enumerates exactly which codes are covered, so an agent knows this reaches the 9 Códigos, the Constitución and the Código Sanitario. It stops short of explicitly differentiating itself from close siblings such as bcn_get_ley and bcn_get_codigo_historico, which an agent must infer from the scope wording.

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 scope statement: consult a code by name, optionally drilling into a single article. There is no explicit when-to-use guidance and no exclusion pointing to bcn_get_ley for individual laws or bcn_get_codigo_historico for prior versions, so routing among siblings is left 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?

Annotations already establish read-only, non-destructive, open-world behavior. The description adds meaningful context beyond annotations: it discloses that results come from real LeyChile version history and specifies the returned effective version, official link, and optional article text.

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 core action and scope, followed by return information and a concrete use case. It is compact and every sentence contributes without repetition.

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 read-only historical lookup with no output schema, the description is largely sufficient: it explains purpose, temporal scope, return components, and a motivating use case. It omits edge cases such as what happens when no version exists at the requested date, but the essential calling information is present.

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 100%, so the baseline is 3. The description nevertheless adds meaning by clarifying the historical date format, giving examples for 'codigo' (civil, trabajo, cpc, penal), and explaining that 'articulo' triggers retrieval of the article text at that date.

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 ('Consulta un Código de la República') scoped to a historical date and LeyChile version history. This clearly separates it from siblings like bcn_get_codigo (current code) and bcn_get_ley_historica (historical law), even without naming them 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?

Provides a clear use case ('Ideal para ver cómo cambió una norma (p. ej. la jornada de 45 a 40 horas)'), giving the agent strong context for when this tool is appropriate. It does not, however, state when not to use it or name the alternative tools for current-version lookups.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful quality guarantee ('texto oficial y vigente'), but says nothing about retrieval behavior, pagination, or what happens when a number/article does not exist. Adds some value above annotations, hence a 3.

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 sentence, front-loaded with the core action, and the parenthetical examples earn their space by clarifying the expected number format and domain.

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 read-only retrieval tool with a full-coverage schema and no output schema, the description covers what it returns (official, in-force text) and how to address it. It omits edge cases such as unknown law numbers or missing articles, which is a minor gap rather than a blocking one.

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 100%, so both parameters are already documented (numero required, articulo optional). The description reinforces the numeric format with concrete examples (21.643, 21.561, 19.886) but never mentions the optional 'articulo' parameter. Baseline 3 is appropriate.

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 (Consulta) and resource (texto oficial y vigente de una ley chilena) plus the lookup key (número). The word 'vigente' implicitly separates it from the sibling bcn_get_ley_historica, but it never names that sibling or bcn_get_codigo explicitly, so differentiation is inferred rather than stated.

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?

The 'vigente' qualifier implies you should use this for the current in-force text rather than the historical one, which is a useful cue. However, there is no explicit when-to-use or when-not-to-use statement, and no mention of the near-identical bcn_get_ley_historica / bcn_get_codigo siblings, so routing is left 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the historical-dating semantics and that the date must be a specific historical date, but says nothing about what happens for dates outside a law's validity range or about return shape. With annotations carrying the safety burden, a 3 is appropriate.

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 that carries the action, the resource, the date-format constraint, and the purpose with zero filler. Nothing is redundant or 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 read-only BCN lookup with 100% schema coverage and no output schema, the description is nearly sufficient; the caller knows what it retrieves and why. It could be stronger by noting the sibling for current text and edge behavior on invalid/out-of-range dates, but nothing essential is missing.

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 100%, so the schema already documents fecha (YYYY-MM-DD with example), numero, and articulo. The description restates only the date format already in the schema and adds no meaning for numero or articulo. Baseline 3 applies when the schema does the heavy lifting.

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 verb (Consulta), resource (el texto de una ley chilena), and a precise scope constraint (vigente en una fecha histórica específica en la BCN). This clearly separates it from bcn_get_ley (current text) since it emphasizes historical-date validity, though it never names the sibling 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?

The clause 'para control de derecho intertemporal' implies the intended use case (checking which version of a law applied on a past date), which is useful context. However, it states no alternatives or exclusions – an agent gets no explicit guidance to prefer bcn_get_ley when the current text is wanted, or bcn_get_codigo_historico for codes.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it produces a catalog, metrics and packages for three external platforms, but it does not clarify whether it merely generates local artifacts or actually uploads to Hugging Face/GitHub/Drive — a meaningful ambiguity for an openWorld tool.

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?

One front-loaded sentence with no filler, naming the artifact types and the three target platforms. Slightly dense, but every clause carries 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?

With no output schema, the description should say what the tool returns or where the packages land. It never explains the 'manifiesto' the tool is named after, nor the resulting file locations, so an agent knows the intent but not the outcome.

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 100% and the single parameter generar_bundles is fully documented in the schema. The description never mentions the flag, so it adds no meaning beyond the schema; baseline 3 applies.

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 concrete verb (compila) and resource (catálogo y métricas de la biblioteca online de Markdown de doctrina) plus the outputs it produces (paquetes para Hugging Face, GitHub y Google Drive). It is specific and distinguishable, though it never differentiates itself from any sibling tool or explains the relationship to the huggingface_* / doctrina_* family.

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 prerequisites, and no mention of alternatives. An agent cannot tell from the description whether this is a routine sync, a publish step, or something that should run only after ingesta de documentos.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-web behavior are covered. The description adds that results come back 'con sus citas listas', a useful callback on output format, but nothing about rate limits, latency/volume expectations across 10 sources, or partial-failure behavior. Beyond-annotation value is thin.

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 efficient sentence that front-loads the verb, the enumerable source list, and the return-value promise. The enumerations are long but informative; nothing semantically redundant.

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 read-only, single-parameter meta-search tool with a 100% covered schema and no output schema, the description is adequate: it names the sources and promises citations. But it omits expected result volume across 10 organisms, pagination, and how it relates to the many source-specific siblings, leaving moderate gaps.

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 100% with a single parameter whose description ('Término o frase a buscar') already documents syntax. The description adds only that it's one term at a time ('un término a la vez'), which is mildly clarifying against the schema, matching the baseline 3 for full schema coverage.

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) and resource (término en 10 organismos del Estado) and enumerates the exact sources, which disambiguates from the many sibling search tools for individual sources like pjud_search_jurisprudencia or sii_search_circulares. However, it does not explicitly name a competing sibling tool that overlaps as a universal/maestra alternative (e.g. consulta_maestra), so differentiation is implicit rather than stated.

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?

The phrase 'un término a la vez' implies one query term per call, which is light guidance on how to invoke. But there is no explicit when-to-use vs. the source-specific siblings, no exclusions, and no naming of an alternative tool despite a crowded search landscape.

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?

Annotations already declare readOnlyHint/true, destructiveHint/false and openWorldHint/true, and the description usefully adds that it only reads supplied input and that materia is classified by deterministic rules (Rol/RIT + keywords) with an explicit 'no alcanza la información, lo dice' failure mode. However, the blanket claim 'no consulta servicios externos' conflicts with openWorldHint=true and with its own estudio_completo parameter, which performs BCN normativa and FTS5 doctrine lookups – a materially misleading capability statement for an agent deciding whether to call it.

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 trigger rule and example utterances, then the deliverable, then behavioral limits – a sensible priority order. It is somewhat wordy (many quoted sample phrases), but each sentence carries routing or expectation-setting value.

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 no output schema, the description compensates by spelling out the shape of the returned PLAN, which is exactly what an agent needs to sequence follow-up tools. It omits the relationship to caso_ejecutar and under-describes the external-call behavior of estudio_completo, but for a 5-param read-only planner it is close to sufficient.

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 100% across all five parameters, so tipo, entrada, consulta, estudio_completo and generar_dashboard are already documented in structured data. The description adds nothing parameter-specific (it does not mention estudio_completo, generar_dashboard, or the tipo enum), so the baseline 3 applies.

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 names a specific action (analizar) and resource (caso/carpeta/expediente/documentos) and states precisely what the tool returns: a PLAN covering qué se trata, qué herramientas usar y en qué orden, y qué falta. That plan-vs-execution framing implicitly separates it from caso_ejecutar without needing to open either 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?

Trigger guidance is unusually explicit – 'Usala SIEMPRE que la persona pida analizar un caso... aunque no nombre ninguna herramienta', backed by four example utterances that cover the common phrasings. It lacks an explicit when-not clause or a named alternative (e.g. route to caso_ejecutar once the plan is defined), so it stops short of a 5.

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?

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, yet the description adds genuinely new behavior: it may be slow because every step hits the real source, and failed steps are recorded with their error rather than fabricating a result. That latency and failure-semantics disclosure is valuable beyond the annotations, though auth/rate-limit context and return shape are absent.

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?

Three tight sentences, front-loaded with purpose, then scope, then the latency and error-handling caveats. No sentence is filler.

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 4-parameter, no-output-schema tool the description covers purpose, real-source behavior, latency and failure handling well. The remaining gap is that the three undocumented input parameters are left for the agent to guess.

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 only 25% (only 'pasos' is documented), so the description must compensate and largely does not: 'entrada', 'tipo' (the carpeta/texto/consulta enum) and 'limite_pasos' are unexplained. It only indirectly signals the step-based model via 'el plan' and 'cada paso'.

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 opens with a specific verb and resource ('Ejecuta el plan de caso_analizar') and names the sibling that produces its input, so an agent can immediately tell it apart from caso_analizar and the many search_* siblings. It also enumerates the concrete scope (State services, indexed doctrine, folder documents).

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 clearly implies the workflow: run this after caso_analizar to execute the generated plan. That is strong contextual guidance, but it never states when NOT to use it or how to pick between it and the individual service tools it wraps.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds that the returned content is the 'checklist oficial' with named document types, which is useful scope, but says nothing about format, permissions, or limits. With annotations carrying the safety burden, a 3 is appropriate.

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 zero filler; the parenthetical enumerates the concrete document categories, each word earning its place.

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 read-only reference tool with no output schema, one well-documented parameter, and annotations covering safety, the description is essentially sufficient. It could be complete with a note on how tipo_inmueble alters the checklist, but nothing critical is missing.

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 100% and the sole parameter (tipo_inmueble) is fully documented in the schema with its default. The description never mentions the property-type parameter or how it changes the checklist. Baseline 3 applies since the schema does all the work.

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?

Specific verb 'Retorna' plus a precise resource: the official document checklist for a Chilean title study, itemizing the actual document categories (GP 30 años, dominio vigente, DOM, TGR). An agent immediately knows this is a static reference lookup, not the study itself. It does not explicitly contrast with the sibling cbr_estudio_titulos, 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?

The description implies usage (fetch the required-documents checklist before/while doing a title study) but never states when to select this tool versus cbr_estudio_titulos or any other sibling. There are no exclusions or prerequisite conditions. Implied context only, nothing explicit.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful domain context (the 10-year legal basis and the defect classes it detects), but says nothing about output format, how findings are structured, or performance on large input lists.

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 legal basis is parenthetically embedded and every clause names a concrete capability. Nothing to trim.

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 an analysis tool with no output schema and a nested array input, the description should hint at what the audit returns (findings list, severity, per-inscription results). It names the defect classes it looks for but leaves the response shape entirely unspecified.

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 100%, so both parameters are already documented in the schema. The description reinforces the 'decenal' (10-year) concept tied to anios_requeridos' default but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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 ('Audita') and a well-defined resource (cadena de títulos de dominio decenal e inscripciones CBR), plus the defects it hunts for (rupturas en la tradición, gravámenes no alzados, falta de posesión efectiva). An agent can tell what it does, though it does not explicitly distinguish itself from the closest sibling cbr_checklist_documentos.

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 only implied by the audit scope; there is no explicit statement of when to reach for this versus cbr_checklist_documentos or the search tools. No prerequisites (e.g., required input data shape) or exclusions are given.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds the corpus size and document types being searched, but says nothing about result format, ranking, or result limits for an open-world search.

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 that carries the verb, the corpus, and the scope with zero filler. Every word earns its place.

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 search tool with no output schema, the description covers what is searched but omits what comes back (fields, count, ranking). Adequate but leaves the agent guessing about result shape.

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?

Only one parameter with 100% schema description coverage, and the schema itself supplies examples ('Municipalidad de Santiago', 'Hospital'). The description adds no syntax or matching-behavior detail beyond that, so the baseline of 3 applies.

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) and a precisely scoped resource: the catalog of 9,600+ Final Audit Reports and special investigations from the Contraloría. This is clearly distinguishable from the sibling cgr_search_jurisprudencia by corpus, though it never explicitly names that sibling.

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 when-to-use, when-not-to-use, or alternative guidance is given. The description only states what corpus is searched, leaving the agent to infer that this is the tool for audit reports rather than jurisprudence or normativa.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the content qualifier 'vinculantes' and nothing about result limits, ranking, or coverage of the source corpus, so it sits at the annotation-supported baseline.

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?

One sentence, front-loaded with the verb and scope, with no filler. It is efficient, though it is arguably minimal for the tool's discovery needs.

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 one-parameter, read-only search over an open-world corpus with full schema coverage and no output schema, the description is largely sufficient. It omits any hint about result volume or how binding dictámenes relate to other CGR content, which is a minor 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?

With a single parameter at 100% schema description coverage, the schema already documents 'query' with an example. The description adds no query syntax, operator, or language guidance beyond the schema, so the baseline 3 applies.

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') and a precisely scoped resource ('dictámenes vinculantes en la jurisprudencia administrativa de la CGR'), which lets an agent separate it from cgr_search_auditorias. It does not explicitly name a sibling for contrast, 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?

There is no statement of when to use this tool versus alternatives such as pjud_search_jurisprudencia or ambiental_buscar_jurisprudencia. Usage is only inferable from the word 'Busca' and the CGR scope; no exclusions or prerequisites are given.

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?

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), so the description is free to add the operational detail it does: that batching costs 'una pasada de red por norma única' and that citing is blocked without fetched text. The failure-handling behavior is only in the schema (`faltantes`), not the description, which keeps this from a 5.

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?

Three sentences, zero padding, and each does distinct work: purpose, precondition, batch guidance. The core verb and resource are front-loaded before any caveat.

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 no output schema, the description carries the return-shape burden and does describe the literal text plus bracket and link. It stops short of covering the single-`referencia` miss case (only the batch `faltantes` path is documented), but for a two-parameter read tool this is close to 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?

Schema coverage is 100% with concrete examples for both `referencia` and `referencias`, so the baseline is 3. The description adds real value beyond the schema by explaining the batching rationale ('una sola llamada, una pasada de red por norma única'), clarifying why to prefer the array parameter.

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 el TEXTO LITERAL de una norma citada') plus the return payload (corchete oficial, enlace), which is more than a restatement of the name. It does not explicitly name or contrast with adjacent retrieval tools like bcn_get_ley or bcn_get_codigo, so the distinction is inferred rather than stated.

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?

'Usala antes de citar cualquier artículo: el producto no cita sin texto' gives a concrete precondition for invoking the tool. It also tells the agent when to switch to batch mode via `referencias`. No explicit when-not-to-use or named alternative is provided, so it falls short of a 5.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the audit is formal and occurs before electronic signature, but it does not explain what the audit evaluates or what kind of result is returned.

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, focused sentence that front-loads the core action and includes the key workflow constraint. It contains no redundant or filler language.

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?

The description adequately covers the input context and the tool's role in the signing workflow. Because there is no output schema, however, it leaves the expected audit output or findings unexplained, which would help an agent understand the result.

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 100%, with both 'tribunal' and 'borrador_texto' documented in the input schema. The description does not add any additional meaning about these parameters, so the baseline of 3 applies.

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 verb and resource: 'Audita formalmente el borrador de un escrito'. It also scopes the action to drafts written by an intern before the supervising lawyer's electronic signature. However, it does not explicitly distinguish this tool from related siblings such as critique_documento.

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?

The description gives clear usage context: the tool is meant for a draft produced by an intern and used prior to the tutor lawyer's electronic signature. It does not state when not to use it or name an alternative tool, but the intended moment in the workflow is explicit.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds domain context but does not reconcile the tension between a name/verb implying intake registration and a read-only hint, nor does it say whether anything is persisted or what the tool returns. With annotations doing the heavy lifting, a 3 is appropriate.

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 well-formed sentence with the action and resource front-loaded and the qualifying scope trailing. Nothing is redundant or padded.

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 generator with no output schema and a nested required object, the description is thin: it never explains the return artifact (the generated ficha) or how datos_usuario is consumed. It is adequate to identify the tool but leaves meaningful gaps about what the agent gets back.

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 100%, so both the materia enum-like values and the nested datos_usuario dictionary are already documented in the schema. The description adds no parameter syntax or meaning beyond that, which matches the baseline 3 when the schema carries the burden.

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 pairs a specific verb ("Genera") with a precise resource ("ficha sociojurídica de ingreso") and scopes it to legal-aid clinics across family, civil, and labor matters. It is clearly distinguishable in subject matter from sibling clinica_* tools, but it does not explicitly contrast itself with alternatives like clinica_auditar_borrador or clinica_lenguaje_claro.

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 explicit when-to-use, when-not-to-use, or alternative-tool guidance. The domain (free legal-assistance clinics, family/civil/labor) is implied but never states the conditions or prerequisites under which an agent should invoke this rather than the other clinica tools.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the desired tone and audience (claro, accesible, empático), which is genuinely useful context, but says nothing about output length, format, or fidelity limits of the translation.

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 well-formed sentence with the purpose and audience front-loaded and no filler. It is efficient, though the extreme brevity leaves no room for the operational detail the tool arguably needs.

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-parameter, fully-documented tool with no output schema, the description covers what the tool does and for whom. It omits expected output characteristics (length, structure, fidelity to the original), which an agent would want when translating legal text.

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 100%, so both parameters are already documented. The description's mention of CAJ users loosely aligns with the destinatario default of usuario_caj but adds no format or constraint details beyond the schema, so baseline 3 applies.

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 (Traduce) and resource (resolución judicial chilena densa) plus the target audience (usuarios de CAJ), so an agent can tell it apart from analysis tools like pjud_analizar_sentencia or vigilante_analizar_resolucion. It does not explicitly name which sibling it replaces, keeping it at 4 rather than 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?

The description implies the scenario (rewriting dense judicial text for CAJ users) but never states when to use this versus pjud_interpretar_proveido, pjud_analizar_sentencia, or clinica_auditar_borrador. No exclusions or prerequisites are given, so usage is only inferable.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the purpose statement — no indication of coverage period, result format, or result volume for an open-world registry lookup.

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 compact sentence with no filler, front-loading the verb and resource. It is appropriately sized, though it conveys only the minimum.

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 read-only search, the description is minimally adequate, but with no output schema it could say a bit more about what the registry covers or what results look like. Nothing critical is missing, but the definition is thin given the breadth of sibling search tools.

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 100% for the single 'query' parameter, and its schema description already explains it accepts an entity name, infraction, or resolution number. The description adds nothing beyond the schema, so the baseline 3 applies.

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 clear verb ('Busca') and a specific resource ('registro oficial de Resoluciones Sancionatorias y procedimientos de sanción aplicados por la CMF'). However, it does not distinguish itself from related sanction-search siblings such as sma_search_sancionatorios or cgr_search_auditorias, so an agent must infer the CMF-specific scope from the name 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?

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. With many sibling search tools (sma, cgr, tdlc, sii), the absence of routing guidance is a noticeable gap.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — no note on corpus scope, coverage, freshness, result limits, or what a match returns.

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?

One efficient sentence with no waste, front-loading the action and the resource scope. It is appropriately short, though it is short because it omits guidance rather than because it is dense.

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 read-only search with annotations covering safety and a fully documented schema, this is minimally adequate. It could still note result format or the corpus boundary (NCG vs circulares) that an agent would need to route correctly among the many sibling search tools.

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?

Single parameter with 100% schema coverage; the schema documents that 'query' accepts a term or NCG number with examples. The description adds nothing about the parameter, so the baseline 3 applies.

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 clear verb (Busca) plus specific resources: Normas de Carácter General (NCG) and circulares, scoped to the CMF. This implicitly distinguishes it from cmf_buscar_sanciones, but never names that sibling or any other alternative 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?

The description only says what the tool searches; it offers no when-to-use, when-not-to-use, or alternative-tool guidance despite a large sibling set (cmf_buscar_sanciones, bcn_get_ley, vigilante_radar_normativo). Usage must be inferred entirely from the resource name.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds data-scope context ('active' plants and energy projects in the SEA), but no auth, rate-limit, or response-shape details.

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 sentence with the verb and resource front-loaded and no filler. It is appropriately sized for a simple lookup tool.

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 read-only registry query with one optional parameter and no output schema, the description supplies enough scope to call it correctly. It does not mention the optional region filter, but the schema covers that; return-format details are unnecessary without an output schema.

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 100% for the single optional 'region' parameter, so the schema already documents it. The description does not add any parameter semantics beyond what the schema provides, which is the expected baseline.

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 ('Consulta') and resource (registry of active generating plants and energy projects in the CNE's SEA). It is clear what the tool retrieves, but it does not explicitly distinguish itself from any sibling tool.

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 when-to-use guidance, alternatives, or conditions are provided. The description only states what the tool consults, so an agent gets no help deciding when to select it over other search/consult tools.

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?

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write-but-safe profile is already covered. The description adds real context — output formats, A4 layout, TOC bookmarks for OJV, editable Word delivery — but the internal contradiction ('compila... a PDF' vs 'se entregan en Word, no en PDF') leaves the actual deliverable ambiguous.

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?

Essentially one long sentence with a nested parenthetical, and the trailing 'se entregan en Word, no en PDF' clause introduces confusion rather than clarity. It is not bloated, but the structure is not front-loaded cleanly.

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 six-parameter document generator with no output schema, the description does explain the primary outputs, but omits selection context against siblings, error/overwrite behavior, and how the optional paths (main_pdf_path, mobile_preview_path) relate to the main deliverable.

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 100%, so every parameter (title, annexes, main_pdf_path, mobile_preview_path, etc.) is already documented in the schema. The description adds no per-parameter syntax or format detail, so the baseline of 3 applies.

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 (compila) and resource (escrito judicial/denuncia) plus concrete outputs (A4 PDF with divider covers and TOC bookmarks, editable Word). An agent can grasp the intent, but the description never differentiates this from siblings like generar_documento or export_brief_ojv, and the closing clause muddies what is actually produced.

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 when-to-use guidance, no prerequisites, and no mention of the adjacent document-generation siblings (generar_documento, export_brief_ojv, critique_documento). The agent is left to infer the use case 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?

Annotations already declare read-only, non-destructive, open-world behavior. The description adds valuable context beyond them: the tool returns literal source text with ready-to-paste citation brackets and works from gathered sources rather than memory. It does not cover latency or result limits, but the safety profile is already handled by annotations.

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-loads the mandatory-first-step instruction, then explains the output and finally the environmental exception. Every sentence carries useful information and the structure mirrors the agent's decision flow.

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?

Although no output schema exists, the description explains what is returned: sources with literal text and citation brackets. It also handles the main routing complexity by specifying the environmental alternative, which is the most important sibling distinction here.

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 100%, so both parameters are fully documented in the input schema. The description does not add syntax or meaning beyond 'consulta' and 'max_fuentes', so the baseline of 3 is appropriate.

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 mandatory action: consult the Hugging Face dataset, canonical doctrine, graph, and detected Chilean norms, then return sources with literal text and citation brackets. It also names the environmental sibling module explicitly, so an agent can distinguish it from alternatives.

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 explicit when-to-use guidance: it is the mandatory first step for every legal query and should be used before answering even when the answer seems known. It also gives a clear alternative for environmental matters, routing to `ambiental_consulta_maestra`.

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?

Annotations declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and the description is consistent with a read-only audit. It adds the substantive verification criteria (which articles/faculties are checked), which is genuine context beyond annotations, but says nothing about what the audit returns or how failures are surfaced. No output schema exists to cover that gap.

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 dense sentence with the action front-loaded and the legal criteria following immediately. Every clause carries substantive meaning; no filler or repetition.

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 an audit tool with no output schema, the description should signal the shape of the result (e.g., pass/fail, defect list). It fully specifies what is checked but not what comes back, leaving an agent guessing about the return value.

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?

Only one parameter with 100% schema description coverage; the schema already explains it is the otrosí de patrocinio y poder or escritura pública de mandato. The description adds no format or size guidance for the input text, so the baseline 3 applies.

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 (audita formalmente) and resource (texto de mandato judicial y patrocinio), then pins down the exact legal scope: facultades ordinarias Art. 7 inc. 1 and extraordinarias expresas Art. 7 inc. 2 CPC. This is unmistakably distinct from the search/retrieval siblings, which dominate the sibling list.

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?

The verification scope implies the use case (checking a mandate's sufficiency before relying on it), but there is no explicit when-to-use statement, no prerequisites, and no alternatives named. An agent can infer usage from the purpose but gets no routing guidance.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the audit dimensions and that it runs on the product's critique engine, but says nothing about latency, output format, or cost of the optional provider call.

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 dense sentence that front-loads the core purpose and then lists scope; nothing is wasted. The parenthetical dimension list is informative rather than filler.

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 read-only analysis tool with full schema coverage and annotations, the definition is mostly sufficient, but with no output schema it does not hint at what the audit returns (report, score, findings), which an agent would benefit from knowing.

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 100%, so both 'texto' and 'provider' are already documented in the schema. The description adds no extra syntax or format detail for either parameter, so the baseline 3 applies.

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+resource ('Auditoría forense de un borrador judicial') and even enumerates the five audit dimensions, so the agent knows exactly what the tool produces. However, it does not differentiate itself from the very similar sibling 'clinica_auditar_borrador', leaving ambiguity about which audit tool to pick.

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/when-not guidance and no mention of the closest alternative, 'clinica_auditar_borrador'. The phrase 'con el motor de crítica del producto' implies a specific engine but gives no condition that tells the agent when this tool is the right choice.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the return shape (definition, requirements, procedural operation, BCN concordances, governing rulings) - important since no output schema exists. It does not mention auth needs or limits, so not a 5.

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 dense sentence that is front-loaded with the verb and resource before enumerating content. Every listed item (vía procesal, tribunal, legitimación, carga probatoria, etc.) earns its place, though the run-on form is heavier than necessary.

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 no output schema, the description carries the burden of describing returns and does so thoroughly via the content enumeration; safety is covered by annotations and parameters by the schema. Complete enough for correct invocation, though the absence of any usage/alternative guidance leaves a small 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 100% with only 2 params, so the schema already documents 'nombre' (exact or approximate name, with examples) and optional 'area'. The description adds nothing about parameters, so the baseline 3 applies.

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 ('Recupera') and a precise resource ('ficha dogmática y forense completa sobre una institución jurídica específica'), then enumerates the exact content returned, so the agent knows this is a deep single-institution lookup rather than a search. It never explicitly names the sibling it competes with (doctrina_search, graphify_explicar_institucion), so it stops 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?

There is no explicit when-to-use or when-not-to-use statement and no alternative is named. The enumerated content strongly implies the scenario (need a full dogmatic/forensic profile of one institution), so usage is inferable but not stated.

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?

Annotations only declare it is a non-destructive, non-open-world mutation. The description adds meaningful side-effect disclosure beyond that: it writes a Markdown file and automatically updates legal_knowledge_graph.json and the FTS5 index. It still omits overwrite/re-ingestion behavior and auth requirements, but adds real context over the annotations.

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 opening with the core verb 'Convierte'. It is dense but every clause earns its place by naming inputs, output format, and the two downstream artifacts updated; the nested parentheticals make it slightly heavy.

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 mutation tool with no output schema, the description covers inputs, the produced artifact, and the automatic graph/index updates, and every parameter is schema-documented. It leaves some gaps (return value, behavior on re-ingestion), but is largely sufficient for correct invocation.

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 100%, so all seven parameters are already documented in the schema, establishing a baseline of 3. The description repeats the supported file types but adds no format or syntactic detail beyond what the schema provides for file_path, area, obra, tratadista, target_path, or actualizar_grafo.

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 precise verb and resource: it converts documents (PDF, DOCX, TXT, MD) or raw text into canonical Markdown and updates the Knowledge Graph and SQLite FTS5 index. This is a distinct ingestion/conversion role that no sibling tool (all searches, lists, or graph readers) performs, so the agent can place it unambiguously.

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?

The purpose implies when to use it (ingesting a source document into the doctrine corpus), but the description never states when-not to use it, prerequisites, or how it relates to alternatives like doctrina_search or grafo_ver_corpus. Usage is only inferable from the stated effect.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds that results include authors and statistics, but says nothing about result volume, pagination, or ordering for a tool that returns the entire corpus.

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 led by the verb, with no filler or redundant restatement of the tool name. It is dense with clauses but every clause (sources, authors, statistics) carries 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?

With no parameters, no output schema, and annotations covering the safety profile, the description does enough by naming the covered corpus and the shape of the return (obras, autores, estadísticas). Missing only practical detail about result size or pagination.

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?

The tool takes zero parameters, so there is no parameter meaning to convey and the baseline of 4 applies. Nothing in the description conflicts with the empty 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 (tratados y manuales dogmáticos de doctrina chilena) with scope (indexados en la base de datos de Open Legal Chile). It is clear what the tool returns, but it does not differentiate itself from the sibling doctrina_search, which an agent must infer from the 'todos' phrasing.

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 explicit when-to-use guidance is given and no alternatives are named. The word 'todos' only implicitly suggests this is a full-enumeration tool as opposed to doctrina_search, but the agent is left to infer that contrast on its own.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds useful context about the retrieval mechanism (FTS5 semantic relevance with BM25 ranking), but says nothing about result format, ranking caveats, or pagination behavior, so it adds only moderate value.

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 beginning with the verb, with no wasted preamble. The lengthy author enumeration is informative but is the only element that stretches the length.

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?

Given 4 parameters (1 required), full schema coverage, no output schema and explicit annotations, the description covers what the tool searches but omits guidance on how to combine the optional filters or what to expect from the ranked results. It is adequate but leaves real gaps.

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 100% – area, autor, limit and query are all documented in the schema with examples. The description's mention of semantic relevance adds marginal color to the query parameter but does not extend meaning beyond what the schema already provides, so the baseline 3 applies.

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 precise resource (the dogmatic canon of the most-cited Chilean legal treatises), and even enumerates the authors covered, so an agent can tell exactly what corpus is queried. It does not explicitly contrast itself with siblings like doctrina_list_obras or doctrina_get_institucion, but the scope 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?

There is no when-to-use or when-not guidance, nor any mention of alternatives (e.g. pjud_search_jurisprudencia for case law, doctrina_list_obras for browsing works). Usage is only implied by the corpus it names.

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?

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is covered. The description adds useful domain context by specifying that the doctrine is 'vinculante' and comes from the DT, but it does not disclose return behavior, coverage limits, or authentication requirements beyond that.

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 well-formed sentence that front-loads the main action and scope. There is no redundant or filler text.

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 one-parameter search tool with full schema coverage and an output schema absent, the description sufficiently communicates the data source and legal domain. It could be improved by clarifying how it differs from sibling doctrine or jurisprudence search tools, but it 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 description coverage is 100%, and the schema itself explains that the single 'query' parameter accepts a subject or dictamen number with examples. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 names a specific verb ('Busca'), specific resources ('dictámenes, pronunciamientos y doctrina laboral vinculante'), and the issuing body ('Dirección del Trabajo'). This is clear enough to distinguish it from generic search tools, but it does not explicitly differentiate itself from close siblings such as doctrina_search or cgr_search_jurisprudencia.

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?

The description states what the tool does but gives no guidance on when to use it versus alternatives like doctrina_search or other jurisprudential search tools. There are no stated prerequisites, exclusions, or recommended contexts.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds content scope (what categories of information are returned), but says nothing about return format, coverage limits, or freshness of the legal data.

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 parenthetical list of organs earns its place by clarifying scope. Slightly dense but appropriately sized for a one-parameter lookup tool.

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 read-only, single-parameter consultation tool with no output schema, the description covers what domain is queried but not what an agent receives back (full statutory text, structured summary, links) or whether coverage is exhaustive across the listed organs. Adequate but with a clear 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 coverage is 100% and the schema itself explains the single 'organo' parameter, so the baseline would be 3. The description goes further by enumerating the valid organ siglas (SII, CMF, CGR, DT, SERNAC, FNE, SMA, CPLT) in context, effectively documenting accepted values even though no enum exists.

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 (Consulta) and a concrete resource: ley orgánica, facultades fiscalizadoras y vías de reclamo of public organs, with named examples (SII, CMF, CGR...). This clearly separates it from sibling tools that search a single agency's normativa or jurisprudencia, though it does not explicitly name those alternatives.

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 condition selecting it over cmf_search_normativa, sii_search_circulares, or cgr_search_jurisprudencia, and no stated prerequisites. Usage is only inferable from the topic itself.

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?

The description explicitly states the tool 'guarda cada clave del perfil de práctica' (saves/writes profile keys), a mutating operation, while the annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction between described behavior and the safety annotations.

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 names the tool's purpose first, then lays out the two argument-driven modes in order. No clause is redundant given the dual-mode behavior being described.

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 3-parameter, no-output-schema tool, the description covers both modes and the parameter interaction adequately, and it names what the no-arg call returns (cuestionario + perfil actual). The main gap is that the write path's effect on the profile is asserted but never reconciled with the readOnly annotation.

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 100% (baseline 3), and the description adds value beyond the schema by explaining that 'pregunta' and 'respuesta' work together to persist each profile key, clarifying the read-vs-write semantics that the individual parameter descriptions do not convey on their own.

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 verb+resource ('Entrevista de arranque del estudio' that reads or writes the 'perfil de práctica') and clearly splits the two operating modes (no args → returns questionnaire; with pregunta/respuesta → saves a profile key). It does not, however, distinguish itself from any sibling tool, since no sibling appears to overlap.

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 describes both invocation contexts: without arguments it returns the questionnaire and current profile, and with 'pregunta'+'respuesta' it saves each practice-profile key. This tells the agent which mode to trigger, though it offers no when-not-to-use guidance or named alternatives.

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?

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description does not need to restate that it is a non-destructive write. It adds that output is produced in four concrete formats (.html, .md, .txt, .json), which is genuine behavioral value, but says nothing about where files land, whether existing files are overwritten, or required auth.

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 sentence with no filler, front-loading the action and resource and ending with the output formats. Every clause earns its place.

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 seven parameters, five required, no output schema and no nested objects, the definition covers the essentials: what it produces, the legal context, and the export formats. It is slightly thin on the export mechanics (destination, overwrite behavior) but complete enough for an agent to invoke it 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 description coverage is 100% and all seven parameters (titulo, tribunal, hechos, derecho, peticiones, comparecencia, otrosies) are documented in the schema itself. The description adds no per-parameter meaning beyond the output-format list, so the baseline 3 is appropriate.

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 concrete verb pair (genera y exporta) and a specific resource (escrito judicial estructurado formalmente) scoped to a named legal regime (OJV, Ley N° 20.886). An agent can tell this is a document-generation/export tool. It does not, however, differentiate itself from close siblings like generar_documento or recurso_proteccion_generar, so it stops 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 only implied through the OJV/Ley 20.886 framing — an agent can infer this is for filing-oriented judicial briefs — but there is no explicit when-to-use statement, no exclusions, and no routing to alternatives such as generar_documento or compile_legal_dossier. Minimum viable guidance.

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?

Annotations only declare it is a non-read-only, closed-world, non-destructive write. The description adds real behavioral context beyond that: multi-format delivery, automatic retrieval of doctrine/jurisprudence from the local corpus when not supplied, full-text transcription of each cited norm, and the product rule «no se cita sin texto». It stops short of stating whether existing files are overwritten or where output lands.

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 dense paragraph, front-loaded with what it produces and in which formats before moving to the «informe» special case and the citation rule. Every sentence carries information, though the run-on «informe» clause is heavy.

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 an 18-parameter generator with no output schema, the description covers the output formats and the informe pipeline well, but leaves the civil/laboral/protección/PPA modes' expected inputs and the handling of optional fields unaddressed. Adequate for the flagship mode, incomplete for the rest.

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 50% across 18 parameters. The description meaningfully explains the informe-mode inputs (hechos, análisis, normas, doctrina, jurisprudencia auto-search), which compensates for several undocumented fields, but many parameters (rut, tribunal, demandante, demandado, peticiones, comparecencia, otrosies) and the non-informe modes get no semantic help in the description.

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 (generar) and resource (documento de trabajo) and enumerates the five concrete document types plus the output formats (Word .docx, HTML/MD/TXT/JSON). It also carves out the «informe» mode's distinct behavior, so an agent can tell it apart from the sibling recurso_proteccion_generar and export_brief_ojv.

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?

The type enum and the special «informe» branch imply when each mode applies, but there is no explicit when-to-use/when-not guidance and no mention of the overlapping siblings (recurso_proteccion_generar, compile_legal_dossier, export_brief_ojv). Usage must be inferred from the type list.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that the tool returns Mermaid code plus JSON, which is useful since no output schema exists, but it says nothing about validations, failure modes, or how nodes/edges are normalized.

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, dense sentence that front-loads the action, the resource, the entity types and the return formats with no filler. Nothing here 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?

With only three well-documented params and no output schema, the description covers what is needed by naming the two output artifacts (Mermaid + JSON). It is slightly incomplete in not hinting at input expectations or any constraints on node/edge validity.

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 100%, with nodes, edges and title each documented including example shapes, so the schema carries parameter meaning. The description adds no further syntax or format guidance, making the baseline 3 appropriate.

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 verb (construye) and resource (red de vínculos societarios, políticos y judiciales entre personas, empresas y organismos) and even discloses the output format (Mermaid and JSON). It is clearly a graph-building tool distinct from read/view siblings like grafo_ver_caso or graphify_trazar_camino, though it never names those alternatives to sharpen the contrast.

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 explicit when-to-use guidance, no prerequisites, and no routing to alternatives among the many graph-related siblings (grafo_ver_caso, graphify_*, graphify_god_nodes). Usage must be inferred entirely from the one-line purpose statement.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety and world-access are covered externally. The description adds the useful behavioral fact that the output is a composite artifact (questions + linked norms + doctrine + grading rubric), but says nothing about format, length, persistence, or whether the result is saved anywhere. There is mild tension between 'Genera' and readOnlyHint=true, though content generation returned to the caller is plausibly non-mutating, so this is not a hard contradiction.

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 sentence that front-loads the verb and resource and then lists the output components without filler. Nothing is redundant and nothing is missing from the sentence's scope.

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 tool with no output schema, the enumeration of what the cédula contains effectively substitutes for a return-value description. Gaps remain around format, size, and language, but the core of what an agent needs to call this correctly is present.

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?

There is a single parameter ('tema') and schema description coverage is 100%, with the schema itself providing examples ('Obligaciones', 'Responsabilidad'). The description adds no meaning about the parameter beyond what the schema already supplies, so the baseline 3 for fully documented parameters applies.

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 pairs a specific verb ('Genera') with a specific resource ('cédula completa de examen de grado') and even enumerates the deliverable's components (preguntas, normas vinculadas, doctrina canónica, pauta de evaluación). An agent immediately understands what it produces. However, it does not distinguish this tool from close siblings like grado_interrogar, grado_obtener_flashcards, or generar_documento, so it stops just short of the top band.

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 prerequisites, and no named alternative. With several grado_* and generation siblings in the toolset, an agent gets no help deciding when a full 'cédula' is the right artifact versus grado_interrogar or grado_obtener_flashcards. The single-purpose framing implies usage but never states it.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral note that it evaluates answers against canonical doctrine and codes, but it says nothing about the interaction mechanics or what a response contains, leaving a real gap for an interactive tool.

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 that names the verb, audience, and domain with no wasted words. It is efficient, though it stops short of conveying the extra structural details an interactive tool would benefit from.

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?

There is no output schema, so the description should explain what the tool returns and how the interrogation proceeds, but it does not. Combined with the absence of usage guidance, an agent has insufficient information to invoke this correctly beyond guessing at the defaults.

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 100%, so both parameters (materia, dificultad) are already documented with their allowed values in the schema. The description adds no syntax, defaults, or constraint detail beyond what the schema provides, making the baseline 3 correct.

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 (interroga socráticamente) and resource (egresado de derecho) with a clear domain (preguntas de examen de grado en Chile), so the agent can tell this is an interactive quizzing tool. It does not explicitly differentiate itself from siblings like grado_generar_cedula or grado_obtener_flashcards, but the verb-plus-resource pairing is clear enough to distinguish it.

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?

The description offers no when-to-use guidance, no prerequisites, and no named alternatives. An agent must infer on its own whether this is for practice, assessment, or exam simulation, and nothing routes it away from grado_obtener_flashcards.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the lower bar applies. The description adds that the payload is flashcards on definitions and deadlines, but says nothing about filter behavior when area/tipo are omitted (both are optional) or about the open-world fetch implied by openWorldHint.

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 or redundancy. The domain jargon makes it dense, but every word carries meaning and 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 simple, two-optional-parameter read tool with full schema coverage and annotations carrying the safety profile, the description is adequate. It nonetheless omits two things an agent needs: what happens when both filters are omitted, and how this differs from the sibling grado_ tools.

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 100%: both parameters carry descriptions and example values, so the schema does the heavy lifting and a 3 baseline applies. The description's mention of 'definiciones' and 'plazos' loosely echoes the tipo values but adds no format, syntax, or default behavior beyond 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 (Obtiene) and resource (fichas mnemotécnicas) with a qualifying scope ('definiciones sacramentales y plazos fatales procesales para el examen de grado'). It is clear what the tool returns, but it never distinguishes itself from siblings grado_interrogar or grado_generar_cedula, which live in the same exam-prep family.

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?

The description only implies usage through the phrase 'para el examen de grado'; there is no statement of when to pick this over grado_interrogar or grado_generar_cedula, and no prerequisites or exclusions are given. An agent must guess at the routing.

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?

The description explicitly states that the tool writes a file ('escribe un HTML que se abre en el navegador'), which modifies the environment, while the annotations declare readOnlyHint=true. These two statements cannot both be true, so this is an annotation contradiction. The otherwise useful behavioral detail (which documents were read/skipped and why) does not repair the conflict.

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?

Three sentences: triggers, mechanics, and reporting behavior. It is front-loaded with usage rather than purpose, and the three quoted trigger phrases largely restate one another, but the whole thing is short and every sentence contributes.

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 no output schema, the description usefully explains the workflow and what the report contains (documents read and skipped, with reasons). It omits where the HTML is written and whether it opens automatically, minor gaps for a one-parameter visualization 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?

There is a single parameter with 100% schema description coverage ('Carpeta del caso (con sus documentos)'), so the schema already carries the semantics. The description adds only the redundant observation that it reads the folder; baseline 3 applies when the schema does the heavy lifting.

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 concrete verb chain and resource: it reads a case folder, builds a graph (document = node, sections hanging off it) and writes an HTML. The 'caso' scoping implicitly separates it from the sibling grafo_ver_corpus, but no sibling is named explicitly, so it stops 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?

It gives explicit trigger phrases ('graficá este caso', 'mostrame el expediente como grafo', 'cómo se ve esta carpeta') plus the general condition 'quieran ver las relaciones entre los documentos de un caso'. There is no when-not guidance and no alternative tool is named, so it is clear context without 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?

Annotations already cover the safety profile (readOnly, openWorld, non-destructive). The description adds real value beyond them: the output is a written HTML file that opens in a browser, hover interactivity, and the returned file path. Minor tension with readOnlyHint since it writes a file, but that is an output artifact rather than a state mutation, so it is not a true contradiction.

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-loads the trigger phrases before the mechanics, and the second sentence efficiently covers the artifact, its behavior, and the return value. Slightly dense but no wasted filler.

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 no output schema, the description correctly carries the return-value burden ('Devuelve la ruta del archivo') and explains the artifact's form. Only minor details (absolute vs relative path, whether it auto-opens) are left unstated.