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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose return format, result limits, pagination, or whether results are ranked, and adding a parenthetical list of covered subject areas is scope rather than behavior. For a search tool with no structured hints at all, this leaves real gaps.

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 the resource, with the covered domains in a trailing parenthetical. Nothing is wasted, though it is thin rather than tightly engineered.

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 could usefully explain what a search returns, but does not. The scope of the guide collection is covered, which makes it minimally viable for a simple two-parameter search tool, but return behavior 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 both parameters (query, materia) are already documented in the schema, establishing the baseline of 3. The description's subject list loosely echoes the materia parameter but adds no format, matching, or validation detail beyond it.

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 (Guías Oficiales de Buenas Prácticas Judiciales de la Academia Judicial de Chile). The domain is distinctive enough to separate it from the many generic search siblings, but it never names an alternative tool, so differentiation is implicit at best.

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 the dozens of sibling search tools (pjud_search_jurisprudencia, doctrina_search, cgr_search_jurisprudencia, etc.). Usage can only be inferred from the subject matter; no exclusions or prerequisites are 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?

No annotations are provided, so the description carries the full disclosure burden. It does not mention that this tool writes files to disk, whether it overwrites existing files, whether it creates the target directory automatically, or any side effects. For a file-generating/exporting tool, this is a notable gap in behavioral disclosure.

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 that front-loads the verb and purpose, then specifies the output formats with concrete paths. Zero waste and 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 a tool with one optional parameter and no output schema, the description covers the core purpose and output formats adequately. The main missing context is behavioral (overwrite behavior, directory creation), but given the tool's simplicity, the description is reasonably 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% and the single optional parameter (target_dir) is already described as the destination directory for configuration files. The description adds value by specifying the default target structure (.claude/agents/*.md and .cursor/rules/*.mdc), which complements the parameter meaning, but it does not add syntax or behavior details beyond that. 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 clear verb (genera y exporta) plus a specific resource (plantillas y perfiles de subagentes jurídicos) and the target platforms with concrete file paths (.claude/agents/*.md and .cursor/rules/*.mdc). No sibling tool performs a similar export function, so the purpose is unambiguous and self-distinguishing.

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 clearly states what the tool does but gives no guidance on when to use it versus alternatives, and no exclusion criteria. Since none of the 80+ siblings perform a similar export role, alternatives are not immediately relevant, but the description still lacks any contextual hint about the intended scenario (e.g., setting up a legal agent workspace). Usage is implied rather than 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?

With no annotations provided, the description carries the full burden, and 'Lista' implies a read-only operation without stating it explicitly. The description does disclose the output content (descriptions, forensic competencies, assigned tools), which is useful, but it adds nothing about behavior beyond the obvious semantics of a listing operation.

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 Spanish sentence that front-loads the verb and resource, then packs in the content details with no filler. Every clause earns its place, and the Spanish language matches the sibling tool set.

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 catalog listing with no output schema, the description sufficiently tells an agent what it will get (the 17 agents with descriptions, competencies, and tools) and why it would call this tool. Minor omissions like output language or whether the catalog is static are not material for a tool of this simplicity.

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 has zero parameters, so the baseline is 4 and the schema imposes no burden. The description adds value by indicating what the returned catalog entries contain (descriptions, competencies, tools), which compensates for the absence of an output 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?

The description names a specific verb ('Lista') and resource ('el catálogo de los 17 agentes jurídicos especializados de Open Legal Chile') and spells out the content scope (descripciones, competencias forenses, herramientas asignadas). It is clear and specific, though it does not explicitly distinguish itself from related siblings like agent_export_subagents or agent_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. There is no mention of when-not-to-use, no prerequisites, and no reference to related agent tools such as agent_run or agent_export_subagents. For a simple catalog tool the use case is fairly obvious, but the description itself provides zero 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?

With no annotations, the description carries the burden of behavioral disclosure. It states that the agent coordinates tools autonomously and mentions execution modes ('determinista soberano o LLM'), which adds useful context. However, it does not disclose potential side effects, execution duration, failure behavior, or any authorization requirements.

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, information-dense sentence that front-loads the core action and resource. The list of agent examples is somewhat long but directly useful. It is concise without being vague.

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 that this is a complex meta-orchestration tool with no output schema and no annotations, the description is incomplete. It does not explain what the agent returns, how 'auto', 'deterministic', and 'llm' modes differ behaviorally, or how to discover available agents (e.g., via agent_list). An agent calling this tool would lack important operational context.

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 fully documents all four parameters. The description adds little beyond repeating the agent_name examples already present in the schema, which is acceptable but not additive.

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 clearly identifies the verb ('Ejecuta'), the resource ('un agente jurídico especializado'), and the goal ('resolver un objetivo legal complejo'). It also differentiates this tool from the sibling tools by framing it as an autonomous orchestrator of the suite, with a concrete list of agent aliases.

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 for complex legal objectives that require autonomous coordination of multiple suite tools, but it does not explicitly state when to prefer this tool over direct sibling tools or provide exclusions. There is no mention of simpler cases where a single specialized tool should be used instead.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that two source sets are searched (tribunals and annual compendia) but says nothing about result ranking, pagination, result limits, or that this is a read-only operation, leaving meaningful gaps for a search 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 and the exact sources with zero filler. 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?

For a two-parameter read-only search with no output schema and no annotations, the description covers what is searched but omits expected output shape or result behavior. Adequate but with clear 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%, with both 'query' and 'tribunal' fully documented including examples and that 'tribunal' is optional. The description adds no parameter-level detail 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 resource (jurisprudencia de los Tribunales Ambientales 1TA/2TA/3TA plus Compendios Anuales), which cleanly separates it from the many sibling '*_search_jurisprudencia' tools (tdlc, pjud, cgr) by domain. It does not explicitly name those siblings, but the environmental 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?

The description implies usage (search environmental case law) but offers no explicit when-to-use, when-not-to-use, or alternative routing against the other jurisprudencia search tools. An agent can infer the right context, but nothing is 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?

Sin anotaciones, la descripción asume la carga de transparencia y detalla las fuentes consultadas, que la búsqueda es en un solo paso, el tipo de retorno (plan, resultados con texto literal y citas) y el efecto de incluir_subgrafo=true con su ahorro de tokens. No declara explícitamente que sea de solo lectura ni sus límites, pero el verbo 'Busca' y el detalle funcional cubren gran parte del comportamiento esperado.

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?

El texto está front-loaded con la condición de uso principal ('PRIMERA consulta cuando...') y luego detalla fuentes y salida. Es relativamente extenso por la enumeración de fuentes, pero esa enumeración justifica el alcance de la herramienta y no resulta gratuita.

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?

Para una herramienta de búsqueda compleja sin esquema de salida y sin anotaciones, la descripción cubre bien el propósito, las fuentes, el contenido del retorno y el comportamiento del parámetro opcional de subgrafo. Faltan solo detalles menores sobre límites, errores o paginación, que no son críticos para invocarla correctamente.

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?

