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 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether this is read-only, whether the returned content is the current in-force version, how 'estructura' differs from an article lookup, or anything about response format or 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, front-loaded sentence with no filler; the verb, scope, and the complete list of codes all appear immediately with zero waste.

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

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

For a two-parameter lookup tool with no output schema and no annotations, the description covers what the tool does and its input domain, but leaves the return shape and the distinction from historical/ley siblings unaddressed.

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, but the description adds real value by enumerating all nine valid values of the required 'codigo' parameter (civil, trabajo, cpc, penal, comercio, tributario, mineria, aguas, cpp), whereas the schema only offers three example strings. The optional 'articulo' behavior (omit to get structure) remains implicit.

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 (los 9 Códigos de la República de Chile) and even enumerates all nine codes, so the agent knows exactly what domain it covers. It does not, however, differentiate itself from close siblings like bcn_get_ley, bcn_get_ley_historica, or bcn_get_codigo_historico, which an agent could easily confuse it with.

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

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

The purpose implies usage (retrieve articles or structure of a code), and the enumerated codes scope the valid inputs. But there is no explicit statement of when to reach for this tool versus bcn_get_ley or the historical variants, and no when-not 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 are provided, so the description carries the full behavioral burden. 'Consulta' implies a read-only lookup, but the description says nothing about authentication, rate limits, whether historical versions are exhaustive, or the response shape. For a tool with zero annotation coverage this is a notable 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 the resource and the historical-date scope front-loaded and no filler. Efficient, though it could have spent a few more words on sibling routing.

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

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

For a simple read-only lookup with no output schema, the description is minimally adequate: it conveys resource, historical scope, and date format. It omits the fact that a specific article can be requested, and, lacking annotations, does not compensate behaviorally.

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

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

Schema description coverage is 100%, so the schema already documents fecha, codigo, and articulo. The description only restates the date format and adds a few código examples (civil, trabajo, cpc, penal), which duplicates the schema's own examples and adds little beyond it. Baseline 3 applies.

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

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

States a specific verb (Consulta) and resource (Código de la República) with the key scoping qualifier 'en una fecha histórica específica', which implicitly distinguishes it from the current-version sibling bcn_get_codigo. It does not, however, explicitly name that sibling or any other alternative, so differentiation is inferable rather than stated.

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

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

Usage is implied: the tool is for retrieving a code at a historical point in time. There is no explicit statement of when to prefer this over bcn_get_codigo (current text) or bcn_get_ley_historica (historical law), and no exclusions or prerequisites are given.

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

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

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 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 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?

With no annotations provided, the description carries the full behavioral burden. It implies a filesystem write (generating a PDF at output_pdf_path) but does not disclose overwrite behavior, failure modes when annex files are missing, order of assembled annexes, or any permission/limit constraints. Only the transformation itself 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?

A single dense sentence that front-loads the verb and resource, then layers on formats and annex assembly. No filler, though it omits any usage or behavioral context that could have earned the sentence more.

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 document-generation tool with no output schema and no annotations, the description covers the transformation adequately but omits the return value (e.g. resulting PDF path/status), error conditions, and what the optional mobile_preview_path produces. The high schema coverage offsets some of this gap.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, and the baseline is 3. The description adds only 'A4 formal' and the notion of institutional separator covers (which are auto-generated, not a parameter), adding marginal meaning 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 names a specific verb (compila/compiles) and resource (escrito judicial o denuncia) and specifies both input (Markdown) and output (formal A4 PDF) formats, including annex assembly. It is highly self-explanatory, though it does not explicitly differentiate itself from document-related siblings like export_brief_ojv or biblioteca_compilar_manifiesto.

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 produces but gives no guidance on when to use it versus alternatives, nor any preconditions (e.g. required input template, valid file paths). No when-to-use or when-not-to-use information is present.

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?

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?

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?

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?

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?

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 behavioral burden. It discloses the output style (synthetic hyper-dense subgraphs) and token-efficiency benefit, but does not state side effects, permissions, rate limits, or return structure beyond the schema-documented Mermaid option.

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 names the resource and output type before adding the token-savings value claim. It is efficient, though the 80%-95% promotional figure adds little for tool selection.

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

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

For a read-only query tool with no output schema and no annotations, the description explains the resource and output nature but omits usage routing, output format details, and operational constraints. The fully described input schema compensates partly, but key decision context is still missing.

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

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

