Server Quality Checklist

Tool Scores

• obtener_actuaciones_receptorA
  3.7/5.0
  Behavior1/5

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

  The description provides rich behavioral context about empty lists, failure versus empty responses, `discrepancia_fechas`, and `georreferenciado`. However, it directly contradicts the `openWorldHint: true` annotation by asserting a closed-world guarantee: 'Una lista vacía significa que la causa NO tiene actuaciones de receptor, y eso es una respuesta.' Under standard MCP semantics, openWorldHint means absence of a result is not definitive proof of absence, so this is an annotation contradiction.

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

  Conciseness5/5

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

  Although the description is long, it is front-loaded with the core purpose and every paragraph addresses a distinct interpretation or failure risk. The use of code-styled field names and explicit contrasts like 'NO compara' and 'SÓLO en apelaciones...' makes the caveats scannable without wasted words.

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

  Completeness3/5

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

  The description covers failure semantics, field meanings, and jurisdictional differences, and an output schema reduces the need to describe return shapes. However, it is not fully complete or coherent because it gives a definitive empty-list interpretation that conflicts with the `openWorldHint` annotation, leaving an agent with contradictory expectations about whether absence is conclusive.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the input schema already provides detailed, tool-specific semantics for `rol`, `tipo`, `corte`, `tribunal`, and `competencia`. The prose description adds valuable output-field semantics, but it does not add much beyond the schema for the six input parameters, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: it returns 'actuaciones del ministro de fe' with their real diligence date. It also clearly differentiates itself from sibling tools by noting that `obtener_detalle_causa` has a different `diligencias` panel and that this tool supplies a datum the official ebook omits.

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

  Usage Guidelines5/5

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

  The description explicitly ties usage to procedural deadlines ('de los que dependen los plazos procesales') and gives clear when-not-to-use guidance: cobranza dates are not usable and other competencias do not expose these acts. It also names the alternative (`panel diligencias` of `obtener_detalle_causa`) and warns about the not-found failure mode so an agent does not misinterpret an empty list.

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

• listar_cortesA
  4.1/5.0
  Behavior4/5

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

  Beyond the readOnly/idempotent annotations, the description reveals that the code appears nowhere else and that detail responses may return a court name while search requires the code. This explains why the lookup is necessary. It does not describe output shape, but the annotations already cover safety and idempotency.

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

  Conciseness4/5

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

  The main purpose is front-loaded in the first sentence, and the following two sentences each add a distinct, actionable use case. The description is slightly longer than a simple lookup needs, but every sentence earns its place.

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

  Completeness5/5

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

  For a zero-parameter reference tool with strong annotations and an output schema, the description covers both primary and secondary use cases plus cross-tool dependencies. Nothing essential is missing for an agent to decide when to call it and how to use its result.

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

  Parameters4/5

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

  The tool has zero parameters and 100% schema description coverage, so there is no parameter gap for the description to fill. The description confirms it is a no-input global lookup, which is sufficient. Baseline 4 for zero-parameter tools is appropriate.

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

  Purpose4/5

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

  The description states that the tool lists the Courts of Appeals and the code required by other searches, making the resource and output clear. It does not explicitly contrast with sibling listar_tribunales, but the focus on Cortes de Apelaciones makes the distinction reasonably obvious.

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

  Usage Guidelines4/5

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

  The description explicitly instructs the agent to call this before searching by name, RUT, or fecha because the `corte` parameter is mandatory and its value is not available elsewhere. It also covers the Supreme Court appeal-origin case. It gives clear context but does not state when-not-to-use or name alternatives.

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