La cobertura de descripciones del esquema es del 100%, por lo que los tres parámetros ya están documentados en el propio esquema. La descripción añade algo de contexto sobre incluir_subgrafo, pero no aporta semántica adicional relevante para limite o consulta más allá de lo que ya indican sus descripciones.

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?

La descripción indica un verbo y recurso concretos: módulo especial de derecho ambiental que realiza la PRIMERA consulta en materia ambiental, con una lista de materias activadoras (SMA, SEIA/RCA, daño ambiental, etc.). Además, diferencia implícitamente esta herramienta maestra de otras búsquedas ambientales al señalar que es la primera consulta y que abarca múltiples fuentes en un solo paso.

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?

Establece claramente cuándo usarla: cuando la consulta o el caso sea de materia ambiental, enumerando los supuestos típicos. No menciona alternativas ni casos de no uso, pero el contexto de activación es suficientemente explícito.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the closed scope of covered sources (a real boundary), but says nothing about read-only nature, permissions, rate limits, or whether it returns full text versus metadata.

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 code enumeration is dense but earns its place by defining scope. Slightly long due to the list, but well structured.

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 lookup tool with no output schema and no annotations, the description covers what sources exist but leaves return format, mode behavior (article vs structure), and error handling to inference. Adequate but with clear 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 only two parameters, so the schema already documents 'codigo' (with examples) and 'articulo'. The description's phrase 'artículos o estructura' loosely maps to the optional 'articulo' parameter (omit it to get structure), adding minor meaning but no syntax or format detail.

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?

Clear verb ('Consulta') plus the precise resource ('artículos o estructura de los 9 Códigos... la Constitución Política y el Código Sanitario'), and it enumerates the covered codes so an agent knows the data domain. It does not, however, differentiate itself from close siblings like bcn_get_codigo_historico or bcn_get_ley.

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 enumeration of exactly which codes and documents are covered implicitly signals when to use this tool (these sources) and when to look elsewhere, but there is no explicit 'use X instead' routing to bcn_get_ley or bcn_get_codigo_historico, nor any stated prerequisites.

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?

With no annotations provided, the description carries the burden of disclosing behavior. It states that the tool consults, returns the effective version, provides an official link, and optionally returns article text. This is transparent enough for a read-only historical lookup, though it does not detail error handling or access requirements.

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 two sentences, front-loads the core purpose, and includes a concrete example without fluff. Every sentence adds necessary context.

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?

Despite having no output schema or annotations, the description explains what the tool returns (effective version, official link, optional article text) and gives a realistic use case. It does not describe failure modes or edge cases, so it is not fully complete, but it is sufficient for basic 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 coverage is 100%, so the baseline is 3. The description adds a little semantic value by indicating that 'articulo' is optional and providing examples of valid 'codigo' values, but these largely mirror the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Consulta'), a specific resource ('un Código de la República'), and a distinguishing scope ('versión vigente a una fecha histórica'). It also clarifies what it returns, which differentiates it from sibling tools like bcn_get_codigo or bcn_get_ley.

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 a clear use case ('Ideal para ver cómo cambió una norma') and an example, so an agent can infer when it is appropriate. However, it does not explicitly name alternative tools or state when not to use this one, 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?

No annotations are provided, so the description carries the full behavioral burden. It conveys that this is a read-only consultation of official, current text, but it does not mention permissions, error behavior, rate limits, or return format, leaving meaningful gaps.

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. The examples are useful and do not bloat the definition.

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 the low complexity, complete schema descriptions, and no output schema, the description is nearly complete for correct invocation. It omits the optional article parameter and any return-format detail, but those are either covered by the schema or inferable from 'Consulta el texto'.

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 both parameters. The description reinforces that lookup is by law number, but adds no syntax or meaning beyond the schema, and it does not mention the optional articulo 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?

The description states a specific verb (Consulta), resource (texto oficial y vigente de una ley chilena), and lookup key (por su número). The word 'vigente' distinguishes it from the sibling bcn_get_ley_historica, and the examples make the scope concrete for an agent.

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 clear context: use this tool when you need the official and current text of a Chilean law identified by number. It does not explicitly name alternatives or exclusions, but 'vigente' implies the historical-version sibling is a different use case.

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

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

No annotations are provided, so the description bears full burden. It doesn't state whether the response includes version history, footnotes, effective date transitions, or whether the lookup requires the law to have actually been in force at that date. For a temporal-query tool, this is a significant 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?

Single sentence, front-loaded with the action and scope, no wasted words. It is dense but appropriately sized for the tool's complexity.

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?

No output schema, no annotations, and only one sentence. For a temporal legal retrieval tool, the description should explain what a 'historical' query returns (current version? historical version? annotations?) and any prerequisites. It's minimally adequate but leaves key behavioral questions unanswered.

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%, so the schema already documents all three parameters including the YYYY-MM-DD format and purpose of 'articulo'. The description reinforces the date concept ('fecha histórica específica (YYYY-MM-DD)') but adds little beyond the schema; baseline would be 3 with high coverage, but the description's date-format hint is slightly additive.

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 specific verb+resource+scope: retrieves the text of a Chilean law as in force at a specific historical date, for intertemporal law control. This clearly distinguishes it from historical code lookups (bcn_get_codigo_historico) by specifying 'ley' vs 'código', though the wording is dense.

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 statement implies usage (intertemporal control) but offers no explicit when-to-use vs alternatives like bcn_get_ley (current law) or bcn_get_codigo_historico. An agent must infer the choice from 'vigente en una fecha histórica específica'.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It says the tool generates packages, but does not clarify whether it uploads to Hugging Face, GitHub, or Google Drive, whether it overwrites existing artifacts, what permissions or authentication are required, or what side effects occur.

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 front-loaded sentence with no filler. Every clause contributes to identifying the resource and the generated outputs.

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 that there are no annotations and no output schema, the one-sentence description is too thin for a tool that compiles content and generates packages for external platforms. It omits prerequisites, side effects, authentication needs, and whether packages are uploaded or only prepared locally.

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 single parameter and its conditional behavior are already documented in the schema. The description adds context about output targets but does not explain the generar_bundles flag or how the default behavior differs.

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 gives a specific verb-and-resource pair: it compiles the catalog and metrics of the online Markdown doctrine library and generates packages for three named platforms. It is clear what the tool does, though it does not explicitly differentiate 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?

The description states what the tool does but gives no guidance on when to use it, when not to use it, or which alternative tools to choose. No prerequisites or sequencing are mentioned.

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

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