Schema description coverage is 100%, so the schema already documents query, max_hops, and incluir_mermaid. The description adds no parameter-level meaning beyond what the schema provides, 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 ('Consulta') and resource ('Knowledge Graph Jurídico de Doctrina Chilena / LegalGraphify'), plus the kind of output extracted (subgrafos sintéticos hiper-densos). It does not distinguish itself from graphify siblings such as graphify_trazar_camino or graphify_explicar_institucion, so sibling differentiation is missing.

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 explicit when-to-use or when-not-to-use guidance relative to the many graphify and legal-search siblings. Usage is only implied by the query parameter and the mention of token savings versus manuals or conventional RAG.

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 usefully describes the shape of the returned explanation (definition, BCN support, Supreme Court criteria, procedural operatives, topological degree), but says nothing about permissions, cost, latency, or whether the operation is read-only.

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, leading with verb and resource before enumerating outputs. Efficient and appropriately sized for the tool's scope.

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

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

With no output schema, the description does well to outline the return content, which is the most important missing structured information. However, it omits routing guidance relative to the many sibling tools, leaving a real gap for correct tool selection.

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 is well documented in the schema itself with examples ('simulacion', 'imprevision', 'nulidad'). The description adds no further parameter meaning, 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 and resource ("Genera una explicación dogmática 360° de una institución jurídica") and enumerates the five components the explanation covers, so the agent knows exactly what it produces. It does not, however, explicitly differentiate itself from graphify siblings like graphify_consulta_subgrafo 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?

There is no when-to-use guidance and no named alternative. With several overlapping graph/doctrina tools in the sibling list, the agent is left to infer when this tool is preferable to graphify_consulta_subgrafo or doctrina_get_institucion.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that results are computed via PageRank/centrality over a knowledge graph (an analytical, implicitly read-only operation), but says nothing about cost/latency of a graph-wide algorithm, determinism, or error behavior for an empty graph.

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

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

A single dense sentence with zero filler, front-loading the deliverable (God Nodes) before the method. Every clause contributes information, and the parenthetical gloss on the jargon aids interpretation.

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 computation tool with no output schema, the description should hint at the return shape (ranked nodes, centrality scores). It implies a ranking of principal institutions/norms via top_n but never states the form of results, leaving a moderate gap.

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

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

There is only one optional parameter (top_n) and the schema description coverage is 100%, so the schema already defines its meaning and default. The description adds no extra semantics beyond what the schema provides, making the baseline 3 correct.

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

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

States a specific verb ('Identifica') and a clearly named resource ('pilares dogmáticos estructurales / God Nodes del sistema jurídico chileno'), plus the method (PageRank y centralidad sobre el Knowledge Graph). An agent can distinguish this from graphify_analizar_impacto or graphify_explicar_institucion by the analytical concept, though no sibling is explicitly named.

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

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

There is no when-to-use guidance, no prerequisites, and no reference to the other graphify_* siblings (consulta_subgrafo, trazar_camino, explicar_institucion, analizar_impacto). Usage must be inferred entirely from the general topic of graph analysis.

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 hints that the tool deduces subsumption chains and dogmatic argumentation, but it does not disclose operational traits such as whether it is read-only, what permissions it needs, how expensive the traversal is, or what the 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?

The definition is a single front-loaded sentence with the main verb and resource first. It contains no redundant or filler content.

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 pathfinding tool with no output schema and no annotations, the description should do more to explain the return shape or traversal behavior. It is minimally adequate because it identifies the operation and the conceptual output, but an agent still lacks details about what the paths look like and when this tool is the right choice.

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 origen, destino, and max_caminos with examples and a default. The description aligns with the two endpoint concepts but adds no extra meaning about parameter formats or constraints beyond the schema, matching the baseline 3.

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: calculating and tracing minimum relational paths between two legal concepts or norms within LegalGraphify. It is clear what the tool does, but it does not distinguish itself from sibling graph tools such as graphify_consulta_subgrafo or graphify_analizar_impacto.

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 legal-reasoning use case through 'deduciendo cadenas de subsunción y argumentación dogmática', but it gives no explicit guidance on when to use this tool instead of the other graphify sibling tools. No alternatives, prerequisites, or exclusion conditions 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 are provided, so the description carries the full behavioral burden, and it discloses little. It does not say the tool only drafts (and does not send or file the letter), whether it requires any party/authorization data, or what the produced document looks like. For a no-annotation generation tool 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 efficient sentence that front-loads the action and resource. No filler, nothing to trim.

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

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

No output schema and no annotations, so the description should have clarified the return (e.g. the drafted letter text) and the drafting-only scope. It is minimally adequate given complete parameter documentation, but leaves the output contract unstated.

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?