• obtener_texto_sentenciaA
  4.1/5.0
  Behavior5/5

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

  The description goes well beyond the readOnly/idempotent annotations by disclosing that the tool stops to enumerate multiple sentences, that responses can be about 25,000 characters, that party names and possibly ID numbers are included, and that anonimizada/fuente indicate the version delivered. It also adds a concrete privacy instruction. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose and organized into focused paragraphs. Each paragraph adds meaningful context, though the 'NULO' reference is a bit opaque and there is minor redundancy between 'de una en una' and 'de a una a propósito'.

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

  Completeness4/5

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

  For a tool with a rich schema and annotations, the description covers the essential behavioral cases: multiple sentences, payload size, fallback decision-making without length data, and privacy handling. The only slight gap is that 'NULO' is not explicitly defined, and the relationship to the search sibling could be more direct.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds useful context around the cual parameter and different buscador behaviors, but most of the actual parameter semantics already live in the input schema. The description contributes rationale rather than meaningfully new parameter-level detail.

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

  Purpose4/5

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

  The description clearly states the tool returns the full text of a judgment, one at a time, and distinguishes this from search by noting it is requested separately and deliberately. It does not explicitly name or differentiate from sibling tools like obtener_documento, so it misses the top score slightly.

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

  Usage Guidelines4/5

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

  It gives clear context for when to use the tool: after search, one judgment at a time, and only when the preview or length fields are insufficient. It also explains the special case where the tool stops instead of choosing among multiple sentences. However, it does not explicitly reference sibling tools by name or give a direct when-not-to-use statement against them.

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

• listar_audios_audienciaA
  4.4/5.0
  Behavior5/5

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

  Beyond the readOnly and idempotent annotations, the description discloses key behaviors: audio is deliberately not downloaded, files are split by procedural act, the Fecha column is empty, filenames begin with the RUC, and links expire. This gives the agent operational knowledge it could not infer from annotations alone.

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

  Conciseness4/5

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

  The description is longer than average but well-structured and front-loaded: the core purpose and the key 'NO los trae' are stated first. The extra context about why links should be delivered, why filenames matter, and how links expire all earns its place, though some prose is slightly verbose.

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

  Completeness5/5

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

  The description covers all important operational aspects: what is returned, what is not returned, file splitting, filename semantics, the empty Fecha column, RUC privacy, and link expiration. Given the output schema exists and the annotations cover safety, the definition is complete for an agent to call and interpret the result correctly.

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

  Parameters3/5

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

  Schema coverage for the single parameter is 100%, and the schema already explains that audio_referencia comes from obtener_detalle_causa and can be null. The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: it lists hearing audio files and their download links, explicitly stating it does not fetch the audio itself. It clearly differentiates from any sibling by focusing on the list-and-link behavior rather than retrieving or transcribing content.

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

  Usage Guidelines4/5

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

  The description gives clear context: use it to get the list and links so people can open the audio, not to retrieve or transcribe it. It also provides practical guidance such as not repeating the full filename because it contains the RUC, and re-requesting the list when links expire. It does not name alternative tools explicitly, but the intended usage is clear.

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

• listar_tribunalesA
  4.5/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the description's job is lighter. It adds valuable context: that the tribunal code is not available elsewhere, and that for exhortos the name must be mapped to a code via this tool. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is concise and front-loaded: the first sentence states the purpose, and the following paragraphs give essential usage context without fluff. Every sentence adds value, and the structure aids comprehension.

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

  Completeness5/5

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

  The description is complete for a listing tool. It explains why the tool is needed, when to use it, how it connects to sibling tools, and what data it returns (codes for searches). The presence of an output schema covers the return structure, so nothing essential is missing.

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

  Parameters3/5

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

  The schema descriptions for both parameters are already very detailed (100% coverage), explaining the meaning of `corte` and `competencia` and their constraints. The description does not add further parameter semantics beyond what is in the schema, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: it lists the tribunals of a court along with the codes that searches require. The title reinforces this with the verb 'Listar'. It also differentiates from siblings by explaining its role as a prerequisite for first-instance searches and for following exhortos, making it distinct from direct search tools.

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

  Usage Guidelines5/5

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

  The description explicitly instructs when to call this tool: 'Llamar esto ANTES de buscar en primera instancia' and 'También es la forma de seguir un exhorto'. It also explains the workflow involving `listar_cortes` and how the returned code is used in a subsequent search, giving clear contextual alternatives.

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