No annotations, so description carries burden. It discloses that queries are one term at a time and that results come with citations ready, but omits operational details such as authentication, rate limits, timeout behavior, or whether all 10 sources are queried live.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action and scope; the 10-organism list is necessary for scope precision and no sentence 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 search tool with no output schema, the description names scope and output format. However, with no annotations and many siblings, it leaves usage and operational expectations underspecified.

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 single parameter is documented in schema. Description adds meaningful constraint 'un término a la vez' clarifying the parameter accepts one term, not multiple, beyond schema's 'Término o frase'.

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', resource 'término', scope across 10 named state organisms, and output with citations. The enumeration of organisms distinguishes it from per-agency siblings like cgr_search_jurisprudencia and sii_search_circulares, which target single institutions.

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?

Scope implies use for cross-organism searches, and 'un término a la vez' constrains input, but it does not explicitly state when to choose this over the many per-agency sibling tools or any 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?

With no annotations, the description carries the full burden, and it discloses a great deal: it returns a plan, does not modify anything, does not consult external services, only reads input, decides the legal subject by rules rather than guessing, and says so when information is insufficient. The only caveat is that the absolute claim 'no consulta servicios externos' sits uneasily beside the estudio_completo parameter's mention of a BCN normative query, which may be local or external; this slight ambiguity prevents 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?

The instruction is front-loaded with the trigger condition and examples, and every clause adds information: output type, side effects, and matter-determination rule. It is long but not wasteful; a little more paragraph separation would improve scannability.

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?

Without an output schema, the description adequately specifies the return as a PLAN with components (what it is, tools/order, gaps), and it covers triggers, side effects, and the honesty rule for insufficient information. It does not describe the effect of estudio_completo, but the schema already covers that parameter.

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%, so the baseline is 3 and the description does not need to document each parameter. It reinforces entrada as the input to read and hints at deduction behavior for tipo, but it adds little specific meaning about consulta or estudio_completo 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?

The description opens with a specific trigger condition ('Usala SIEMPRE que la persona pida analizar un caso...'), lists concrete example phrases, and defines the resource and output ('Devuelve un PLAN...'). It also distinguishes itself from likely siblings by stating it does not modify anything and returns a plan, so an agent can separate it from analysis/execution tools like caso_ejecutar or pjud_analizar_sentencia.

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 when-to-use guidance ('Usala SIEMPRE que...') and includes varied phrasings to catch implicit requests, even when no tool is named. It does not name alternative tools or explicit when-not-to-use conditions, but the examples and 'No modifica nada...' effectively rule out mutation/execution 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?

The description discloses important behavioral traits: it can be slow because each step goes to the real source, failed steps are annotated with their error, and it never returns an invented result. These go beyond the schema and annotations (none provided), giving the agent critical expectations about latency and failure handling.

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 compact and front-loaded: it states the core function first, then the key behavioral warnings. Every sentence adds value, and the warning about slowness and error handling is placed early. No wasted words.

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 tool with no output schema and no annotations, the description covers the main operational expectations: what it does, what sources it touches, that it can be slow, and how failures are handled. It doesn't describe the return format or how to interpret the annotated errors, but the core context for calling it 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?

Schema description coverage is only 25%, so the description carries some burden. The description explains the overall execution flow but doesn't detail the meaning of `tipo`, `pasos`, `entrada`, or `limite_pasos` beyond what the schema provides. The schema covers `pasos` and `limite_pasos` partially, but `tipo` and `entrada` remain under-explained. Baseline 3 is appropriate because the description adds context about the plan execution but doesn't fully compensate for the low 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?

The description clearly states the tool executes the plan from `caso_analizar`, specifying the exact resources it queries (BCN, PJUD, CGR, DT, SII, CMF, SMA), the doctrina search, and folder documents. It distinguishes itself from sibling tools by referencing the specific plan it executes and the real-source behavior.

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 explains when to use it: after `caso_analizar` has produced a plan, and it warns about delays because each step hits real sources. It doesn't explicitly name alternatives or exclusions, but the reference to `caso_analizar` and the plan context provides clear usage context.

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

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

No annotations are provided, so the description carries the full burden. 'Retorna' implies a read-only lookup and the phrase 'checklist oficial' signals an authoritative fixed reference, but there is no statement about the response format, sourcing, or whether the checklist varies by jurisdiction beyond the property type.

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 wording. The parenthetical document list is compact and informative rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description usefully previews the return contents by naming the document categories. It is adequate for a simple one-parameter lookup, though it stops short of usage routing or noting how the property type changes the checklist.

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 tipo_inmueble and its accepted values are already fully documented in the schema. The description adds no meaning beyond it, 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?

States a specific verb and resource ('Retorna el checklist oficial de documentos requeridos para un estudio de títulos en Chile') and enumerates the document categories it covers (GP 30 años, dominio vigente, DOM, TGR). This is clearly distinguished from the sibling cbr_estudio_titulos, which performs the study rather than listing the required 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?

The description offers no explicit when-to-use guidance or prerequisites, and does not mention alternatives such as cbr_estudio_titulos. Usage must be inferred purely from the stated purpose.

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

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

No annotations, so the description must carry full behavioral burden. It states what it detects but omits whether the tool is read-only or mutating, permission requirements, error handling, rate limits, or output format.

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 dense sentence, front-loaded with the core action and resource. No wasted words, but the single-sentence format may under-serve the tool's complexity.

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 complex legal audit tool with no output schema and no annotations, the description covers purpose but omits when to use it, behavioral traits, and expected output. It is minimally adequate but leaves gaps an agent needs to call 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 coverage is 100%, so baseline is 3. The description reinforces the decenal 10-year context for 'anios_requeridos' default but adds no syntax, format, or item-level details beyond what the schema already provides.

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 'Audita', resource 'cadena de títulos de dominio decenal (10 años, Arts. 2510-2511 Código Civil) e inscripciones CBR', and explicit detection targets. Distinguishes from sibling cbr_checklist_documentos by focusing on chain audit rather than document checklist.

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 or when-not-to-use guidance. No alternatives named. Usage must be inferred entirely from the 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?