All four parameters are required and schema description coverage is 100%, so the schema already explains titular, infractor, marca_afectada, and hechos_infraccion. The description adds nothing beyond the schema, which is the expected baseline here.

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 ('Redacta') and a concrete resource ('carta formal de Cese y Desistimiento'), plus the two legal bases (Ley 19.039 marca, Ley 17.336 propiedad intelectual). The purpose is clear, though it never names a sibling (e.g. inapi_evaluar_marca) to sharpen boundaries against similar INAPI-branded tools.

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 dual legal grounds (trademark vs. intellectual property) imply when the letter applies, but there is no explicit when-to-use, when-not-to-use, or alternative routing. Usage must be inferred 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 usefully signals that the result is preliminary rather than binding, but says nothing about whether the call is read-only, whether it accesses live INAPI records, latency, or what the returned assessment 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; every phrase (preliminar, viabilidad, distintividad, Niza, INAPI) contributes to scoping the tool.

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

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

For a small two-parameter tool this is nearly adequate, but with no output schema the description should at least indicate what the preliminary evaluation returns (e.g., a viability/distinctiveness signal) and how class selection affects it. The absence of that leaves a gap an agent cannot fill from structured data.

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% (both clase_niza and marca_propuesta are documented, including a default and examples for the Niza class). The description adds nothing about parameter meaning, so baseline 3 applies.

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

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

The description gives a specific verb (evalúa), resource (marca comercial), and scope qualifiers (preliminarmente, viabilidad y distintividad, Clasificador de Niza, ante INAPI). This is enough for an agent to distinguish it from the only nearby sibling, inapi_cease_and_desist, which is an enforcement action rather than an evaluative 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 word 'preliminarmente' implies this is an initial screening rather than a definitive filing or legal opinion, which hints at when to use it. However, the description never states when NOT to use it, what prerequisites exist (e.g., must a Niza class be chosen first), or what to do if a definitive registration step is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says the tool 'downloads and analyzes' but does not mention read-only nature, authentication requirements, rate limits, or what the analysis entails. This is a significant gap for a data-retrieval 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 that conveys the action, resource, source, and input method without any wasted words. It is appropriately sized for a simple retrieval tool.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but leaves gaps: it does not explain what 'analiza' means in practice or what the return value looks like. More detail on output or behavior would improve completeness.

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 the single parameter thoroughly. The description's phrase 'por URL o identificador' is redundant with the schema and adds no extra meaning or format details 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 and resource: 'Descarga y analiza la Declaración de Intereses y Patrimonio (DIP) de una autoridad pública desde InfoProbidad (CGR/CPLT) por URL o identificador.' It clearly identifies the document type and source, and no sibling tool covers the same resource, so no confusion arises.

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 by specifying the input types (URL or identifier) and the target document (DIP of a public authority), but it does not explicitly state when to use this tool versus alternatives or any prerequisites. Usage 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?

No annotations are provided, so the description must carry the full behavioral burden. It mentions accepted file types (PDF, escrito judicial, Markdown) and the target notebook, but says nothing about side effects, permissions, failure modes, or whether it appends or replaces sources.

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. It efficiently conveys the core action, accepted formats, and target system.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It omits usage context, prerequisites, side effects, and any indication of what happens on success or failure, leaving the agent underinformed about how to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only the notion of a local file upload and file types, but no additional syntax, constraints, or meaning beyond the schema itself. 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 (Sube) and resource (archivo local) and the exact target (cuaderno de Google NotebookLM). It clearly distinguishes itself from siblings like notebooklm_create_notebook, notebooklm_query, and notebooklm_list_notebooks.

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, exclusions, or context of use. It only describes what it does, not when or why to choose it.

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

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

With no annotations, the description carries the full disclosure burden: it correctly signals a mutation ('Crea') and helpfully states the returned values (URL and notebook_id). However, it says nothing about authentication requirements, whether the notebook is created in a personal or shared account, or whether the operation is idempotent on repeated titles.

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

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