• buscar_causa_por_ritA
  4.6/5.0
  Behavior5/5

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

  Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavioral context beyond that: null fields mean that competence does not publish them, the listing excludes history/parties/notifications, and some fields are only populated for specific competences. It also warns that penal has no detalle by design.

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

  Conciseness4/5

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

  The description is long but dense: it front-loads the core purpose and example, then covers output caveats, alternative tools, and edge cases. It could be better structured with shorter paragraphs or bullets, but nearly every sentence earns its place given the tool's complexity.

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

  Completeness5/5

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

  For a tool with seven parameters, multiple competences with different semantics, and nuanced output behavior, the description covers the important edge cases: null meaning, per-competence fields, the detalle alternative, suprema behavior, penal rejection, and tribunal/corte disambiguation. The output schema covers return structure, so nothing an agent needs for correct invocation is missing.

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

  Parameters3/5

  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 seven parameters thoroughly. The description adds contextual examples and calls out how tipo/tribunal/competencia behave differently across competences, but the parameter-heavy lifting is already done in the schema, making the baseline of 3 appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Busca causas por rol en la consulta pública') and a concrete example ('tipo='E', rol=468, anio=2026'). It clearly distinguishes this tool from obtener_detalle_causa and related lookup tools, so an agent can tell what it is for.

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

  Usage Guidelines5/5

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

  It states when this tool is appropriate (searching by RIT) and explicitly routes to obtener_detalle_causa when history, parties, or notifications are needed. It also explains when to use listar_tribunales or listar_cortes to resolve names to codes, and notes the penal exclusion, which is strong usage guidance.

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

• buscar_causa_por_rut_juridicaA
  4.6/5.0
  Behavior5/5

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

  The annotations already mark the tool read-only/idempotent, and the description adds valuable non-obvious behavior: field presence varies by competencia, null means the competence does not publish the field rather than the cause lacking it, and penal has no detail by decision. These details materially affect how results are interpreted and chained.

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

  Conciseness4/5

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

  The description is front-loaded with purpose and use-case, and most sentences carry warnings an agent needs. It loses the top score because the paragraph on per-competencia column publication overlaps with the output schema and makes the definition denser than strictly necessary.

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

  Completeness5/5

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

  Given 7 parameters, 6 competencias, and several sibling interactions, the description covers critical call-routing and result-interpretation concerns: field variation, null semantics, detail-tool chaining, and required filters. With an output schema present, it is not required to restate return values, so no essential gap remains.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies. The prose mostly restates the schema's tribunal/corte requirements rather than adding new syntax or format details; the useful framing that RUT searches must be restricted is already implied by the schema's 'Obligatorio' conditions.

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

  Purpose5/5

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

  The opening sentence names the exact operation ('Busca causas de una persona jurídica por su RUT'), including a specific resource and search key. It further differentiates the tool by stating it is the only route for companies and by explicitly routing history/parties/notifications to obtener_detalle_causa.

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

  Usage Guidelines5/5

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

  The description explicitly says when to use it ('Es la única vía para empresas') and when to switch to obtener_detalle_causa or listar_tribunales/listar_cortes. It also provides competence-specific routing rules: civil/cobranza/laboral/penal require tribunal, apelaciones requires corte and not tribunal, and suprema requires neither.

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