With no annotations supplied, the description carries the full behavioral burden. It discloses only the corpus size and source; it says nothing about result volume, whether the search is keyword or semantic, whether full text is returned, or any access constraints on this public-body 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 compact sentence with no filler, and the most decision-relevant facts (what is searched, whose reports, how many) are front-loaded. It is arguably too short for the guidance it lacks, but nothing in it 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 one-parameter read-only search with no output schema and no annotations, the description covers purpose and corpus but omits usage routing and any expectation about returned results, leaving the agent to guess at behavior on first call.

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 already documents itself with two concrete examples. The description adds only the scope of the searchable corpus, not any syntax, matching, or formatting guidance for 'query', 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 resource (Informes Finales de Auditoría e investigaciones especiales de la CGR), and quantifies the corpus, so the agent knows exactly what is searched. It does not, however, differentiate itself from the sibling cgr_search_jurisprudencia, which likely covers an overlapping CGR document set.

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 conditions, and no mention of an alternative tool. The agent must infer from the tool name alone when this is preferable to cgr_search_jurisprudencia or the other search siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about return behavior, result limits, ranking, pagination, or authentication. 'Vinculantes' implies a binding-effect filter but is not explained. Significant gap for a search tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste. It states the institution and document type efficiently.

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 search tool with no annotations and no output schema, the definition omits return format, result limits, and how to scope or refine queries. The schema documents the query param, but the description leaves the agent without enough to call the tool confidently.

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%; the single 'query' param is documented with examples in the schema. The description adds no syntax, format, or query-construction guidance beyond what the schema already 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 ('Busca') and resource ('dictámenes vinculantes en la jurisprudencia administrativa de la CGR'), identifying both the institution and the document type. It is clear against most siblings, though it does not distinguish itself from other *_search_jurisprudencia siblings (tdlc, pjud, ambiental) beyond naming the CGR.

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 indication of when to use this tool versus alternatives, nor any prerequisites, scope limits, or exclusions. The word 'vinculantes' hints at a scope filter but is not an actionable usage rule. The agent 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?

No annotations provided, so the description carries the full burden. It discloses return content (literal text, official bracket, link) and batch failure handling ('lo que falle queda en faltantes'), which is useful. It does not discuss error semantics, permissions, or whether input must be a valid norm, leaving gaps for a no-annotation 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?

Three tight sentences, front-loading the core verb and output, then the workflow precondition, then the batching tip. No filler, though the batching sentence partly duplicates schema guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-param read tool with no annotations and no output schema, the description covers return content, the mandatory workflow precondition, and batch failure behavior. Only minor gaps remain around error/permission handling.

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 with examples. The description reinforces the batching semantic of `referencias` but adds no syntax or format detail beyond the schema. Baseline 3 is 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 and resource: 'Devuelve el TEXTO LITERAL de una norma citada', plus distinguishing output details (corchete oficial y enlace). An agent can tell this apart from generic law-fetchers like bcn_get_ley because it returns citable literal text with official formatting.

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?

