Server Quality Checklist

Tool Scores

• search_enrichedA
  3.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry the full burden. It discloses credit cost (1 credit), global scope, output format (10 matches with specific fields), and AI intelligence used. It lacks details on idempotency or error handling, but for a search tool these are not critical.

  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 moderately sized, front-loaded with the tool's purpose, then lists output specifics, cost, scope, and follow-up instructions. Every sentence adds value and is well-structured without repetition.

  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 no output schema, the description adequately describes the output format (10 matches, fields). It also explains the next step (get_opportunity) and cost. It does not mention what happens if no matches are found, but overall is sufficiently complete for a search tool with one parameter.

  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 single parameter 'query' has full schema description. The tool description adds semantic guidance: 'Include any country, region, or sector context directly in the description. More detail = better matches.' This adds value beyond the schema by advising on detail and context inclusion.

  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 is a government procurement search tool that returns a ranked summary of 10 matches with specific fields. It names sibling 'get_opportunity' for follow-up, but does not explicitly distinguish from sibling 'search_opportunities', so it is somewhat clear but not fully differentiated.

  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?

  The description advises using get_opportunity after reviewing the summary, but does not provide explicit guidance on when to use this tool versus the alternative 'search_opportunities', nor does it describe any prerequisites or exclusions.

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

• check_creditsA
  4.1/5.0
  Behavior3/5

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

  No annotations exist, so description carries burden. Describes a read-only operation but does not disclose if authentication is needed, real-time nature, or potential side effects. Adequate but incomplete.

  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-loaded with the core action being 'check your credit balance'. Every sentence adds value; 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?

  Tool is simple with no parameters, but lacks output description. Given no output schema, description could mention what the balance return looks like (e.g., integer, message). Somewhat incomplete.

  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 (100% schema coverage), so baseline is 4. Description adds no parameter info, which is appropriate as there are none.

  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 purpose as checking credit balance, with specific verb 'check' and resource 'credit balance'. It distinguishes from sibling tools which are search/get operations.

  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 about when credits are used (enriched searches) and that other actions are free, implying the tool should be used to check balance before enriched searches. Lacks explicit when-not-to-use but context is strong.

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

• get_opportunityA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses cost behavior but does not explicitly address idempotency, side effects, or error conditions. As a simple get, it is minimally 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?

  Three concise sentences: purpose, returns, and prerequisite/cost. No wasted words, well-structured.

  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 no output schema, the description lists all return fields (strategic fit memo, etc.) and states the data source (last enriched search). This provides sufficient context for the agent.

  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 schema already describes the number parameter. The description adds no new detail beyond the schema, earning the baseline score.

  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 action ('Get full details for a specific opportunity') and the resource ('from the last enriched search'). It lists return fields, distinguishing it from siblings like search_enriched which performs the search.

  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?

  Explicitly states the prerequisite ('You must run search_enriched first') and cost ('FREE - no extra credit cost'). However, it doesn't compare to search_opportunities or mention when not to use.

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

• search_opportunitiesA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses result limit (10 matches), free cost, and global search. Does not explicitly state read-only behavior, but search operation implies no side effects.

  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 sentences with no wasted words. Front-loads purpose, then adds key usage guidance and differentiating details.

  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?

  Single parameter, no output schema, yet description covers what it returns, limits, cost, scope, and relationship to sibling tool. Complete for the tool's complexity.

  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% with a detailed description. The tool description does not add significant meaning beyond the schema; it reiterates context inclusion advice already in the schema description.

  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?

  Explicitly states it searches government procurement opportunities worldwide, lists returned fields, and distinguishes from sibling tool search_enriched by noting free usage and global search.

  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?

  Clearly advises use for initial discovery before committing credits to enriched search, implying when to switch to search_enriched. Provides context on free usage and global scope.

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