Server Quality Checklist

Tool Scores

• eventos_financierosB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavioral traits (e.g., read-only, authentication needs). It only states the basic function, missing details about side effects, rate limits, or required permissions.

  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?

  Efficient two-sentence description with an Args list. No superfluous text, front-loaded with purpose, and clearly structured.

  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?

  Adequate for a simple retrieval tool with well-documented parameters, but missing output description and usage context given no annotations or output schema.

  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 0%, but the description compensates by explaining both parameters (dias as backward window, max_eventos as max groups) with defaults. Adds value beyond the schema which only has names and defaults.

  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 it retrieves recent financial events (liquidaciones, comisiones, fees), providing a specific verb and resource. It distinguishes from sibling tools like inventory and sales summary, though does not explicitly contrast.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus siblings or when not to use it. Lacks context about prerequisites or typical use cases.

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

• inventarioA
  3.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it returns inventory levels and mentions a max_items parameter (default 50), but does not describe side effects, read-only nature, authentication needs, or any limitations.

  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 extremely concise: one sentence for the purpose and one line for the parameter. No redundant words, efficiently 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?

  Given the low complexity (1 parameter, no output schema, no nested objects), the description covers the essential purpose and parameter. It could briefly mention the return format (e.g., list of SKU numbers with levels) but is largely sufficient for an agent to understand the tool's function.

  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?

  The description explicitly explains the only parameter 'max_items' as 'máximo de SKUs a devolver (default 50)'. Since the input schema has 0% description coverage, the description fully compensates by adding clear meaning beyond the schema's type and default.

  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 'Niveles de inventario FBA por SKU en el marketplace actual' clearly states the verb ('provides'), resource ('inventory levels'), and scope ('by SKU in the current marketplace'). It is distinct from siblings like 'pedidos_recientes' (recent orders) and 'resumen_ventas' (sales summary).

  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?

  Usage is implied from the purpose (checking current inventory levels), but no explicit when-to-use or alternatives are given. The sibling names provide context but the description itself offers no comparative guidance.

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

• pedidos_recientesA
  4/5.0
  Behavior4/5

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

  The verb 'Lista' implies a read-only operation, and no destructive behavior is indicated. However, without annotations, the description does not explicitly state that the tool does not modify data, but the intent is clear.

  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 extremely concise, using only three short lines to convey purpose and parameter details. No unnecessary words are present, and the docstring format is clean.

  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?

  Despite being concise, the description lacks information about the output format (fields in each order), ordering, or pagination. With no output schema, more detail on return structure would improve completeness.

  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?

  The description fully explains both parameters: 'horas' as a backward window in hours (default 24) and 'max_pedidos' as maximum orders to return (default 50). Since the input schema has 0% description coverage, the description compensates completely.

  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 'Lista los pedidos de las últimas N horas' (lists orders of the last N hours), specifying a verb and resource with a time window. It distinguishes from siblings like 'inventario' (inventory) and 'resumen_ventas' (sales summary) by focusing on recent orders.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or scenarios where sibling tools would be more appropriate.

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

• resumen_ventasA
  4.1/5.0
  Behavior3/5

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

  No annotations provided, so description carries the burden. It implies a read-only operation by describing a summary, but does not explicitly state behavioral traits like side effects, idempotency, or permissions.

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

  Conciseness5/5

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

  Extremely concise: one-line summary plus two parameter descriptions. No redundant information, well 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?

  Given low complexity (2 optional parameters, no output schema), the description covers parameters well. Missing details on output structure or exact value formatting, but sufficient for basic usage.

  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?

  The description explains both parameters (dias and granularidad) with clear meaning, defaults, and allowed values for granularidad, fully compensating for the 0% schema description coverage.

  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 provides an aggregated sales summary by period, covering importe, pedidos, unidades. This is distinct from sibling tools like eventos_financieros (financial events) and pedidos_recientes (recent orders).

  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 usage for sales summaries but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria.

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