Clerk - IA Legal Dominicana

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

Beyond readOnlyHint/openWorldHint, it discloses non-obvious behavior: substring matching inside the recorded name («Fiallo» matches anywhere, homonyms included), that invalid distrito/materia return errors listing valid values «nunca un cero», and pagination of 20 per page with `total` and per-state counts. Return fields are enumerated, which matters with no output schema. Minor gap: no indication of result ordering or truncation limits on large name 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?

Front-loaded with purpose and search keys, then return contents, then semantics and warnings. The return-field enumeration is dense but earns its place since there is no output schema. Nothing is wasted, though the parenthetical list of hearing outcomes could be tightened.

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 read-only search with no output schema and no annotations beyond readOnly/openWorld, it covers everything an agent needs: what is searched, what comes back, how paging works, how errors behave, and which sibling to use for a different question.

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 meaning on top: the matching semantics of `consulta`/`por` (substring within the recorded name), and the clarification that «conocida» is the already-celebrated hearing carrying its outcome. The failure mode for bad `distrito`/`materia` values is also explained, which the schema does not state.

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 («Busca en el Rol Nacional de Audiencias del Poder Judicial dominicano») plus the three lookup keys (NUC, nombre de parte, nombre de representante). It also draws an explicit boundary against the jurisprudencia siblings: «El rol no es jurisprudencia: dice qué se conoce y cuándo», so an agent can distinguish it from buscar_jurisprudencia and verificar_decisiones without opening any schema.

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

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

Gives explicit routing: use this for hearing dates/status, but «Para saber si un expediente ya tiene sentencia, verificar_decisiones con su `nuc`» names the alternative and its condition. It also warns that party names and subject matter are transcribed by the court and «no se citan», telling the agent how to treat results.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context the annotations don't: accent-insensitive full-text matching, 50-per-page pagination, the `total` field, and the critical `aviso_lista_cortada` signal meaning truncated results. However, it does not state the return shape beyond field names or describe ranking/ordering behavior, so a 3 is appropriate rather than higher.

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?

Long but front-loaded and well-organized: core purpose, then search behavior, then the tipo trap, then pagination, then citability, then exclusion. The multiple warning emoji and some repetition of the 'reglamentos are archived as decretos' point cost it a bit of tightness, but no sentence is irrelevant.

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

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

With no output schema, the description carries the return-value burden and does so: it names `total`, the 50-per-page pagination, the `aviso_lista_cortada` truncation flag, and `doc_id` plus leer_decreto for citation. Nothing an agent needs to search, paginate, detect truncation, or cite is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the numero format and page sizing. The description reinforces the type-filter trap for `tipo` and clarifies that `terminos` searches inside the norm text, which is genuinely useful, but it largely restates what the schema already says. 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 ('Busca DECRETOS y REGLAMENTOS del Poder Ejecutivo dominicano') and immediately scopes what it returns (número, Gaceta Oficial, PDF). It distinguishes itself from web search and from its sibling buscar_normas_reguladores by naming the excluded corpus 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?

Gives an explicit routing rule ('Úsala EN LUGAR de una búsqueda web'), a concrete example use case (reglamento de Compras y Contrataciones), a warning against the tempting tipo='reglamento' filter, and an explicit exclusion routed to buscar_normas_reguladores. Both when-to-use and when-not-to-use are covered.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description nonetheless adds real behavioral context: full-text vs title matching, the es_texto_normativo flag marking normative text, aviso_versiones warning that editions are not marked as current, and the articulos_de_revista sub-results. What it does not do is describe ranking, pagination limits, or the timeout ceiling — the latter is instead carried by the rows parameter description in the schema.

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

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

Front-loaded with the core matching semantics in the first sentence, then layered warnings, so the most important information survives skimming. It is long and the emoji-laden warnings add visual noise, but nearly every sentence carries distinct operational content rather than filler.

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

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

There is no output schema, and the description compensates fully by enumerating the returned fields (título, autores, editorial, páginas, isbn13) plus the conditional ones (es_texto_normativo, aviso_versiones, articulos_de_revista con autor y temas). For a three-parameter read tool it leaves nothing an agent needs to call it correctly or to interpret the response.

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

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

Schema coverage is 100% and the schema itself is unusually rich, including the ~30 s gateway timeout guidance for rows. The description adds meaning not in the schema by tying result fields to the sibling tool's parameters (isbn13, articulo, clave), but it says nothing about how terminos is interpreted (multiple terms, AND/OR, stemming), which is the one parameter an agent most needs to understand.

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 (búsqueda de libros y publicaciones jurídicas dominicanas) and, crucially, the matching semantics: the hit is in the full text of the work, not the title, with concrete examples («anatocismo» devuelve el Diccionario Jurídico Dominicano). It also separates itself from leer_doctrina (which serves the text) and from buscar_legislacion (which does not hold codes), so an agent can pick it out among 25 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?