One sentence, front-loaded with the action, and the return values appended without filler. Nothing extraneous and no repetition of the schema.

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 creation tool with no output schema, stating the returned URL and notebook_id is a meaningful addition. It falls short only on operational context (auth, account scope) that an agent would otherwise 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 coverage is 100% and the single 'title' parameter is documented in the schema itself. The description confirms a title is needed implicitly but adds no constraints (length, uniqueness, default naming), so it matches the baseline 3 for well-covered schemas.

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 ('Crea un nuevo cuaderno de investigación jurídica en Google NotebookLM') and even names the return artifacts. It clearly differs from siblings like notebooklm_list_notebooks, notebooklm_add_source, and notebooklm_query, which operate on existing notebooks.

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 create a notebook versus reusing an existing one (e.g., after calling notebooklm_list_notebooks), nor any prerequisite or exclusion. Usage must be inferred entirely from the tool 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. 'Lista' implies a read, but there is no mention of read-only safety, pagination, ordering, or authentication requirements for the NotebookLM backend.

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 return fields front-loaded. No wasted text, though it is terse rather than rich.

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, parameterless list tool with no output schema, the description covers what is returned (notebook_id and metadata) and scopes the result set to active notebooks. It is sufficient, though pagination or ordering behavior remains unstated.

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

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

The tool takes zero parameters, so there is nothing to document; per the baseline for 0-param tools this sits at 4. The description correctly implies no filtering input is required.

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

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

States a specific verb (Lista) and resource (cuadernos de investigación jurídica activos en Google NotebookLM), plus what is returned (notebook_id y metadatos). It is clear against unrelated siblings, though it does not explicitly name the related notebooklm_create_notebook / notebooklm_query tools it could be confused with.

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 versus notebooklm_create_notebook, notebooklm_add_source or notebooklm_query. The word 'activos' hints at a filter but no conditions or alternatives are given.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that the response is 'grounded con citas' (citation-backed, derived from loaded documents), which is real behavioral context beyond the schema. However, it says nothing about permissions, rate limits, or what happens with an empty/unpopulated notebook.

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 key trait (grounded with citations) front-loaded and no wasted words. It is appropriately sized, though very lean given the missing usage detail.

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-required-parameter query tool with no output schema, the description partially compensates by noting citations are returned. But it omits any usage routing, prerequisite, or failure-mode context that an agent would need to invoke it 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%, so both parameters (prompt, notebook_id) are already documented in the schema. The description adds no syntax, format, or constraint details beyond that, 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 ('realiza una consulta fundada') and resource ('documentos cargados en un cuaderno de NotebookLM'), so the agent knows this retrieves grounded answers from a notebook. It is clearly distinguishable from notebooklm_create_notebook/add_source by the query verb, though it does not explicitly name those siblings.

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

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

No guidance on when to use this versus the many search/query siblings (doctrina_search, pjud_search_jurisprudencia, etc.) or versus notebooklm_list_notebooks. It does not state prerequisites such as a populated notebook or required auth.

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 mentions performing OCR but does not describe output format, whether files are modified, how mixed native/scanned pages are handled, or which engine is used by default. Additionally, it only mentions Tesseract while the schema supports multiple engines, creating a minor inconsistency. These gaps are significant for a 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?

The description is a single sentence that is front-loaded with the core action and resource. Every word earns its place, and there is no redundancy or 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?

The tool has a moderately complex schema (5 parameters, one enum) and no output schema, so the description should clarify return values or behavior. It implies that text is extracted but does not specify the output format, pagination, or error handling. Given the rich parameter coverage in the schema, a 3 is the minimum viable level, though more behavioral detail would improve completeness.

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 five parameters thoroughly (including engine options and page ranges). The description adds no parameter-level detail beyond the schema and even omits the other engine choices, but the baseline for high coverage is 3. No extra semantic value is provided.

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 ('Extrae texto nativo o ejecuta OCR') and resource ('expedientes PDF judiciales, actas notariales o resoluciones públicas escaneadas'), making the tool's function clear. It distinguishes itself from siblings, none of which perform PDF OCR, though it does not explicitly name any alternative. A score of 5 would require explicit sibling differentiation, but the purpose 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?

Usage is implied: the tool is for scanned legal PDFs when native text extraction is insufficient. However, there is no explicit guidance on when to choose this tool over alternatives (e.g., other document-processing siblings) or when not to use it, nor any stated prerequisites. A 3 is appropriate for implied usage with no exclusions.

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

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