• buscar_jurisprudenciaA
  4.7/5.0
  Behavior5/5

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

  Annotations already mark the tool as read-only, idempotent, and open-world, and the description adds substantial operational detail: `ocultas` vs `no_entregadas`, NULL meaning 'cannot be known' rather than zero, empty-page meaning end-of-results, and facet overlap semantics. This goes far beyond the annotations and gives an agent the behavior needed to interpret results safely.

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

  Conciseness5/5

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

  The description is long but densely packed and well organized into focused paragraphs: purpose, completeness counts, null semantics, pagination, measured scale, field availability, facets, and publication conditions. Every block addresses a real operational risk, and the most important usage directive appears early.

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

  Completeness5/5

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

  Given 11 parameters, no required fields, an output schema, and complex platform-specific quirks, the description is remarkably complete. It covers the open-world caveats, pagination loop, facet filtering pitfalls, per-search field availability, and the meaning of NULL in multiple contexts, so an agent has enough guidance to invoke the tool safely and interpret results.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3; the tool description still adds value by tying `rol`/`anio` to the returned caratulado/fecha/enlace, specifying that `desplazamiento` should advance by `desplazamiento + filas`, and explaining that facet values must be copied from this same search's facets. These additions meaningfully complement the schema rather than merely repeating it.

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

  Purpose5/5

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

  The description opens with a clear verb and resource: 'Busca sentencias en el Buscador Unificado de Fallos.' It further distinguishes the tool by stating its citation-verification role: 'Verifica que una cita existe antes de usarla,' which separates it from the cause-search and document-fetching siblings.

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

  Usage Guidelines4/5

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

  The description gives explicit usage context: use this tool to verify a citation, and it explains when pagination is needed and how to handle incomplete results. It does not explicitly name alternatives or say when not to use it, but the intended role is clear from the verification framing and the mention of deciding whether full text is worth requesting.

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

• obtener_detalle_causaA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate readOnly/openWorld/idempotent, but the description goes far beyond them: it explains the meaningful NULO vs empty-list distinction, notes that fecha_diligencia only exists in civil, says liquidaciones are not sums, reveals that notificaciones includes unserved notices, and explicitly flags that personal data of third parties is returned. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is long, but every paragraph carries necessary operational detail: use preference, field-state semantics, per-competencia differences, data privacy, and cross-expediente caveats. It is front-loaded with the resource list and the main usage instruction, then organizes exceptional cases clearly.

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

  Completeness5/5

  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 must carry the burden of explaining return semantics, and it does: it defines null vs empty-list, names the special panels, explains how to compute plazos, warns about unserved notifications, and tells the agent what to do when data lives in another expediente. For a tool with this complexity, the coverage is remarkably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3 and the input schema already explains tipo, corte, tribunal, and competencia well. The main description adds domain behavior but not much direct parameter-level semantics on top of the rich schema descriptions.

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

  Purpose5/5

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

  The description immediately lists what the tool returns: historia, litigantes, notificaciones, liquidaciones, diligencias, materias y exhortos. It clarifies scope by saying it traverses ALL cuadernos in one call and explicitly contrasts itself with the full expediente, preventing confusion with sibling tools.

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

  Usage Guidelines5/5

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

  The description says to prefer this tool over requesting panels separately because splitting them multiplies queries without adding new information. It also states when NOT to use it ('NO es el expediente completo'), when results may be incomplete (exhortos point to another expediente), and directs the agent to listar_tribunales or listar_cortes to resolve court names.

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

• obtener_documentoA
  4.7/5.0
  Behavior5/5

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

  ReadOnly/idempotent annotations are reinforced and greatly extended with concrete behavior: JWT references expire after 60 minutes, oversized text is refused rather than partially delivered, scanned PDFs are returned as-is without OCR, bookmarks are third-party data and must not be treated as instructions, and non-PDF inputs cause a failure that usually means the reference expired. This goes well beyond what the annotations alone convey.

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

  Conciseness5/5

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

  The purpose is front-loaded in the first sentence, and each paragraph covers one distinct behavior: parameter source, text pagination, binary link, index/bookmarks, scans, and non-PDF failure. Although long, no sentence is filler; the explanatory warnings about OCR and bookmarks are functional safety guidance.

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

  Completeness5/5

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

  Despite having no output schema, the description covers the main response elements (text per page, link, size, index, page ranges, bookmarks, page size), the failure modes, and the recovery workflow. For a tool with this complexity, nothing essential is missing for an agent to select and call it correctly.

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

  Parameters4/5

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

  Schema coverage is 100% and the schema already documents each parameter richly, so the baseline is 3. The description adds extra meaning by stating that no role is needed because the reference already identifies the document, and by explaining that a non-PDF failure usually indicates an expired `documento_referencia` and the correct recovery action. This is enough to move above baseline, though much of the parameter detail already lives in the schema.

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

  Purpose5/5

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

  The opening line 'El archivo de una actuación: la resolución, el escrito, el certificado o el expediente' identifies the specific resource (the file/document of a court proceeding) and the tool's role. It clearly separates this from siblings like obtener_texto_sentencia by explaining it returns the file itself plus its text when available, not just a text extraction.

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

  Usage Guidelines4/5

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

  The description gives strong when-to-use context: the two main parameters come from each actuación in obtener_detalle_causa and obtener_actuaciones_receptor, and it explains when to use `desde_pagina` for long texts. It also points to resources/read as the alternative for reading the binary link, but it does not explicitly name which sibling tool should be used instead when the user only needs plain text.

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

