Server Quality Checklist

Tool Scores

• search_awardsA
  3.5/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. It indicates a read-only search but does not disclose error handling, rate limits, or any behavioral nuances beyond parameter descriptions.

  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 efficiently structured: a clear one-sentence purpose, a requirement line, and a bulleted parameter list. No 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 purpose and parameter semantics but lacks examples, error scenarios, or explicit behavioral details. An existing output schema reduces the need to describe return values, but the description could be more thorough for a 9-parameter tool.

  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 description provides brief one-liners for each of the 9 parameters (e.g., 'cpv: CPV code filter'), adding meaning beyond the schema's titles and types. However, it lacks details like formats or allowed values, and schema coverage is 0%.

  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 it searches for award notices (who won which public contract, for how much), distinguishing it from sibling tools like search_tenders (tenders) and winner_intel (likely winner intelligence).

  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 mentions a prerequisite (Starter tier or above) but does not explicitly guide when to use this tool vs. alternatives or exclude cases. Usage is implied but not fully delineated.

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

• search_tendersA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It explains the paginated return format and non-destructive nature implicitly, but does not disclose rate limits, authentication requirements, or other behavioral constraints, meeting only minimal adequacy.

  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 concisely structured with a brief introductory line, followed by a clear bullet-point list of parameters and a final line about the return value. Every sentence adds value, with no repetition or fluff.

  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 11 parameters, no annotations, and an output schema, the description adequately covers the input semantics and return structure. However, it lacks examples, error handling, or edge-case behavior, which would make it fully complete.

  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?

  Schema coverage is 0%, so the description must compensate. It provides detailed, human-readable explanations for all 11 parameters (e.g., 'CPV classification code (e.g. "72000000" for IT services)'), adding significant meaning beyond the schema's type and name information.

  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 searches for public procurement tenders from specific sources (BOAMP and TED). It uses a specific verb 'search' and resource 'tenders', distinguishing it from sibling tools like 'search_awards' and 'winner_intel'.

  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 parameter details but no explicit guidance on when to use this tool versus alternatives like search_awards or winner_intel. It does not mention conditions, prerequisites, or exclusions, leaving usage inference implied.

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

• winner_intelA
  4.2/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. States Pro tier requirement (authorization). Does not mention rate limits, response size, or mutation behavior, but it is clearly a read-only aggregation. Output schema covers return format, so that is acceptable.

  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?

  Two sentences in first paragraph plus a bulleted arg list. No fluff, front-loaded with core purpose, then usage condition, example, and parameters.

  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?

  Tool is simple; description covers purpose, parameters, and authorization. Output schema handles return values. Adequate for an aggregation tool with few parameters.

  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 description adds explanations for all four parameters (cpv, region, year, limit) including default and max for limit. This adds value beyond the schema's type/default fields.

  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?

  Clearly states it provides aggregated winner statistics (top companies by contract count and total amount). The example query 'which companies win IT contracts in Occitanie in 2025?' makes purpose immediately understandable. Distinguishes from siblings (search_awards, search_tenders) by being an aggregation tool rather than 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.

  Usage Guidelines4/5

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

  Mentions 'Requires Pro tier' (precondition) and gives a usage example. Does not explicitly contrast with siblings, but the nature of the tool (aggregated statistics vs. individual searches) is implied.

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

• meA
  4.7/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses the return values and implies a read-only operation. Could mention authentication failure behavior but is adequate.

  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?

  Two concise sentences front-load the purpose and add usage guidance without waste.

  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?

  With zero parameters and an output schema, the description fully covers what the tool does and when to use it.

  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?

  No parameters exist, so baseline 4 applies. Description adds no parameter info, which 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 returns the authenticated key's tier, quota remaining, and available features, distinguishing it from sibling tools like search_awards.

  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?

  Explicitly advises using it to check quota before launching many calls or to pick a tier-appropriate strategy, providing clear use context.

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