No annotations are provided, so the description carries the full burden. It hints that results are binding ('vinculantes'), but says nothing about return format, result volume, pagination, or any access constraints for a search against a specialized tribunal.

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 tight sentence with the resource and scope front-loaded and no filler. 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 one-parameter search tool with no output schema and no annotations, the description covers what is searched but omits return semantics and usage boundaries. Minimum viable rather than 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% and the single 'query' parameter is fully documented with examples ('peajes', 'coordinador electrico'). The description adds nothing beyond that, 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'), a precise resource ('dictámenes vinculantes y resolución de discrepancias técnicas y tarifarias'), and the institution that scopes it ('Panel de Expertos de la Ley Eléctrica'). This is distinct from siblings like tdlc_buscar_icg_y_dictamenes or cgr_search_jurisprudencia, which cover other bodies.

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 identifies the domain but gives no when-to-use guidance, no prerequisites, and no routing advice relative to the many sibling search tools (tdlc, cgr, pjud, cmf, etc.). The agent must infer that this tool applies only to electricity-law panel matters.

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 full behavioral burden. It doesn't state whether processing is read-only, whether the input must be plain text (vs PDF), what happens with incomplete sentences, or how results are returned. It only describes output structure, not operational behavior.

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 action and packs the structural taxonomy efficiently. No filler or repetition.

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

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

For a 1-parameter analysis tool with no output schema and no annotations, the description explains the output taxonomy but omits expected input size, error conditions, and usage context. It is adequate but leaves the agent to infer significant operational details.

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 a single well-described parameter, so the baseline is 3. The description adds no syntax or formatting detail beyond the schema's own description of texto_sentencia.

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 (Desglosa) and resource (sentencia judicial chilena) and enumerates the exact structural components it extracts per Art. 170 CPC. Clearly distinguishable from siblings like pjud_interpretar_proveido or search tools.

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 versus alternatives such as pjud_interpretar_proveido or pjud_search_jurisprudencia, nor any prerequisites (e.g., input must be a full sentence text). The description only tells what it does, not when to choose it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the tool performs a simple lookup, a legal reasoning step, or generative interpretation; no mention of permissions, rate limits, side effects, or output format. The agent cannot predict what the tool actually returns.

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

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

A single well-structured sentence that front-loads the purpose and scopes it with concrete examples. No unnecessary padding, though it could be slightly more concise by not repeating the full list of proveído types.

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 should clarify what the interpretation entails (e.g., returns a structured analysis, a summary, or legal risk flags). It leaves the return value and behavioral profile completely unspecified, which is a significant gap for an interpretation 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% and there is a single required parameter whose schema description ('Texto del proveído o resolución judicial breve') is adequate. The tool description adds examples of what kinds of texts qualify, which marginally enriches parameter meaning, but baseline 3 applies because the schema already documents the parameter fully.

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 (interpretar) and resource (proveídos frecuentes) with concrete examples ('Téngase presente', 'Como se pide', 'Traslado', 'Autos para fallo'). It doesn't explicitly differentiate from siblings like pjud_analizar_sentencia, which could confuse an agent about scope, but the domain focus is clear.

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

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

There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives. The agent must infer that this tool is for short judicial decrees rather than full sentences, but nothing in the description directs it away from pjud_analizar_sentencia.

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 supplied, so the description carries the full behavioral burden. It does not mention read-only nature, authentication, result limits, pagination, or return format, leaving the agent with no behavioral disclosure beyond the topic.

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

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

A single dense sentence with the action front-loaded and the scope qualifiers following; nothing is wasted.

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

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

For a simple two-parameter search with no output schema, the description covers the corpus scope but says nothing about result behavior, limits, or how results are returned. Adequate but with clear gaps given the absence of annotations.

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 'sala' documented with examples in the schema itself, so the baseline is 3. The description adds only the corpus context, not additional meaning about parameter syntax or the sala codes.

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 ('sentencias y fallos rectores') and narrows the corpus to Corte Suprema unification rulings (Laboral, Constitucional, Civil) and Tribunal Constitucional. This differentiates it from siblings like pjud_analizar_sentencia (analyses one ruling) or pjud_interpretar_proveido, though it never names them explicitly.

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

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

Usage is implied by the stated corpus scope: you use it to find Corte Suprema unificación and TC precedents. There is no explicit when-to-use vs. alternatives guidance and no mention of the sibling search tools (cgr_search_jurisprudencia, ambiental_buscar_jurisprudencia, etc.).

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 of behavioral disclosure. It states that the tool processes and generates an official response model, but omits critical details such as required permissions, whether the response is saved or returned, side effects, or any rate 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and 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?