Explicit when-to-use ("Úsala para saber A QUÉ DOCTRINA acudir"), explicit hand-off (pass the isbn13 to leer_doctrina, the clave for Revista Saber y Justicia articles), and an explicit exclusion/correction: codes and reglamentos are in this library but NOT in buscar_legislacion, so search them by title here. It even states the read-before-attributing rule.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavior beyond that: catalogue size (~204 obras), that items are free and downloadable, that search matches title/subject/description and NOT book text, and that the returned value is a slug to feed into leer_doctrina_constitucional. It also warns about a genuine misuse risk (citing a TC book as if it were the court's holding).

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

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

Front-loaded with what the collection is, then the doctrine-vs-jurisprudence caveat, then sibling routing, then the return hint — a sensible information order. It runs long and repeats the warning motif (double ⚠️ and a restated doctrine point), which costs a little density but not comprehension.

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 exists, and the description compensates by naming the returned field (`slug`) and the tool that consumes it. Combined with the collection scope, search-scope limits and sibling routing, an agent has everything needed to call it and chain 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 both parameters are already documented in detail, including the literal-phrase warning and the max-3-term union behavior. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies; the closing note about `slug` is output semantics, not input semantics.

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 ('Publicaciones del Centro de Estudios Constitucionales... libros y colecciones que edita el propio TC') and immediately separates it from buscar_jurisprudencia and buscar_doctrina by collection. An agent can pick this tool over its siblings without opening any schema.

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

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

Explicit routing: doctrine vs. tribunal criteria ('Para el criterio del tribunal, buscar_jurisprudencia'), and the sibling distinction from buscar_doctrina ('biblioteca del Poder Judicial: son dos colecciones distintas'). It also names the downstream tool (leer_doctrina_constitucional) and gives the citation rule (author + page).

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

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

Annotations declare readOnlyHint=true/openWorldHint=true, so the safety profile is already covered; the description goes further by disclosing the silent-failure mode (a bad filter value yields HTTP 200 with zero results) and the mitigation (`busqueda_ejecutada: false` with diagnostics and near-spelling suggestions). It also reveals that results are split across `documentos`, `complemento_tc`, `complemento_scj` and `complemento_archivo`, and that partial TC/SCJ holdings sit outside `documentos` — real behavior an agent cannot infer from schema or annotations. It stops short of describing pagination/timing beyond the `rows` warning, so a 4 rather than a 5.

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

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

The first sentence is front-loaded and the ⚠️ blocks are individually high-value, but the description runs to five warning sections with some redundancy (each complemento_* block repeats "se lee con obtener_texto_completo y su id") and mixes return-shape detail into what is nominally a usage statement. It is dense rather than wasteful, yet noticeably longer than needed for an agent to act correctly.

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 13-parameter tool with nested `excluir`, no output schema, and a large sibling fleet, the description covers what an agent must know: response blocks, the `busqueda_ejecutada: false` diagnostic shape, `frase_tal_cual` on results, `avisos`, and cross-tool handoffs. Nothing essential for a correct first call 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 coverage is 100%, so the baseline would be 3, but the description adds meaning well beyond it: tribunal shortcuts SCJ/TC/TSA/TST and automatic grapheme expansion, the trap that metadata values are not facet vocabulary («Sala Primera» vs «Primera Sala»), the materia spelling hazards (hyphenated «Contencioso-administrativo», split «Inmobiliaria»/«Tierras»), and sort guidance that `score desc` biases toward recent Supreme Court rulings while «fecha asc» surfaces settled doctrine.

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?

Opens with a specific verb+resource: "Busca sentencias y decisiones judiciales dominicanas", and immediately scopes the corpus as Dominican, distinguishing it from the many sibling tools covering Colombia, España, Francia, electoral, interamericana, etc. It also states what comes back (total, documentos normalizados, filtros aplicados), so an agent knows both what it does and where it fits.

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

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

Explicitly says to use this INSTEAD of a web search ("la web no trae el texto de las sentencias"), and routes to siblings by name: explorar_facetas for valid vocabulary and obtener_texto_completo (modo «mapa») for the dispositivo of older rulings. It also gives when-NOT guidance — don't cross `sentido` with pre-2024 years, don't raise `rows` before narrowing with facets.

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

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

Annotations already cover readOnlyHint and openWorldHint, so the safety bar is low; the description adds substantive context the annotations cannot: the result is a relatoría catalog (tema + resumen) meant for triage and NOT as a citation, with citable text deferred to leer_sentencia_colombia. Minor gap: the opening 'por texto completo' could be read as the return being full text, though the later sentence corrects the scope.

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

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

Front-loaded with the resource identity, then usage, then the critical 'not citable' caveat and return semantics. Every sentence earns its place, though the warning-heavy middle section is somewhat dense; still well organized and free of filler.

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

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

With no output schema, the description carries the return-values burden and does so: it explains that results are catalog entries (tema, resumen) for triage, not citations, and points to the sibling that produces citable text. Combined with routing and terminology guidance, an agent has everything needed to invoke and interpret this 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 83%, so the baseline is 3, but the description meaningfully augments the key parameter semantics: it warns the search is LÉXICO and that query terms must match Colombian magistrate phrasing ('tutela' vs 'amparo'), which is not in the schema. This lexical/terminology guidance adds real value beyond the enum and date formats documented in the schema.

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

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

States a specific verb and resource (full-text search of Colombian Constitutional Court rulings) and immediately differentiates from siblings by naming buscar_jurisprudencia for Dominican law and leer_sentencia_colombia for citable text. An agent can distinguish this from the Spain/France/doctrine siblings without opening a schema.

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

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

Gives explicit when-to-use (comparative constitutional doctrine to support an argument), when-not (it is not Dominican law and binds no RD court — persuasive only), and the alternative to use instead for RD-applicable material. Both routing conditions and the exclusions are 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?

Annotations only declare readOnlyHint and openWorldHint; the description supplies the real behavioral context: accent-insensitive matching, AND semantics across all terms, 50-per-page pagination, a `total` field, and the `aviso_cobertura` partial-coverage caveat warning that a zero result does not mean no ruling exists. It also flags that the «relativo a» field is a secretary transcription, useful for triage but not citable.

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

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

Front-loaded with purpose, then usage, then two clearly marked ⚠️ caveats — good scanability. Slightly long, and the pagination detail in the body partially duplicates the `page` schema description, but every sentence still carries information.

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

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

There is no output schema, and the description compensates by naming the fields the agent will encounter (`total`, `aviso_cobertura`) and how to interpret them. Combined with the follow-up tool guidance, an agent has everything needed to call it and act on the response.

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 genuine meaning beyond it: that searching covers both the full text and the listing fields (número, expediente, relativo a), that accents are ignored, and that all terms must match simultaneously. The `anio` bounds are implicit (coverage starts 2021) rather than spelled out as a valid-value range.

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 (buscar sentencias del TSE) plus the material scope (2021 en adelante) and the subject-matter taxonomy (amparos, impugnaciones, nulidades, conflictos internos). This cleanly separates it from the generic buscar_jurisprudencia and the country-specific buscar_jurisprudencia_colombia/espana/francia 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?

Gives an explicit use-instead instruction ("Úsala EN LUGAR de una búsqueda web") and an explicit exclusion ("Las de antes de 2021 no están"). It also routes the agent forward to obtener_texto_completo with `tse` and `modo: "criterio"`, so the workflow after a hit is unambiguous.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description is consistent with both. It adds context the annotations cannot carry: the corpus is limited to the Constitutional Court (not the Supreme Court) and the output is non-binding persuasive authority rather than Dominican law. It does not discuss pagination limits or result volume, which would be the remaining behavioral 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?

Front-loaded with the resource and mode, then usage condition, then the two scope warnings, then the ambito rationale. It is dense and every sentence carries information, though the emoji-prefixed warnings lengthen it slightly more than a plain-text statement would.

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

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

For a read-only search tool with a full schema and no output schema, the description covers what an agent needs: what is searched, which court, which parts of a resolution, and the legal status of the results. Nothing required for correct invocation or correct framing of results 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 coverage is 100%, so baseline is 3, but the description adds interpretive weight to 'ambito' by explaining that the distinction between 'fundamentos' (where the ratio lives) and 'votos_particulares' (what is NOT the court's criteria) is precisely what separates criteria from non-criteria. That exceeds the schema's own enum descriptions in emphasis and purpose, though it covers only one of the five parameters.

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

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

States a specific resource (resoluciones del Tribunal Constitucional de ESPAÑA) and retrieval mode (texto libre), and explicitly scopes the court ('Solo Tribunal Constitucional; el Tribunal Supremo español NO está disponible'). Combined with the country qualifier, an agent can distinguish it from buscar_jurisprudencia_colombia, buscar_jurisprudencia_francia and the generic buscar_jurisprudencia without opening any schema.

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

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

Gives an explicit trigger condition ('Úsala cuando haga falta doctrina constitucional comparada') plus a clear exclusion (not binding Dominican law, only persuasive) and a court-level limitation. It stops short of naming sibling alternatives to route to (e.g. usar buscar_jurisprudencia_colombia para Colombia, leer_resolucion_espana para texto completo), so it is strong but not complete.

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?

Goes well beyond readOnlyHint/openWorldHint: discloses that results are restricted to the requested court unless incluir_instancias_inferiores is true, that each hit carries an `organo` field to check before citing, that the corpus is French-language and searched lexically, and that `resumenes` are non-citable cataloguing summaries.

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

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

Purpose is correctly front-loaded in the first line, but the body is four stacked warning blocks with escalating emoji, and the `organo`/inferior-courts warning is duplicated almost verbatim from the incluir_instancias_inferiores schema description. The meta line about the warning 'going further than usual' is 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?

With seven parameters and no output schema, the description carries the return-shape burden and does explain court scoping and the `organo` field. It says nothing about result counts, totals, ordering or how pagination behaves across a large corpus, which leaves a gap for a paginated search 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 already 86%, so the baseline is 3, but the description adds genuine meaning: it explains the default AND-semantics of `modo`, the need to search French terms rather than Dominican translations, and ranks the `tribunal` options by authority for RD rather than merely restating the enum.

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

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

Names a specific verb (buscar) plus resource and enumerates the three exact courts covered (Cour de cassation, Conseil constitutionnel, Conseil d'État), which cleanly separates it from siblings like buscar_jurisprudencia_espana or buscar_jurisprudencia_colombia. It also states the search modality (texto libre) up front.

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

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

Gives unusually explicit when/when-not guidance: the results are not Dominican law and do not bind RD courts, and it warns against the specific analogical trap of citing Cour de cassation on homologous Code civil articles. It never names the obvious companion tool leer_decision_francia for reading a hit in full, so the alternative-routing dimension is incomplete.

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?

Beyond the readOnly/openWorld annotations, it discloses important behavior: invalid filter values are not searched and the response reports which values are valid; each result carries an official citation to copy verbatim; and the response includes a required warning about the disputed force of the Court's rulings in the Dominican Republic.

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 front-loaded with the resource and scope, then moves efficiently through filters, validation behavior, citation rules, and the required warning. Every sentence earns its place, including the warning and next-step reading instruction.

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, open-world search tool with no output schema, the description supplies the essential context: what is searched, how filters work, what happens with invalid values, what the result includes, and how to handle the Dominican Republic warning. Nothing critical for correct invocation 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 coverage is already high at 83%, but the description adds meaningful semantics for key filters: `estado` is the respondent State and `articulo` means the Convention article declared violated in the operative part. It does not add detail for `anio`, `page`, or `terminos`, which the schema already covers.

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 (buscar) and resource (jurisprudencia de la Corte Interamericana), enumerating the exact document types covered. It is clearly distinguishable from generic or national-jurisprudence siblings because it explicitly scopes the search to the Inter-American Court.

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 a clear use directive ('Úsala EN LUGAR de una búsqueda web') and a workflow rule ('Lee cada decisión con leer_sentencia_interamericana antes de citarla'). It does not explicitly address when to prefer this over the generic buscar_jurisprudencia sibling, so it stops just short of full when/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?

Annotations only declare readOnlyHint and openWorldHint, so the description carries real weight and delivers: title-match ordering with `coincide_titulo`, the `aviso_cobertura` and `aviso_codigo` response flags, and the instruction to read those before concluding. The gateway-timeout guidance lives in the schema, and the description's framing ("con cara de acierto: eso NO significa que el texto no exista") discloses a non-obvious behavioral trap that no structured field captures.

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

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

Front-loaded: purpose, then coverage exclusions, then result-interpretation rules, then citation rationale. Dense but mostly earning its place. The closing paragraph on citing from the text rather than commentary is more scholarly guidance than invocation guidance, and the warning emojis plus bold markers make it heavier than necessary.

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

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

No output schema exists, and the description compensates by explaining the ordering, the `coincide_titulo` flag, and the two aviso fields an agent will encounter in the response. Combined with full routing to sibling tools for every out-of-scope corpus, an agent has everything needed to call it and interpret the result correctly.

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

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

Schema description coverage is 100% and the parameter docs are unusually rich (rows carries the 504/timeout tradeoff, ordenamiento explains invalid-value handling). The description adds almost nothing about individual parameters — it only indirectly reinforces the ordering-by-title behavior. Baseline 3 is correct when the schema does all the work.

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

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

Opens with a specific verb+resource ("Busca LEYES dominicanas en la colección de la Consultoría Jurídica del Poder Ejecutivo") and enumerates the included norm types (leyes, leyes orgánicas, Constitución, resoluciones). It then explicitly carves out what it does NOT cover, which lets an agent separate it from buscar_decretos and buscar_normas_reguladores without opening any schema.

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

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

Gives an explicit use directive ("Úsala EN LUGAR de una búsqueda web") plus negative routing: decretos → buscar_decretos, códigos/resoluciones del Poder Judicial → buscar_doctrina + leer_doctrina, SCJ/CPJ → buscar_normas_reguladores. It even explains a failure mode (searching a code returns hundreds of false positives) so the agent does not misinterpret a bad result set.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing coverage gaps, the `aviso_cobertura` warning that a zero result is not proof of non-existence, the `solo_por_titulo` limitation, and the vigencia semantics (only vigente:true is institution-labeled; null is unknown). It also tells the agent that título/descripción are institution-authored and that the citable text comes from leer_norma_reguladora with the `clave`, which is exactly the caveat needed for a legal-research 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 opening sentence is a ~350-word run-on enumerating every regulator and its document types, largely duplicating the `institucion` enum descriptions verbatim, and it pushes the genuinely critical content (cobertura, aviso_cobertura, vigencia) behind that wall. The warning blocks that follow are well structured and earn their place, but the enumeration is redundant bulk.

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 still explains the return-relevant fields (`total`, `page`, `solo_por_titulo`, `aviso_cobertura`, `vigente`, `clave`) and the handoff to leer_norma_reguladora. Combined with the coverage caveats, an agent has everything needed to query, interpret zeros, and cite 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 `terminos`, `anio`, `page` (50 per page) and the full `institucion` enum. The description adds only the accent-insensitive matching behavior and restates the all-words-at-once and 50-per-page semantics already present in the schema, so it stays at the baseline rather than adding real parameter insight.

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 (normas propias de los órganos reguladores dominicanos), then enumerates the document types per institution so an agent knows exactly what corpus is hit. It explicitly separates itself from buscar_decretos (decretos y reglamentos del Poder Ejecutivo) and buscar_legislacion (leyes), so siblings are distinguishable without opening schemas.

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

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

Gives an explicit positive directive ('Úsala EN LUGAR de una búsqueda web') plus negative routing to the two competing tools for decrees and laws. It also names hard exclusions (SIE y MINERD no están) and partial-coverage cases (SIMV, Junta Monetaria solo una selección), which is the when-not-to-trust-it guidance most tools lack.

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

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

Annotations only say readOnly and openWorld, so the description usefully adds that the counts are the authoritative source of valid filter values and that an unmatched `contiene` returns a "does not exist with that spelling" answer plus near matches instead of a misleading zero. That is real behavioral disclosure beyond the structured fields; only ordering/pagination of the result list is left unspecified.

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?

Core purpose is front-loaded in the first sentence, then parameters are addressed in short, scoped paragraphs. Slightly verbose in the middle paragraph, but each sentence carries information the agent needs.

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

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

For a 5-parameter read-only tool with no output schema, the description conveys enough about the return: values paired with document counts and a spelling-suggestion path on misses. Missing only secondary details such as result ordering or how many values come back by default beyond the schema's `tope`.

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

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

With 100% schema coverage the baseline is 3, and the description earns above it by explaining the semantics of `contiene` (in-facet search with fuzzy fallback) and clarifying that `terminos` and `tribunal` scope the counts to that particular search rather than global counts. `tope` and the enum aliases are left to the schema, which already documents them well.

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?

"Publica el vocabulario REAL de un filtro, con el número de documentos de cada valor" gives a specific verb (publica) plus resource (valores de un filtro) and states the shape of the output. It is unmistakably a facet/vocabulary introspection tool rather than a search, though it never names a sibling to contrast 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 last clause establishes context for use: checking which salas or materias have material "antes de gastar una consulta", which tells the agent this is a cheap pre-flight step before a real search. It stops short of naming the search tool to use afterwards or any explicit when-not-to-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?

Annotations only declare readOnlyHint and openWorldHint; the description adds real context beyond them — the authoritative status of the documents ('la guía que la Sala dice que seguirá, no un criterio jurisprudencial'), the citation rule requiring literal quotes with page numbers read via `pagina` or `desde`/`hasta`, and what each mode returns. It stops short of describing error behavior or how `buscar` composes with `desde`/`hasta`.

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

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

Front-loads the identity of the documents and their scope, then the mode behavior, then the citation warning. Dense but every sentence carries operational information; nothing is 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?

With no output schema and five optional parameters, the description adequately sketches what each mode yields (list with Sala, fecha, and applicability date; PDF text for reads). The only gap is the exact shape of the list response and whether `buscar` can be combined with a page range, which is minor given how well the calling patterns are explained.

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, but the description adds meaning: it clarifies the list-vs-read switch keyed on `id` and, importantly, that only text obtained through `pagina` or `desde`/`hasta` is citable — implying `buscar` hits alone are insufficient. That is semantic guidance the schema does not carry.

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 the specific resource (acuerdos plenos no jurisdiccionales of the Primera and Tercera Sala), enumerates the subject matter they cover (interés casacional, admisibilidad, cuantía, memoriales, plazos), and explicitly distinguishes itself from buscar_jurisprudencia ('No son sentencias, así que buscar_jurisprudencia no los encuentra'). An agent can identify the tool and its scope without opening the schema.

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

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

Gives explicit routing: use buscar_jurisprudencia for sentencias, and additionally search the Sala's sentencias when asserting how it actually rules, because these agreements are guidance rather than binding criteria. It also states the two modes (list without `id`, read with `id`) so the agent knows which call shape to use when.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with a read of an external corpus. It genuinely adds behavior beyond that: the appended 'escrito del recurrente' can be over half the document, the operative reasoning sits under 'Réponse de la Cour' or 'Mais attendu que', and a ficha may arrive without text rather than as an empty decision. However, much of the length is citation etiquette for the agent's answer rather than properties of the tool call itself, so the behavioral payload is diluted.

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

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

Purpose is front-loaded in the first sentence, which is correct. But the body is a stack of four ⚠️ blocks, two of them double-flagged, and a substantial share is post-retrieval citation policy (French verbatim first, marked working translation) rather than anything needed to select or invoke the tool. The emphasis markers multiply visually without adding decision-relevant information.

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

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

There is no output schema, and the description compensates by naming the returned 'bloque_de_cita' with its header, template order, and link, plus the degradation case where no text is served. For a single-resource reader that is close to complete. What is missing is how it chains to the French search tool and what 'ventana' controls.

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 75% and the schema already documents 'modo' (with its enum glosses) and 'buscar' (mandatory in 'buscar' mode, in French). The description adds no meaning to 'modo', 'buscar', or 'ventana' – the window size is undocumented in both places, which is the main remaining gap. Baseline 3 applies since the schema carries most of the load.

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

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

The opening sentence states a specific verb+resource: full text ('texto íntegro') of a French decision, and enumerates what comes with it (ECLI, visas, map of who speaks where). The jurisdiction word 'francesa' separates it from the many sibling 'leer_' tools for Colombia, Spain, Inter-American, etc. It stops short of naming the retrieval sibling (buscar_jurisprudencia_francia) that feeds it.

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

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

Usage is only implied: the tool is the reader for French decisions, and the mode enum values are glossed in the schema, not in the description. There is no explicit 'call this after buscar_jurisprudencia_francia' or 'do not call for RD/Colombian material – use leer_sentencia_colombia' routing, which matters given roughly a dozen sibling readers. The Conseil d'État/Constitutionnel note gestures at an edge case but frames it as output behavior rather than a when-to-use 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is set. The description nonetheless adds substantial behavioral context beyond annotations: the PDF is a Gaceta Oficial excerpt that may contain adjacent decrees, decretos_que_empiezan_aqui marks boundaries, first read is slow (don't retry), and decrees may amend/repeal others. These are valuable, but the emoji warnings crowd out return-shape detail (covered separately by output schema absence).

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

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

Front-loaded with the resource and the six modes, then grouped warnings. Mostly earns its length, though the stacked ⚠️ blocks and repeated emphasis add bulk; a tighter version could convey the same boundaries with less 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 7-parameter tool with no output schema, the description supplies the missing context: what each mode returns, pagination/truncation behavior (hasta recorta y se dice), aviso_cobertura semantics, and citation hygiene. An agent has everything needed to invoke correctly and interpret results.

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 parameters are already documented. The description still adds real semantics: articulo matches the 'Art. N.-' header rather than in-text mentions, buscar is accent/case-insensitive, desde/hasta reads a contiguous range, and the mode-selection logic itself clarifies parameter interaction beyond the flat 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 (leer) and resource (decreto/reglamento del Poder Ejecutivo), scoped to pages of the official PDF from Consultoría Jurídica, and explicitly ties doc_id to buscar_decretos, distinguishing it from that sibling. An agent knows immediately this is the fetch-by-id read tool, not a search 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?

Enumerates all six modes and the exact argument that selects each (estructura, articulo, buscar, desde/hasta, pagina, or bare call = ficha). Adds explicit when-not guidance: don't read a 100-page reglamento whole, use estructura/articulo first and read only the relevant chapter, and when to distrust buscar results via aviso_cobertura.

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?

Beyond readOnlyHint/openWorldHint it discloses latency on first read, the truncation behavior («se recorta y se dice») and, critically, the meaning of aviso_cobertura — a zero means 'not in the pages I scanned'. It even warns about attribution risks via es_cita, autor, es_aparato and aviso_citas, which annotations cannot express. Slight deduction because this is delivered as long policy prose rather than a compact behavioral contract.

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

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

Front-loaded purpose and mode enumeration are good, but the ⚠️ stack is long and partly restates schema text (the 120-page cap appears in both the description and two schema fields), and the citation-etiquette block is agent policy rather than tool-selection information. Density is justified by complexity, but trimming is possible.

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 the description compensates by naming every returned field of consequence — ficha/índice, es_cita, autor, es_aparato, seccion, aviso_citas, donde_aparece, aviso_cobertura — with enough semantics to interpret them correctly. Nothing an agent needs to call or read the result 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 coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: the mutual-exclusion/mode model across eight all-optional params, that `articulo` matches the «Art. N.-» heading and not in-text mentions or the index, and that `entrada` bypasses isbn13 entirely.

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?

Opens with a specific verb+resource+scope: «El texto de una obra de la biblioteca, por páginas, extraído de su PDF oficial», and immediately states the identifier source (isbn13 from buscar_doctrina, clave from articulos_de_revista). An agent can tell this apart from the retrieval siblings without opening the schema.

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

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

Explicitly enumerates five invocation modes and what each returns, plus routing advice: «Empieza por la ficha… Si no trae índice, usa buscar». It also covers the alternative sources of identifiers and a negative case («no reintentes por lentitud»).

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

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

Annotations only declare readOnly and openWorld; the description goes far beyond by disclosing the 120-page cap and truncation behavior, the cold-start latency of the first read ('no reintentes por lentitud'), and the semantics of es_cita / autor / es_aparato / aviso_citas / aviso_cobertura. It even warns that doctrine is not tribunal criteria despite the publisher.

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

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

Front-loaded: purpose, then modes, then warnings, with no filler sentences — each warning carries distinct operational content. It is nonetheless a dense wall of ⚠️ bullets, and the `entrada` sentence is both long and (per the schema) wrong, which costs a point.

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 exists, and the description does the work of explaining the return shape (page numbers, coverage notice, appearance distribution, per-passage attribution fields) — a genuinely complete picture for a paginated reader. The one hole is the phantom `entrada` parameter, which contradicts the strict schema and would break calls if followed.

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?

Adds real meaning beyond the 100%-covered schema: `articulo` matches the 'Art. N.-' header and explicitly not in-text mentions or the index, and the description layers a strategy (ficha → índice → desde/hasta) over the raw params. However, it describes an `entrada` mode for the Diccionario Jurídico that does not exist in the schema (additionalProperties: false), so an agent following it would issue an invalid 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 and resource (leer el texto de una publicación del Centro de Estudios Constitucionales, por páginas, desde su PDF oficial) and immediately ties itself to the search sibling by saying the `slug` comes from buscar_doctrina_constitucional. An agent can distinguish it from buscar_doctrina_constitucional and leer_doctrina without opening any schema.

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

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

Explicitly enumerates the five operating modes and when each applies (ficha first, then index + desde/hasta, and buscar only when there is no index). Adds exclusions and negative guidance — do not cite `buscar` context, do not treat a zero under aviso_cobertura as absence — which is exactly the when/when-not detail the dimension rewards.

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

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

Annotations only say readOnly/openWorld; the description adds real behavioral context beyond them: first read is slow and later reads are cached, do not retry on slowness, oversized ranges get truncated and reported, and some PDFs are image scans with no text (in which case the link is returned). It also states a citation policy distinguishing citable modes (`pagina`, `desde`/`hasta`) from the non-citable `buscar` context.

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 mode list and the three ⚠️ blocks are front-loaded and each carries actionable content. The opening sentence's long enumeration of ~30 regulators is heavy, though it does establish scope; a grouped phrasing would have preserved the meaning at a fraction of the length.

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

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

With 7 optional params, no output schema, and a document corpus that can exceed a hundred pages, the description covers the failure modes an agent would otherwise hit: scan-only PDFs, truncation, latency, and citation validity. Nothing needed to call it correctly or to interpret the result appears to be 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 coverage is 100%, so per-parameter meaning is already documented; the description nevertheless adds the mode model that the flat schema cannot express (which combination of optional params yields ficha vs. outline vs. range, and that `buscar` returns locating context only). It stops short of stating precedence when conflicting modes are combined (e.g., `pagina` plus `desde`), which keeps it off a 5.

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

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

States a concrete verb and resource (leer el texto de una norma, por páginas, extraído del PDF) and enumerates the covered regulators, so the agent knows exactly what corpus this tool serves. It also names the sibling that supplies the required `clave` (buscar_normas_reguladores), making the pairing unmistakable.

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

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

Explicitly defines six modes and the argument combination that selects each (no args = ficha, `estructura`, `articulo`, `buscar`, `desde`/`hasta`, `pagina`), plus a strong when-not: do not read a 100+ page regulation end to end. It also routes the agent forward ('Se pide con la `clave` que devuelve buscar_normas_reguladores'), which is exactly the alternative-selection guidance this dimension rewards.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description goes further by disclosing the actual payload (full text + ECLI + structural map) and flagging that search output is cataloguing, not the ruling's own words. It doesn't discuss length limits or truncation for very long resolutions, which is the remaining behavioral unknown.

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

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

Front-loaded with what is returned, then two dense warnings that each carry operational weight. The trailing 'Doctrina persuasiva en RD' is cryptic and under-explained, the one phrase that doesn't clearly earn 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?

No output schema exists, and the description compensates by describing the returned structure (íntegro + ECLI + mapa). For a 4-parameter read tool with readOnly annotations this is nearly sufficient; only the 'ventana' window and behavior on exceptionally long rulings are left 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 75% and the schema itself documents modo's three values, buscar's conditional requirement and resolucion's accepted formats (STC 52/2026 or internal id). The description adds nothing parameter-specific, and 'ventana' is undocumented in both places. Baseline 3 for high-coverage schemas doing 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 (leer), a precise resource (resolución del Tribunal Constitucional de España), and enumerates what comes back: texto íntegro, ECLI y mapa de Antecedentes/Fundamentos/votos particulares. That distinguishes it from the buscar_* siblings and from the other national leer_* tools without needing the schema.

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

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

The warning 'Sin leer el texto no hay criterio que citar: la síntesis de la búsqueda es catalogación, no palabras del fallo' establishes the workflow position — read this before citing, don't cite search summaries. It stops short of naming the concrete alternatives (buscar_jurisprudencia_espana, resolver_referencia, obtener_texto_completo), so routing is implied rather than 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?

Annotations already establish readOnly and openWorld behavior; the description adds valuable context about what the returned text contains, including salvamentos and aclaraciones, and warns that search metadata is not authoritative. It does not cover error behavior, truncation, or permissions, so it is strong but not exhaustive.

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 purpose is front-loaded and the warnings are compact and relevant to citation behavior. The abbreviation “RD” is somewhat cryptic and could distract, but the description remains efficient overall.

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 no-output-schema tool, the description explains the core return content and citation caveats well. Modes and reference format are left to the schema, and ventana remains unexplained, so it is complete enough but not fully self-contained.

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 description does not explain the parameters; the schema documents sentencia, modo, and buscar, but ventana has only bounds/default and no meaning. With 75% schema description coverage, this is adequate but the description adds no parameter guidance of its own.

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

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

The description states a specific verb and resource: full text of a Colombian Constitutional Court ruling, plus a map of where dissents and clarifications begin. This distinguishes it from the buscar_* siblings by emphasizing full-text reading rather than search-result metadata.

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

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

It clearly warns that the full text must be read before citing a criterion and that search topic/summary text comes from the relatoría, not the Court. It gives strong usage context but does not explicitly name the alternative search sibling or state when not to use this tool.

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 readOnlyHint and openWorldHint already declared, the description adds genuinely useful interpretive context: the Court's actual criterion lives in the consideraciones, text under «Alegatos» belongs to a party, and a voto belongs to a single judge, plus the citation convention with `cita` and paragraph. It does not cover failure behavior (e.g., missing `buscar`, out-of-range pages) or what the map/page output looks like structurally, so it stops short of 5.

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

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

Front-loaded with the core action and then mode-by-mode behavior, followed by a bolded interpretive warning that is genuinely high-value rather than padding. The mode sentences are dense run-ons, and the warning's capitalization and quotes make it slightly harder to parse, but nothing is wasted.

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

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

For a six-parameter, three-mode reader with no output schema, the description does describe the return shape per mode (resolutive points, page map with where each section starts, term snippets, page text), which is the necessary compensation for a missing output schema. The undocumented `ventana` parameter and the absent 'get clave from the search tool first' instruction keep it from being 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 67%, so baseline is 3. The description adds real meaning for `modo`, `buscar` and `paginas` (ten-page ceiling, who a term belongs to), but `ventana` is undocumented in both the schema and the description, and `desde`/`hasta` are only echoed from the schema rather than elaborated.

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 ('Una decisión de la Corte Interamericana por su clave') and then enumerates what each of the three modes returns: resolutive points and a page map, term occurrences with authorship, or up to ten pages. The resource is clearly distinguished from sibling readers such as leer_sentencia_colombia or leer_decision_francia by naming the Inter-American Court 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?

Gives explicit mode-selection guidance: no `modo` for what the Court decided plus the structural map, `modo: "buscar"` for term locations, `modo: "paginas"` for page ranges. The one gap is that it never states the upstream step — that `clave` must first come from buscar_jurisprudencia_interamericana — which is only present in the schema, not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe external read. The description's one addition is what the call yields (PDF link plus cover page), which is genuinely useful since there is no output schema, but it omits access, availability, or failure behavior for older/future months.

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?

Two short sentences with no filler, front-loading the resource and then the return value. Nothing needs to be trimmed.

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, no-output-schema tool, the description covers what it returns and that it is monthly, which is most of what is needed. It still leaves the key semantic link between the fecha argument and month selection unexplained, so an agent could call it with an arbitrary date without knowing whether that is valid.

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 only one parameter, so the ISO date format is already documented in the schema. The description adds nothing about how fecha maps to a monthly bulletin (e.g. whether a mid-month date selects that month's edition), which is the one ambiguity an agent could get wrong.

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 resource and action: a monthly judicial bulletin of the Poder Judicial, returning the PDF link and cover page. It is clear on its own, but it does not distinguish itself from the many buscar_*/leer_* siblings, so an agent cannot tell from the text alone why it would pick this over, say, obtener_texto_completo.

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 and no mention of alternatives, despite 17 sibling tools. The monthly cadence is the only implicit usage signal, and nothing says whether to call this instead of the search tools or in combination with them.

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

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

Annotations declare readOnlyHint/openWorldHint and nothing in the description contradicts them. Beyond that, the description discloses non-obvious behavior: it refuses to return text when the court's holding cannot be delimited, emits per-paragraph `etiquetas` with `citable`/`razon`, returns `null` inside criterio and defers to `senales` as "pistas para comprobar, no veredictos", flags partial reads and instructs to re-call with the same arguments, and adds `pagina` for PDF-sourced readings.

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

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

Front-loading is excellent — the citation hazard is stated before anything else, and the mode semantics follow in descending order of importance. It is nonetheless long, and the two enumerated "formas del error" illustrate the hazard at a length that exceeds what is needed to select or invoke the tool correctly.

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

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

For an 8-parameter, zero-required tool with no output schema, the description covers everything an agent needs: which mode produces what, how to paginate, how to fall back to PDF sources, how to recover from a partial read, and even the shape of the returned citation scaffolding (`bloque_de_cita`, `postura_procesal`, `comprobar`). Nothing material 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains what each `modo` returns and excludes, that `parte` pagination means the judgment is not fully read until all parts are consumed, and that `tc`/`tse` are alternatives to `id` that route to official PDFs. Only `ventana` and `articulo` (norm-oriented, arguably vestigial for a judgment reader) are left entirely to 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?

Opens with a specific verb+resource: "Texto de una sentencia, con su MAPA ESTRUCTURAL". It immediately distinguishes its modalities (criterio/pasaje/mapa/completo/buscar) and its three input paths (id, tc, tse), so an agent knows exactly what it retrieves and can tell it apart from siblings like leer_sentencia_colombia or buscar_jurisprudencia.

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

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

Explicit when-to-use routing: "PARA CITAR, USA modo: criterio", "modo: buscar LOCALIZA un término sin devolver el texto", "modo: mapa da la estructura sin traer el documento", "modo: completo da todo". It even points to the sibling that supplies inputs (resolver_referencia indica `como_leer`; buscar_jurisprudencia_electoral aporta la `clave`) and states the retry rule when `leida: false`.

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

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

Annotations only declare readOnlyHint and openWorldHint, yet the description discloses the full response contract: the `encontrada` / `mismo_numero_y_dia` / `registro_oficial` fields and the three-way `existe` semantics (true / null / false) plus `consultado: false`. It also warns that a registry hit carries secretaría-authored metadata, not text, which is behavior an agent could not infer from annotations or schema.

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

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

Front-loaded with the purpose and the accepted formats, with warnings grouped at the end, so an agent can stop reading early. It is on the long side for a one-parameter tool and leans on caps/emoji emphasis and some repetition, which trims a point.

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 exists, and the description compensates fully: it documents the outcome fields, the disambiguation path for same-number/same-day matches, the registry fallback tri-state, and the follow-up call (`como_leer` → obtener_texto_completo). Nothing an agent needs to act on the result 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 coverage is already 100%, so baseline would be 3-4, but the description goes well beyond 'la referencia tal como aparece citada' by enumerating the accepted literal forms (TC/0437/17, SCJ-PS-22-2005, «núm. 312, 24 de febrero de 2021», «Ley núm. 108-05», «Código Civil, art. 2262») and the requirement to include the sala in classic prose. That directly changes how an agent formats the single input.

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 ('Convierte una referencia citada en el documento al que apunta') and then enumerates exactly which reference families it accepts (TC structured, SCJ modern, classic prose, norms by number or by name, TSE, court numbers). An agent can distinguish this from buscar_legislacion or buscar_jurisprudencia without opening the schema.

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

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

Explicitly names the job ('Sirve para comprobar que un precedente citado existe y es el que se dice') and routes away from siblings: 'sin pasar por buscar_legislacion', 'cómo leer el artículo con leer_doctrina', 'se lee con obtener_texto_completo, con mapa y modo «criterio»'. It also gives a when-not-style warning: don't cite from registry metadata, and how to handle ambiguous classic-prose matches.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description goes far beyond them by explaining the three payload shapes the result can take and what the agent must do in each, including the case where only `nota` exists and the text is unreadable. The closing warning that the court-registered fallo and asunto say WHAT was decided but not WHY is a substantive epistemic constraint that prevents mis-citation.

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

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

Purpose is front-loaded in the first sentence, then the read-mode branches are laid out as short bullets that are each independently actionable, with the caveat isolated behind a warning marker. The dense field enumeration in sentence one buys the agent real orientation and no sentence is filler.

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

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

With no output schema and a single parameter, the description carries the full descriptive burden and does so: it discloses the shape of the returned decisions, the possible readability states, and how to proceed in each. The degraded case (decision issued, text not yet readable) is explicitly handled, which is exactly the gap an agent would otherwise stumble into.

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 parameter, so the schema already documents the NUC format and its origin in buscar_audiencias. The description only echoes 'por su NUC' without adding format, validation, or fallback details beyond the schema — the baseline 3 applies.

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

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

The description states the exact resource returned (the decisions the Poder Judicial registers for a case, keyed by NUC) and enumerates the fields: number, date, type, ruling, court, chamber, plus proceeding status. It also frames the intent ('Sirve para saber si un caso ya se falló'), which distinguishes it from the sibling search tools and positions it as the entry point that feeds obtener_texto_completo.

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 an explicit trigger ('para saber si un caso ya se falló') and routes the agent onward with named alternatives and conditions: use obtener_texto_completo with the `id` when `en_clerk` is present, read the PDF directly when only `pdf` is present. It does not say when to prefer this over related lookups such as buscar_decretos or buscar_jurisprudencia, so it stops short of full when/when-not coverage.

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