Explicit when-to-use: 'Usala antes de citar cualquier artículo: el producto no cita sin texto' tells the agent the precondition. It also gives batch guidance for `referencias'. It does not name the sibling tools to prefer over/under, so it falls short of explicit 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?

No annotations are provided, so the description carries the full behavioral burden. It says the audit is 'formal' but never discloses what is actually checked (formal structure, citations, legal validity?), what the output looks like, whether the draft is modified, or what permissions are needed. For a tool with zero annotation coverage this is a significant 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 well-formed sentence with no filler, front-loading the action ('Audita formalmente el borrador') ahead of the qualifiers. It is appropriately sized, though it is arguably too terse to carry the disclosure burden it inherits from the absence of annotations.

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 and no annotations, so the description must alone explain what an audit yields. It never states what the audit returns (findings? a pass/fail? a corrected draft?) or how results are shaped, leaving the agent unable to set expectations for the call.

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 both parameters ('tribunal' with default 'Civil', and 'borrador_texto') are already documented in the schema. The description adds no format or usage detail beyond that, so the baseline of 3 for schema-covered parameters 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 and resource: 'Audita formalmente el borrador de un escrito' and adds the workflow context (draft authored by an intern, prior to the supervising lawyer's signature). This is much clearer than a tautology, but it never distinguishes itself from the sibling tool 'clinica_lenguaje_claro', which plausibly also inspects legal text, so an agent must guess which to call.

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 embeds timing context ('antes de la firma electrónica del abogado tutor'), which implies when the tool fits in the workflow. However, it gives no explicit when-not guidance and does not point to any alternative sibling (e.g. clinica_lenguaje_claro) for adjacent review tasks, leaving selection to inference.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the ficha is persisted or only returned, whether the datos_usuario object is validated or how sensitive personal data (RUT, socioeconomic status) is handled, or what the agent receives back. For a generation tool handling personal data, this is a meaningful 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, well-formed sentence that front-loads the verb and the artifact produced. Nothing is wasted, though it is a bit short given the tool's complexity.

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 explain what the 'ficha sociojurídica' contains and whether it is stored, but it does not. For a tool that consumes a nested personal-data object and produces a document, the definition is under-specified relative to its complexity.

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, establishing a baseline of 3. The description adds nothing beyond the schema and even loosely frames the scope as 'familia, civil o laboral', which does not map cleanly onto the schema's enum-like values ('alimentos', 'precario', 'cuidado_personal').

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 ('Genera la ficha sociojurídica de ingreso') and scopes it to a clear domain (free legal aid clinics, family/civil/labor matters). It is distinguishable from the other 'clinica_' siblings, but it never names or contrasts them, 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 explicit when-to-use, when-not, or alternative-tool guidance. The usage is only implied by the domain phrase 'consultorios de asistencia judicial gratuita', leaving the agent to infer when intake is appropriate versus auditing a draft (clinica_auditar_borrador) or plain-language rewriting (clinica_lenguaje_claro).

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

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

No annotations are provided, so the description carries the full burden. 'Traduce' implies a generative transformation but the description does not state whether the output is a faithful legal rendering, whether content may be summarized or omitted, what caveats apply, or whether the output requires human review. For a legal-domain transformation tool this is a significant disclosure 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 well-formed sentence with zero waste, front-loaded with the verb and resource and finishing with the audience qualifier.

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 legal-domain generative tool with no annotations and no output schema, the description omits key context: output format, fidelity constraints, handling of sensitive data, and any review requirement. The audience is clear but an agent lacks enough to invoke this responsibly in a legal setting.

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%, so the schema already documents both parameters and their defaults. The description adds no syntax, length limits, or format guidance beyond what is in the schema. 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 (traduce) and resource (resolución judicial chilena densa) with output characteristics (lenguaje claro, accesible, empático) and target audience (usuarios de CAJ). This is distinguishable from siblings like pjud_interpretar_proveido or vigilante_analizar_resolucion, which analyze rather than translate for laypeople.

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 audience ('usuarios de consultorios jurídicos CAJ') implicitly signals when this tool applies: when a plain-language rendering for a lay client is needed. However, there is no explicit when-not-to-use guidance and no named alternative for adjacent tasks such as analyzing or auditing resolutions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose read-only status, authorization requirements, result format, pagination, or limitations, leaving the agent with little beyond the basic purpose.

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 front-loaded sentence with no filler or repetition. Every element serves to identify the registry being searched.

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, the description plus schema is enough to invoke it. However, it omits routing guidance among several similar search siblings and gives no sense of result scope, so it is only minimally 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?

The single parameter has 100% schema description coverage, and the schema already explains that 'query' accepts an entity name, infraction, or resolution number. The description adds no parameter-level detail beyond what the schema provides, 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 uses a specific verb, 'Busca', and names the exact resource: the official registry of CMF sanction resolutions and sanction procedures. This clearly distinguishes it from siblings such as cmf_search_normativa, which covers regulations rather than sanctions.

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 states what is searched but gives no explicit when-to-use guidance, no conditions for choosing it over alternatives like sma_search_sancionatorios or cmf_search_normativa, and no exclusions. Usage is only implied 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?

No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether search is full-text or exact-match, how results are ranked or paginated, or what the response contains, adding only that the scope is NCG/circulars.

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, well sized for a one-parameter search tool. It is perhaps too sparse to guide selection, but nothing in it is 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 low-complexity single-parameter search with no output schema, the description defines scope adequately but omits any indication of return format or result volume. That leaves an agent without expectations about what a call returns.

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 'query' parameter already documents accepted inputs with examples ('461', 'gobierno corporativo'). The description adds no syntax or format detail beyond the schema, 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 clear verb (Busca) and a specific resource (Normas de Carácter General y circulares de la CMF), naming the document types so an agent can distinguish it from cmf_buscar_sanciones. It lacks any explicit contrast with the sibling, but the scope is otherwise 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 statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer usage from the scope alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Consulta' implies a read-only lookup, which is useful, but the description does not state whether the operation has side effects, requires authentication, has rate limits, or how results are formatted. For a simple getter this is minimally adequate, but more explicit read-only or safety notes would help.

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, front-loaded sentence that captures the essence of the tool with zero wasted words. It is appropriately sized for a simple lookup tool and easy to parse.

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 a single optional parameter, no output schema, and no annotations, the description states what the tool does but omits usage guidance and return-value expectations. It is minimally viable: an agent knows it queries a registry, but not what a response looks like or when this tool is preferred. It could more fully compensate for the lack of structured metadata.

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%: the single 'region' parameter is already documented in the schema as 'Región de Chile (opcional)'. The description adds no additional meaning about the parameter (e.g., valid values, filtering behavior beyond what the schema states). With high schema coverage, 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 states a specific verb ('Consulta') and resource ('registro de centrales generadoras activas y proyectos energéticos') with clear scope ('en el SEA de la Comisión Nacional de Energía'). No sibling tools cover energy registries, so differentiation is trivial, and an agent can immediately understand what data this tool retrieves.

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 no guidance on when to use this tool versus alternatives. It does not state any conditions, prerequisites, or scenarios that would select it over other tools. It merely describes the resource, leaving usage entirely to inference.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add useful behavioral detail such as A4 formatting, divider covers, TOC markers, and editable .docx output, but it does not disclose side effects, overwrite behavior, permissions, or return values, and it internally contradicts the required output_pdf_path by saying documents are delivered in Word, not PDF.

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 short and front-loaded with the core verb 'Compila', but the tail clause repeats the Word delivery idea and adds contradictory delivery information. It is concise in length but not tightly structured or fully coherent.

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 tool has 6 parameters, no annotations, and no output schema, so the description must explain behavior more completely. It covers the main output concept but omits what happens with optional output paths, what the tool returns, and the inconsistency around PDF vs Word leaves the agent with significant ambiguity.

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 baseline is 3. The description adds some extra meaning by mapping Markdown input to formal PDF/Word outputs, but it does not clarify optional parameters like main_pdf_path or mobile_preview_path beyond what the schema already documents.

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 action: compiling a judicial brief or complaint from Markdown into a formal A4 PDF with divider covers and TOC markers, plus an editable Word working copy. It is not a tautology, though it does not distinguish itself from similar siblings like export_brief_ojv, and the final clause claiming documents are delivered in Word, not PDF muddies the stated PDF output.

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 context: use this for formatting legal filings for OJV with formal PDF layout and an editable Word version. However, it does not explicitly state when to prefer this tool over alternatives nor what exclusions apply, and the contradictory delivery clause could mislead an agent deciding between PDF and Word outputs.

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?

With no annotations, the description still discloses the aggregation behavior across multiple sources and the output format: literal text plus a ready-to-paste citation bracket. It does not explicitly state that it is read-only or describe rate limits or auth needs, but the retrieval nature and output are transparent.

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, with the mandatory-first-step instruction front-loaded. There is minor repetition between 'PRIMER PASO OBLIGATORIO' and 'Usala antes de responder', but the structure is efficient and every sentence has a purpose.

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?

No output schema or annotations are provided, so the description carries the burden, and it explains both the aggregated sources and the literal-text-plus-citation output. It covers the primary use and the environmental exception, though it omits failure modes, limits, and explicit read-only confirmation.

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 both `consulta` and `max_fuentes` documented in the input schema. The description adds no further syntax, default, or formatting detail for the parameters, so the schema 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 action: it consults the Hugging Face dataset, canonical doctrine, graph, and detected Chilean norms, then returns sources with literal text and a citation bracket. It clearly distinguishes itself from the environmental sibling by naming `ambiental_consulta_maestra` for environmental matters.

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?

Explicitly says it is the mandatory first step for every legal query, to be used before answering even if the agent thinks it knows the answer. It also names the alternative tool and condition when the subject is environmental, leaving no inference needed.

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

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

No annotations are provided, so the description carries the full burden. It states what is verified (ordinary and extraordinary faculties) but not what the result looks like (e.g., pass/fail, error details), whether it's a read-only operation, or any rate limits. The description adds some behavioral context (formal audit) but is insufficient for a validation tool with no structured safety hints.

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 is front-loaded with the core action and specific legal references. There is no wasted verbiage; every clause contributes to defining the 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?

Given no annotations, no output schema, and a single required parameter, the description is incomplete. It does not explain what the audit returns, how errors are reported, or any prerequisites. For a validation tool that likely produces a structured verdict, this leaves the agent guessing.

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 single parameter is fully documented in the schema. The description does not add meaning beyond what the schema provides (it mentions 'texto de un mandato' implicitly, but the schema already says 'Texto del otrosí de patrocinio y poder o escritura pública de mandato'). Baseline 3 is appropriate when 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?

States a specific verb ('Audita formalmente') and resource ('texto de un mandato judicial y patrocinio') with legal precision, including the specific statutes checked (Ley 18.120, Art. 7 CPC). It is distinguishable from siblings, though sibling names are opaque and don't overlap in obvious ways. The purpose is clear but lacks scoping detail like output format or consequences.

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 guidance on when to use this tool versus alternatives, nor when not to use it. The legal references imply a narrow scope, but the agent is left to infer that this applies only to mandate texts. No alternatives are named.

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?

With no annotations, the description carries the full behavioral burden. It says the audit uses the product's critique engine but does not disclose permissions, reversibility, rate limits, output format, or any side effects. The listing of dimensions is not behavioral context, so a low score is warranted.

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, front-loaded sentence with no filler. It efficiently states the tool's purpose and scope. It could be slightly more structured (e.g., separating purpose from usage) but is highly concise.

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 tool with two simple parameters, no output schema, and no annotations, the description gives the core purpose and dimensions. However, it omits any indication of return format, usage context, or behavioral traits, leaving meaningful gaps for an agent to infer.

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%, so both parameters ('texto' and 'provider') are already documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides. Per the rubric, baseline 3 is correct 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 and resource: 'Auditoría forense de un borrador judicial' with five named dimensions and the product's critique engine. This clearly conveys what the tool does. However, it does not differentiate itself from similarly named siblings like clinica_auditar_borrador or other analysis tools, so a 4 is appropriate.

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 a context (auditing a judicial draft) but provides no explicit when-to-use, when-not-to-use, or alternative selection guidance. No siblings are mentioned as alternatives. This falls short of the clear context expected for a 4 or the implied usage of a 3.

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

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

No annotations are provided, so the description carries the full burden. It discloses the rich content returned (definition, requirements, procedural details, concordances, rulings), which is useful. However, it does not state whether this is a read-only operation (implied by 'Recupera'), any rate limits, or how the data is sourced/updated.

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, front-loaded sentence that efficiently enumerates the key outputs. It is appropriately sized for the tool's complexity, with no wasted words, though the long list could be marginally streamlined.

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 tool with two well-described parameters and no output schema, the description is fairly complete: it tells the agent what will be returned and implies the retrieval nature. The main gap is the absence of any guidance on when to prefer this over sibling tools that also deal with institutions.

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 both parameters with examples. The description does not add syntactic or semantic detail about the parameters (e.g., how 'área' interacts with 'nombre', or tolerance for approximate names) beyond what the schema provides.

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 ('Recupera') and resource ('ficha dogmática y forense completa sobre una institución jurídica específica'), and enumerates the components of that ficha. This clearly distinguishes it from siblings like doctrina_search or graphify_explicar_institucion, which are search/explanation tools rather than full doctrinal file retrieval.

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: use when you need a complete doctrinal and forensic profile of a specific legal institution. However, no explicit when-to-use vs. alternatives (e.g., doctrina_search or graphify_explicar_institucion) is provided, leaving the agent to infer selection criteria.

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?

There are no annotations, so the description carries full burden. It explicitly discloses the side effects: updating the Knowledge Graph (legal_knowledge_graph.json) and the SQLite FTS5 index automatically. This is significant behavioral context for a conversion tool that modifies persistent state, and it is clearly stated.

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 dense sentence that front-loads the core conversion action and then lists the side effects. It is concise yet packs substantial information without unnecessary repetition. It could be slightly reorganized for readability, but it earns its 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 the tool's complexity (7 parameters, no output schema) and the absence of annotations, the description covers the main function, accepted formats, and automatic updates. It does not detail error handling or the exact Markdown formatting, but it provides enough for an agent to understand the tool's role and 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 input schema already documents all parameters thoroughly. The description adds marginal value by mentioning the file_path formats and the graph update option, but it does not provide additional semantics beyond what the schema states, so a 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 states a specific verb ('Convierte') and resource ('documentos... a Markdown canónico') and also mentions the automatic update of the Knowledge Graph and SQLite index. It clearly distinguishes this ingestion tool from search/retrieval siblings like doctrina_search and doctrina_get_institucion, making its purpose 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?

The description implies the tool is for adding or converting doctrine documents into the system, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusionary conditions (e.g., 'use doctrina_search for querying instead'). The context of sibling tools suggests the usage context, but the description itself lacks clear when-to-use 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?

With no annotations, the description carries the full burden. It usefully discloses the returned payload (authors plus statistics), which is meaningful since there is no output schema, but says nothing about authentication, result size, pagination (there is no pagination parameter at all), or freshness of the index.

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, source, and return contents with no redundancy. The phrase 'indexados en la base de datos de Open Legal Chile' is slightly verbose but does establish provenance.

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 zero-argument read-only listing with no output schema, the description tells the agent what the tool returns and where the data comes from, which is enough to invoke it correctly. Only the relationship to doctrina_search and any result-size caveats are 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; by the stated rule a 0-parameter tool gets the baseline of 4. The description correctly implies a no-argument, full-catalogue call.

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 well-defined resource ('tratados y manuales dogmáticos de doctrina chilena'), and even names what the results contain (autores y estadísticas). It is clearly distinct from a search tool, but never names the sibling doctrina_search to reinforce the boundary.

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 word 'todos' implies an enumeration/browse use case as opposed to a targeted lookup, so an agent can infer when to prefer this over doctrina_search. However, there is no explicit when-to-use, no exclusions, and no named alternative, leaving the routing decision implicit.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the corpus and the ranking mechanism (FTS5 and BM25), which is real behavioral context. However, it omits return format, pagination behavior, and permission requirements, leaving meaningful gaps for a search 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?

The description is a single front-loaded sentence with no wasted words. The core action and corpus come first, followed by the method and author list, making it easy for an agent to parse quickly.

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 four-parameter search tool with no annotations and no output schema, the description identifies the corpus and search method but omits when to use it versus alternatives and what a result looks like. It is adequate for basic invocation but incomplete for confident tool selection and result interpretation.

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 all four parameters, including area, autor, limit, and query. The description adds no parameter-specific syntax, format, or interaction details beyond what the structured schema already provides, so the baseline score 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 bounded resource: the dogmatic canon of the most-cited Chilean legal manuals and treatises, naming eight authors. The corpus and semantic/BM25 search method clearly distinguish it from sibling search tools like dt_search_doctrina or panel_expertos_search.

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 does; it gives no when-to-use guidance, no exclusions, and no routing against the many sibling legal-search tools. An agent must infer from the corpus that this is for Chilean dogmatic doctrine, with no explicit alternative or trigger condition.

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?

With no annotations, the description carries the full behavioral burden. It conveys only that results are 'vinculante' (binding) labor doctrine, but says nothing about result format, ranking, pagination, coverage limits, or whether the corpus is complete. That is a real gap for a search 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 efficient sentence with the resource and authority front-loaded and no filler. It is appropriately sized for the scope, though it leaves room for a routing clause that would cost little.

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 with no output schema and no annotations, the description is minimally adequate: it tells the agent what corpus is searched. It does not, however, explain how results should be interpreted or when this corpus is the right one to consult.

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 required parameter and schema description coverage is 100% – the schema already documents 'query' with examples ('acoso laboral ley karin', 'artículo 161', '344'). The description adds no further meaning, 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 resource ('dictámenes, pronunciamientos y doctrina laboral') scoped to a named authority ('Dirección del Trabajo'). It is clear what the tool retrieves, but it does not differentiate itself from similar siblings such as 'doctrina_search' or 'tdlc_buscar_icg_y_dictamenes'.

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 says what is searched but never states when to use this tool versus alternatives, nor any exclusions or prerequisites. In a sibling set containing several other doctrine/jurisprudence search tools, this omission forces the agent to guess.

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

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

No annotations are provided, so the description bears the full burden. It implies a read-only consultation of public-organ information and specifies the subject-matter coverage, which is useful. However, it does not disclose operational traits such as data source, update freshness, authentication needs, or return format.

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. It efficiently lists the legal domains the tool covers and gives concrete organ examples without burying the purpose.

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 consultation tool with no output schema and no annotations, the description adequately explains what information is retrieved. It could be more complete by indicating the likely return format or source, but the core scope is covered.

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 one required parameter with 100% schema description coverage. The schema already explains that 'organo' takes a sigla or name and gives examples. The description expands the organ examples (CGR, SERNAC, SMA, CPLT), which is mildly useful, but does not add semantic 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 ('Consulta') and resource ('órganos públicos'), and enumerates the information domains: ley orgánica, facultades fiscalizadoras, vías de reclamo. This is clear enough for an agent to know what the tool returns, but it does not distinguish itself from potentially overlapping siblings such as graphify_explicar_institucion or doctrina_get_institucion.

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 says what can be consulted but gives no explicit when-to-use guidance, no exclusions, and no comparison with alternative tools. Usage is only implied by the tool name and description.

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?

With no annotations, the description carries the burden but does disclose that the tool is read-only without arguments and mutating when both question and answer are provided. It does not cover permissions, error handling, overwrite behavior, or side-effect details, leaving meaningful gaps.

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; the two behavioral modes are separated clearly by the semicolon.

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, 0-required tool with full schema coverage and no output schema, the description covers both invocation modes adequately. It could say more about base_dir behavior, validation, or persisted-profile semantics, but the essential invocation picture is 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 description coverage is 100%, so the schema already documents all three parameters. The description adds only the high-level distinction that 'pregunta'+'respuesta' saves a key; it does not add format or constraint semantics 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+resource ('Entrevista de arranque del estudio') and describes two invocation modes. It does not explicitly distinguish itself from any sibling tool, but the purpose is clear and non-tautological.

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 explains the parameter-based behavior: without arguments it returns the questionnaire and current profile, with 'pregunta' and 'respuesta' it saves a profile key. This implies usage, but it does not state when to use this tool versus alternatives or any prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It states the tool generates and exports, but does not disclose whether it writes files to disk, returns content, requires file paths, needs network/auth, or what happens on típica missing fields. The multiple output formats are mentioned but not how the format is selected (schema has no format parameter).

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 action and resource. No wasted words, though it packs multiple format claims into a long clause rather than structuring them clearly.

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 7-parameter tool with 5 required structured inputs and no annotations and no output schema, the description is thin. It doesn't explain how the four formats are chosen or returned, what the caller must supply beyond the listed fields, or what 'exporta' means operationally (file vs response). It's not misleading, but it leaves major behavioral gaps for a fairly complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters with useful descriptions (e.g. 'Capítulo I. Los Hechos'). The description adds no parameter-level meaning beyond what the schema provides. 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 ('Genera y exporta') and resource ('escrito judicial estructurado formalmente para la Oficina Judicial Virtual'), and names the legal framework and output formats. The 'export_brief' name aligns. Compared to siblings like 'clinica_auditar_borrador' or 'compile_legal_dossier', the OJV-specific framing distinguishes it, though it doesn't explicitly contrast with 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?

No indication of when to use this tool versus alternatives such as 'clinica_auditar_borrador' (which drafts/audits) or 'compile_legal_dossier'. No prerequisites, no mention that the input must already contain structured chapters (hechos/derecho/peticiones)., leaving an agent to infer.

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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the concrete output artifacts and their format (editable .docx, A4, justified, plus HTML/MD/TXT/JSON), the auto-retrieval of doctrine/jurisprudence from local material, the integral transcription of cited norms, and the governing rule "no se cita sin texto". Gaps remain around permissions, latency, and failure behavior, but this is well above the annotation-free 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?

Front-loaded with the core action and outputs before the type list and the 'informe' elaboration. It is dense and runs long with stacked parentheticals, but nearly every clause carries information and the closing product rule "no se cita sin texto" is a clean, memorable anchor.

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 tool with no annotations, no output schema, and only 50% schema description coverage, the description covers outputs, types, and informe behavior but never maps which parameters are required for which 'tipo' (e.g. whether a demanda civil needs demandante/tribunal) nor how output-format selection works. Adequate but with clear gaps for this complexity.

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% on 18 parameters, so the description must compensate. It adds real meaning for the 'informe' workflow (normas transcribed in full with citation and link, doctrine/jurisprudence auto-searched when omitted, dictamen behavior) but leaves roughly half the parameters, including type-specific ones like demandante/demandado/tribunal/peticiones, with no cross-parameter context 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+resource ("Genera un documento de trabajo completo") with concrete output formats (Word .docx editable, A4, justified text, plus HTML/MD/TXT/JSON) and enumerates the document types matching the 'tipo' enum. It is highly specific, but it never addresses its overlap with the sibling recurso_proteccion_generar, which appears to cover the 'proteccion' type.

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?

Implicitly tells the agent which document types are supported and that doctrine/jurisprudence are fetched automatically "cuando no se las entregan", which is useful routing info. However, there is no explicit when-to-use-this-vs-X guidance for closely related siblings such as recurso_proteccion_generar or compile_legal_dossier.

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

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

No annotations are provided, so the description carries the burden. It does disclose the return artifacts (código Mermaid and JSON), which is genuinely useful given there is no output schema. However it says nothing about how nodes/edges are validated, error behavior, or size/scale limits.

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 no filler; the resource and outputs are front-loaded. It is efficient, though it sacrifices some structure that could have carried usage guidance.

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 graph-construction tool with no output schema and fully documented params, the description adequately conveys inputs (people, companies, organisms as nodes) and outputs (Mermaid and JSON). It is complete enough to invoke, with the main gap being behavioral/operational context rather than field-level detail.

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 examples fully document the nodes and edges shapes plus the title field. The description only hints at node categories ('personas, empresas y organismos') and adds no syntax or format detail beyond the schema, so the baseline 3 holds.

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 (Construye) and resource (red de vínculos societarios, políticos y judiciales entre personas, empresas y organismos), plus the output forms (Mermaid y JSON). This lets an agent understand the operation clearly, though it does not explicitly distinguish itself from the graphify_* siblings that also deal with relationship graphs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent must infer its role purely from the verb and resource, with no routing advice toward or away from siblings like graphify_consulta_subgrafo.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the composed output (questions, linked norms, doctrine, rubric), which is the main behavioral trait for a generation tool, but omits anything about scope limits, determinism, jurisdiction assumptions, or permissions.

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 verb and resource come first and the output inventory follows compactly. Nothing is padded or repeated.

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 tool with no output schema, the description compensates by naming the four components of the generated cédula, giving the agent a reasonable picture of the return value. It stops short of full completeness because constraints on topics or output size remain 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?

There is a single parameter 'tema' with 100% schema description coverage, including example values ('Obligaciones', 'Responsabilidad', 'Posesión', 'Recursos'). The description adds nothing about granularity or format beyond the schema, 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 ('genera') and a concrete, domain-specific resource ('cédula completa de examen de grado'), and enumerates the artifacts it produces (preguntas, normas vinculadas, doctrina canónica, pauta de evaluación). This clearly separates it from retrieval-oriented siblings like bcn_get_ley or doctrina_search, though it never explicitly contrasts itself with the closest siblings grado_interrogar and grado_obtener_flashcards.

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 says what the tool produces but gives no indication of when to reach for it versus grado_interrogar or grado_obtener_flashcards, nor any prerequisites (e.g. whether a topic must map to a known legal area). Usage must be inferred entirely from the name and output 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?

No annotations are provided, so the description carries the full burden. It hints that the tool interrogates and evaluates, but does not disclose whether the interaction is single-shot or multi-turn, how answers are supplied (there is no answer parameter), what permissions are needed, or what the evaluation output contains.

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. It is efficient, though it packs three ideas (socratic questioning, exam context, evaluation doctrine) into one clause chain without structural separation.

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 no annotations, the description should explain how the interrogation works, especially given that the only inputs are materia and dificultad and there is no parameter for supplying an answer. The evaluation flow and return behavior remain unexplained, leaving a meaningful gap for an interactive 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?

The input schema has 100% description coverage for both parameters (materia, dificultad), including defaults and example values, so the schema does the heavy lifting. The description adds no parameter-specific meaning beyond that, which makes 3 the appropriate 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 ('Interroga socráticamente') and resource (law graduate exam questions in Chile) with an explicit evaluation goal, so an agent can identify the function. It does not differentiate against siblings like grado_generar_cedula or grado_obtener_flashcards, which is why it falls short of 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, no prerequisites, and no exclusions. The exam-practice context is only implicit in 'examen de grado' and never framed as a routing condition.

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

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

No annotations, so the description carries the full burden. It does not disclose whether results are cached, personalized, randomized, or limited in number, nor any auth or rate behavior. Only the content domain is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single efficient sentence that front-loads the verb and the resource. No wasted words, though extremely terse given the lack of other guidance.

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 fetch with full schema coverage and no output schema, the description is minimally adequate. It does not explain what a flashcard contains or count limits, but the schema covers parameters well enough to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters, so baseline 3. The description adds semantic context by clarifying that 'definicion' relates to definiciones sacramentales and 'plazo' to plazos fatales, reinforcing the enum-like values 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) plus scope (definiciones sacramentales, plazos fatales procesales). Clearly distinguishable from siblings like grado_generar_cedula, but it does not name those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies study/exam usage context but never states when to choose this over alternatives like grado_generar_cedula or grado_interrogar. No when-not or exclusions provided.

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?

With no annotations, the description carries the full burden and discloses key behaviors: it reads the folder, builds the graph, writes an HTML file, opens it in the browser, and reports skipped documents with reasons. It does not state potential file-system side effects in detail, but the main mutations are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler, front-loads the usage trigger, and then provides the process and observable output. Every sentence contributes useful 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?

For a single-parameter tool with no annotations and no output schema, this description is complete: it identifies the input, the action, the artifact produced, the browser side effect, and what feedback the agent will receive about read/skipped documents.

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 tool description reinforces that ruta refers to the case folder but adds no new format, examples, or constraints 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?

The description states a clear verb and resource: it reads a case folder and builds a graph, with an HTML output. It is clearly about case-folder graph generation, but it does not explicitly differentiate itself from sibling tools such as grafo_ver_corpus or generar_grafo_vinculos.

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 says when to use the tool by listing natural-language triggers like «graficá este caso» and «mostrame el expediente como grafo». However, it does not mention when not to use it or name alternatives, so it earns a 4 rather than 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?

With no annotations provided, the description carries the behavioral burden and does disclose the main side effect: it writes an HTML file that opens in the browser and returns the file path. It also describes the visualization features, though it omits details like file cleanup, permissions, or persistence.

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 compact and front-loaded with the usage trigger, then states behavior, scope, and return value in a single efficient paragraph. Every sentence adds distinct 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?

For a tool with no output schema, the description appropriately states that it returns the file path and explains the generated artifact. It could be stronger by explicitly contrasting with sibling graph tools, but the core behavior, input scope, and output are sufficiently covered.

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 explains both parameters. The description adds context by framing 'consulta' as a 'subgrafo de una consulta', but it does not add meaningful detail about 'max_nodos' beyond what the schema already states.

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 clearly identifies a specific action and resource: it writes an interactive HTML graph file for the corpus or a query subgraph. It does not explicitly differentiate itself from siblings like grafo_ver_caso or graphify_consulta_subgrafo, so it stops short of full sibling distinction.

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 opens with explicit usage direction: 'Usala cuando pidan ver el grafo' and provides concrete trigger phrases such as 'mostrame el grafo' and 'mostrame el grafo de despido'. However, it gives no when-not-to-use guidance or mention of alternatives, so it lacks exclusions.

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

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

No annotations are provided, so the description bears full behavioral disclosure. It states what is computed (blast radius, grado 1 and 2) but does not disclose whether the operation is read-only, what the output format looks like, computational constraints, or how the graph is traversed — behaviorally thin for a graph analysis tool with no 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, dense sentence that front-loads the core function (calculating blast radius) and immediately specifies the trigger condition (reform or jurisprudential shift) and the output granularity (grado 1 and 2). No 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 1-parameter graph analysis tool without an output schema or annotations, the description covers the purpose and output tiers but lacks information on return format, traversal methodology, or performance characteristics. It is adequate but leaves gaps an agent would need to infer.

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 parameter count is 1, so baseline is 4 when no params = 4, but here there is one well-documented parameter. The description adds the conceptual meaning of 'objetivo' (norma legal o institución jurídica) beyond the schema's example-based definition, though it doesn't add syntax details.

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 specifies a precise verb and resource — calculating a topological blast radius when a legal norm suffers reform or jurisprudential shift — and details the output tiers (grado 1 directo, grado 2 cascada). This distinguishes it clearly from sibling tools like graphify_trazar_camino or graphify_consulta_subgrafo.

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 (when a legal norm or institution experiences reform or jurisprudential change) but does not explicitly state when to use this over sibling tools like graphify_consulta_subgrafo or graphify_trazar_camino. The context is inferable but not spelled out.

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?

With no annotations, the description carries the full burden. It does convey that this is a consult-style operation producing synthetic hyper-dense subgraphs and quantifies token efficiency, which adds behavioral context. However, it does not disclose the output shape, size limits, or any side-effect/reliability considerations beyond the extraction claim.

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 dense sentence and remains readable, but it mixes the core function with a specific token-savings statistic and a reproducibility pointer. That metric is not needed for tool selection or invocation and distracts from more actionable routing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.