Given no output schema and no annotations, the description should explain return values and behavioral context more fully. It hints at generating a response model but does not describe the output format, legal caveats, or what happens after generation, leaving gaps for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four required parameters. The description adds no additional meaning about parameter formats, valid values, or interactions beyond what the schema provides. Baseline 3 is appropriate 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: 'Procesa y genera el modelo oficial de respuesta a solicitudes de Derechos ARCO'. This clearly distinguishes it from all siblings, none of which handle ARCO rights. However, it does not explicitly differentiate from any sibling by name or function.

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, nor does it state prerequisites or exclusions. Usage is only implied by the legal context in the 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 provided, the description carries the full burden. It usefully discloses the validation method (Módulo 11) and that it returns a canonical format, which implies a stateless, read-only operation. But it omits critical behavior: what happens with an invalid RUT (error vs. boolean false) and the exact shape of the returned value.

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

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

One well-formed sentence with the action, resource, method, and output front-loaded and no filler. Nothing redundant or wasteful.

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 validation utility with no annotations and no output schema, the description adequately covers purpose, method, and the fact that it produces a canonical format. It falls just short of complete because the return value and invalid-input behavior 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?

Schema description coverage is 100% with a single parameter, so the schema already explains that the RUT is accepted with or without dots/dashes. The description adds only slight context by noting persona natural o jurídica, which is not a parameter detail, so baseline 3 applies.

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

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

The description states a specific verb (valida) and resource (RUT chileno de persona natural o jurídica), and even names the mechanism used (algoritmo oficial Módulo 11). This makes it unmistakable among the sibling tools, none of which touch RUT validation.

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 implicit in the purpose — an agent can infer this is the tool to call when it needs to check or normalize a Chilean RUT. However, there is no explicit when-to-use framing, no prerequisites, and no mention of related alternatives or follow-up tools in the suite.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it delivers only the purpose sentence. It says nothing about whether the search is read-only, whether results are paginated or capped, what the default date window behavior returns, or the shape of results.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though also minimal — there is no second sentence to add routing or behavioral 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?

Given a simple two-parameter search tool with fully covered schema descriptions and no output schema, the definition is minimally adequate. The gap is that it never distinguishes itself from the adjacent SII circulars search or states result/pagination behavior.

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' as term or resolution/oficio number, 'anios' defaulting to 2023-2026) are already documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Busca') and a precisely named resource set: Resoluciones Exentas y Oficios Ordinarios de Jurisprudencia Administrativa del Director del SII (Art. 26 CT). This resource specificity implicitly separates it from the sibling sii_search_circulares, which covers a different document type, though the alternative is never named.

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 sii_search_circulares or the broader search siblings (cgr_search_jurisprudencia, tdlc_search_jurisprudencia). The document type narrows the domain implicitly, but there is no explicit when-to-use, when-not-to-use, or prerequisite 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?

No annotations are provided, so the description carries the full burden. It does not disclose result format, pagination, whether results are exhaustive, or any rate/permission behavior. Only the content scope (circulares, 2020-2026) 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?

A single, front-loaded sentence with no filler. Nothing is wasted and the key scope (source + timeframe) is stated immediately.

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

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

For a single-parameter search tool with no annotations and no output schema, the description covers what is searched and the time window, but omits differentiation from the near-identical SII sibling and any hint about return format or result limits.

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 is already documented with examples in the schema. The description adds no additional semantics beyond what the schema provides, so 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 (busca) and resource (circulares e instrucciones oficiales del SII) with a date range, which is reasonably specific. However, it does not differentiate from the very similar sibling 'sii_buscar_resoluciones_y_oficios', leaving the agent unsure which SII source to prefer.

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

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

No guidance on when to use this vs alternatives such as sii_buscar_resoluciones_y_oficios or bcn_get_codigo. The description only says what it searches, not in which contexts an agent should reach for it.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the subject matter. It does not state that the operation is read-only, how results are returned, whether pagination or result caps apply, or what happens with empty/partial matches.

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. It is efficient, though the brevity comes at the cost of the missing usage and behavioral detail noted elsewhere.

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

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

For a one-parameter search tool with no output schema, the description identifies the domain clearly but omits return-format, result-volume, and matching-behavior context an agent would need to call it confidently. 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% and there is a single required 'query' parameter with an example in the schema, so the baseline is 3. The description adds no syntax, matching behavior, or format guidance 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?

States a specific verb ('Busca') and resource ('expedientes y procedimientos sancionatorios ambientales'), plus the authoritative source (SNIFA/SMA). It is distinguishable from nearby siblings like ambiental_buscar_jurisprudencia, but it never explicitly contrasts itself with those siblings.

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

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

The description gives no when-to-use guidance, no prerequisites, and no alternative tools to prefer for a given case. An agent must infer from the source name alone when this search is appropriate versus ambiental_buscar_jurisprudencia or cmf_buscar_sanciones.

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