Server Quality Checklist

Tool Scores

• buscar_causa_por_nombreB
  3.2/5.0
  Behavior2/5

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

  Annotations already declare read-only, open-world, and idempotent behavior. The description adds the two-name-field requirement and the year exclusion, but it also introduces a false behavioral constraint about requiring a tribunal. This false claim undermines transparency and is contradicted by 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.

  Conciseness4/5

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

  The description is compact and front-loaded with the main purpose. However, the inclusion of a false statement about tribunal being required is a content error, though it doesn't affect the structural conciseness. It is still appropriately sized.

  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?

  Given the 8-parameter schema with 100% description coverage and an output schema, the description does not need to restate every parameter. It covers the essential name-field constraint but misstates the tribunal requirement. It also does not mention the pagination failure behavior, though that is documented in the schema. The misleading tribunal claim is a significant completeness gap.

  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 baseline is 3. The description adds the cross-parameter rule that at least two of the three name fields are required and that anio does not count toward that minimum. This is valuable semantic context not present in the individual parameter 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 states 'Busca causas por nombre de litigante', which is a specific verb+resource that clearly distinguishes this tool from siblings like buscar_causa_por_rit or buscar_jurisprudencia. The purpose is unambiguous.

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

  Usage Guidelines1/5

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

  The description provides useful guidance about requiring at least two name fields and that the year does not count, but it also states 'Exige además indicar el tribunal', which directly contradicts the schema's tribunal parameter that says 'Omitir para buscar en todos'. This is misleading and could cause incorrect usage.

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

• buscar_causa_por_ritB
  3.4/5.0
  Behavior2/5

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

  Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds only 'consulta pública' and an example, but does not disclose tool-specific behaviors such as failure modes, pagination limits, or other constraints. The schema includes a pagination warning, but that is structured data, not part of the description.

  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 consists of one concise sentence followed by an example, immediately communicating the tool's purpose and usage. Every word earns its place, with no repetition of schema or annotation information.

  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?

  Despite having 7 parameters, the rich schema and annotations provide most of the necessary context. The description states purpose and gives an example, which is sufficient for an agent to select and invoke the tool, especially given the sibling tool names. A brief note on when to use alternatives would improve it, but the current combination is adequate.

  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%, with thorough descriptions for each parameter, including warnings about 'corte' and 'paginas'. The description's example provides a concrete illustration of parameter usage but does not add semantic meaning beyond what the schema already offers, meeting the baseline for high coverage.

  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 'Busca causas por rol en la consulta pública' clearly states a specific verb (searches) and resource (causas by rol), with an example that illustrates the parameter values. The 'por rol' distinguishes it from sibling tools like buscar_causa_por_nombre, but the description does not explicitly compare against those alternatives.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when you have a rol, and the example shows how to construct the search. However, it does not explicitly state when to use this tool over siblings (e.g., when you have a name or RUT) or any exclusions, leaving usage guidance implied.

  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
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context about companies lacking Clave Única, but it does not disclose failure modes or pagination behavior, and the erroneous tribunal requirement reduces confidence.

  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 very short and front-loaded, with the core purpose in the first sentence and a concise rationale for companies. The only flaw is the misleading 'Exige indicar el tribunal' sentence, which prevents a perfect score.

  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 rich input schema and output schema cover the technical details, and the description supplies the key use-case context for legal entities. However, the false statement about needing a tribunal leaves the agent with conflicting guidance about an important optional parameter, so the description is not fully reliable.

  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%, with each parameter well-documented (e.g., rut format, corte false negatives, paginas failure behavior), so the baseline of 3 applies. The description itself adds no parameter detail and actually contradicts the schema by implying tribunal is required.

  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 'Busca causas de una persona jurídica por su RUT', a specific verb+resource+scope statement that clearly identifies what the tool does. This distinguishes it from sibling tools like buscar_causa_por_rit and buscar_causa_por_nombre.

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

  Usage Guidelines3/5

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

  The description provides clear context for when to use the tool: it is 'la única vía para empresas' and explains why they do not appear in 'Mis Causas'. However, it incorrectly states 'Exige indicar el tribunal' while the schema marks tribunal as optional with default null, which is a misleading usage instruction.

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

• obtener_actuaciones_receptorA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context about the returned field ('fecha_diligencia' vs 'fecha_registro') and the data source (ebook omission), which goes beyond the annotations.

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

  Conciseness5/5

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

  Three short, information-dense sentences: one names the resource, one explains its significance, one gives a precise output directive. No wasted words, and the key instruction is front-loaded.

  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?

  With a rich input schema and an output schema present, the description doesn't need to repeat field details. It adds the missing context about why this tool is important (procedural deadlines) and which field to rely on, making it sufficiently complete for the tool's purpose.

  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 fully documents all parameters. The description does not add additional parameter meanings, staying at the baseline of 3.

  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 identifies the resource ('actuaciones del ministro de fe') and the key behavior (returning 'fecha_diligencia' rather than 'fecha_registro'). It distinguishes from sibling search tools by focusing on a specific record type, though it lacks an explicit verb like 'obtener' in the description itself.

  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?

  Provides clear context for when to use the tool: when you need the real diligence date for procedural deadlines, which the official ebook omits. It does not explicitly name alternative sibling tools or mention when not to use it, but the context implies the appropriate scenario.

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

• buscar_jurisprudenciaA
  4.6/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds valuable behavioral context: it explains what fields are returned when providing rol/anio, and crucially discloses the 'ocultas' field semantics—if greater than zero, the list is a subset and absence cannot be interpreted as definite missing. This is rich, non-obvious behavior directly relevant to using results.

  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 three short, purposeful paragraphs. The first sentence states the main function, the second gives a concrete usage example, and the third warns about a surprising result field. No filler; front-loaded with the most important information.

  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?

  Given 8 optional parameters and a rich output schema, the description focuses on the most important use case (citation verification) and the key caveat (ocultas). It doesn't enumerate all filtering options, but those are already in the schema. The description adds enough context for an agent to understand when and how to use the tool effectively.

  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 schema covers all 8 parameters with descriptions, so baseline is 3. The description adds extra meaning by explaining how 'rol' and 'anio' combine to fetch a specific ruling and what output to expect. This elevates beyond the schema's minimal per-parameter 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 clearly states the tool's verb and resource: 'Busca sentencias de la Corte Suprema en el Buscador Unificado de Fallos.' It distinguishes itself from sibling tools (which search 'causas') by specifying 'sentencias' and provides a concrete use case (verifying a citation).

  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 says the tool is for verifying a citation before using it, and specifically mentions giving 'rol' and 'anio' to retrieve the ruling. While it doesn't name alternatives, the sibling context makes it clear this is for jurisprudence ('sentencias') vs. causes. This is clear contextual guidance but not explicit exclusionary guidance.

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