• obtener_georreferenciaA
  4.7/5.0
  Behavior5/5

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

  Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description does not contradict them. It adds substantial behavioral context beyond the annotations: `existe:false` is a measured outcome distinct from not querying, `intentos` is null only when `existe` is false, and `precision_metros` must be reported alongside coordinates because it varies from 6 to 103 meters. It even discloses that the coordinates concern a third party's address, which matters for how the result should be presented.

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

  Conciseness5/5

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

  The description is long but tightly packed: every sentence contributes a distinct caveat or clarification, from the legal basis to the one-request-per-act rule to the measured precision ranges. It is front-loaded with a clear one-line purpose and then proceeds in a logical order through source, usage, failure semantics, and reporting obligations. No filler or repetition of the schema is present.

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

  Completeness5/5

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

  The output schema exists, but the description goes further and explains the meaning and reliability of key output fields (`existe`, `intentos`, `precision_metros`) that an agent must understand to use the response correctly. It covers failure cases, rate-of-request concerns, data provenance, and privacy-sensitive handling. For a tool with this complexity, nothing important for invocation or interpretation is missing.

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

  Parameters3/5

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

  Schema coverage is 100%, and both parameters have meaningful descriptions in the schema; the description adds no new information about `competencia` and mostly restates the `georreferencia_referencia` origin already documented in the schema. The rich caveats in the description concern output fields and usage policy, not parameter semantics. A baseline 3 is therefore appropriate.

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

  Purpose5/5

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

  The opening line states exactly what the tool reports: where and when the minister of faith (ministro de fe) recorded performing a diligence. The description further distinguishes this record from the `hora_diligencia` field in the actuaciones, making its scope precise even without reading the schema. The name and title agree with the described resource.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when not to rely on this data ('NO reemplaza a `fecha_diligencia`') and to report discrepancies rather than choose between values. It also warns that each request is one per actuación and that requesting for all actuaciones multiplies queries, so only the relevant one should be requested. This is strong when/when-not guidance, even though it doesn't name a sibling tool.

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

• buscar_causa_por_fechaA
  4.8/5.0
  Behavior5/5

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

  Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral detail: competencia-specific fields, null meaning absence of publication rather than absence of data, absence of history/partes/notifications, pagination failure instead of silent truncation, and the penal no-detail decision. This goes well beyond the safety profile provided by annotations.

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

  Conciseness4/5

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

  The description is long but organized into thematic paragraphs that each carry useful information. There is minor fluff such as 'Es la cuarta búsqueda que la plataforma ofrece' and the aside 'que existe y se ve bien', but overall the structure makes the dense content navigable.

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

  Completeness5/5

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

  Given the tool's complexity, the presence of an output schema, and rich annotations, the description is complete: it covers invocation rules, result semantics, null behavior, pagination limits, and the path to obtener_detalle_causa. Nothing material needed to call and interpret this tool correctly is missing.

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

  Parameters4/5

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

  The input schema already has 100% coverage and detailed descriptions, so the baseline is 3. The tool description adds meaningful cross-parameter context: which competencias require tribunal versus corte, that suprema requires neither, and how to resolve tribunal/corte names for the detail call. Some of this overlaps with the schema, but the operational framing adds value.

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

  Purpose5/5

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

  The description clearly identifies the resource ('causas ingresadas en un rango de fechas') and the filter being applied, aided by the title's explicit verb. It also distinguishes this tool from sibling searches by explaining the unique scenario it answers ('qué ingresó contra esta empresa esta semana' knowing the tribunal but not the rol).

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: date searches must be bounded, and the required bound depends on competencia. It names alternatives such as obtener_detalle_causa and explains when to use listar_tribunales/listar_cortes, while also noting that rol searches do not require bounds.

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

• obtener_anexos_escritoA
  4.9/5.0
  Behavior5/5

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

  Beyond the read-only/idempotent annotations, the description reveals important behavior: looking only at `Doc.` can produce a false-complete result, the tool returns location references rather than file contents, and null fields mean the panel does not publish that column rather than that the data is missing. It also warns that panels differ across competencias, with specific examples for civil and suprema. No contradiction with the annotations exists.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place: purpose, critical caveat about hidden annexes, request cost, output semantics, and cross-competencia schema differences are all covered without fluff. The core purpose is front-loaded in the first line.

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

  Completeness5/5

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

  For a tool with rich schema descriptions, an output schema, and safety annotations, the description supplies the remaining context an agent needs: when to use it, what it actually returns, how to use those results with `obtener_documento`, and how to interpret nulls across competencias. Nothing essential is missing.

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

  Parameters4/5

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

  The input schema already documents all three parameters thoroughly, so the baseline is 3. The description adds value by explaining the underlying two-column model and why `anexo_ruta`/`anexo_referencia` can be null depending on the panel and whether the folio offers annexes. This context helps an agent interpret parameter values correctly in edge cases.

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

  Purpose5/5

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

  The description names a precise verb and resource: it retrieves the documents that accompanied a written submission, explicitly framing them as a channel distinct from the resolution. It also differentiates itself from the sibling `obtener_documento` by clarifying that this tool returns the references needed to fetch each annex, not the annex itself.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: query this tool when an actuación has `tiene_anexo: true`, and request only the specific folio of interest, never a sweeping scan. It also names the alternative (`obtener_documento`) for actually retrieving the annex once you have the references.

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

• buscar_causa_por_nombreA
  5/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent annotations, the description discloses accent-sensitive matching, the tool's fusion of both accent spellings, the failure mode when `paginas` is exceeded, the meaning of null values for different competencias, and the fact that penal has no detalle by decision. These are non-obvious platform behaviors an agent must know before calling the tool.

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

  Conciseness5/5

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

  The description is long but every paragraph earns its place: purpose, name-field requirement, accent warning, field/null semantics, detail-routing, and scoping rules. It is front-loaded with the core purpose and organized into coherent blocks. Despite the density, there is no filler.

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

  Completeness5/5

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

  For a complex 8-parameter search with zero required fields in the schema, the description resolves the most dangerous ambiguities: minimum name fields, accent behavior, pagination failure, per-competencia scoping, and routing to detail/search siblings. Since an output schema exists, return-value documentation is not required. Nothing essential is missing.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds the critical rule that at least two of the three name parameters are required and that `anio` does not count toward that minimum. It also adds competition-dependent semantics for `tribunal` and `corte`, and explains that `paginas` over the cap causes failure rather than silent truncation. This goes well beyond the schema's field descriptions.

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

  Purpose5/5

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

  The opening line 'Busca causas por nombre de litigante' names the verb, resource, and search axis. It also differentiates from siblings by stating that history, partes, and notificaciones belong to `obtener_detalle_causa`. Even the grouping with 'por RUT y por fecha' clarifies that this is the name-based sibling.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when to use `obtener_detalle_causa` instead, including the fields to repeat, and when to use `listar_tribunales` or `listar_cortes` to resolve codes. It also explains per-competencia scoping requirements for `tribunal` and `corte`, including that apelaciones rejects tribunal and suprema requires neither. This is direct, alternative-aware usage guidance.

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