Server Quality Checklist

Tool Scores

• get_indicator_dataB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by noting pagination and annual frequency, but most constraints it mentions ('up to 20 countries', 'bounded year range') merely repeat what the schema already enforces through maxItems and min/max values.

  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 a single, front-loaded sentence that wastes no words and immediately communicates the core action and primary constraints. It loses a point for using 'bounded year range' where something like 'inclusive startYear/endYear range' would be more precise, but overall it is concise and readable.

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

  Completeness2/5

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

  Despite having an output schema, the tool has 6 parameters with 0% schema coverage and the description leaves out essential invocation details such as what an 'indicator' is, how countries should be formatted, and how pagination behaves. It also provides no routing to sibling tools. The description is too sparse to fully enable correct use without external knowledge.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only broadly refers to countries and a year range. It does not explain the indicator format, country code pattern, page/pageSize defaults, or whether startYear/endYear are inclusive. This is inadequate for a 6-parameter tool with zero 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 uses a specific verb ('Get') and a specific resource ('indicator time series'), and adds key scoping details: paginated, annual, up to 20 countries, and a bounded year range. This distinguishes it from siblings like get_indicator_metadata (metadata vs data) and find_countries (country lookup vs data retrieval).

  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 provides no explicit guidance on when to use this tool instead of its siblings, such as compare_countries or get_indicator_metadata. There is no 'when to use', 'when not to use', or mention of alternatives. The intended selection context is only implied by the tool's name and the sibling list.

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

• get_country_profileB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'latest' qualifier, but does not disclose behavior around missing data, response completeness, or any open-world caveats, so it adds only moderate value 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?

  The description is a single, front-loaded sentence that names the action, resource, and included data without wasted words. It is efficiently structured and easy to scan.

  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 single-parameter, read-only lookup with a robust output schema and clear annotations, the description is largely sufficient. The main gap is the lack of explicit country-code format guidance, but the schema's regex pattern partially mitigates this.

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

  Parameters2/5

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

  With 0% schema description coverage, the description needed to explain the 'country' parameter, but it makes no mention of it. The property name and regex pattern imply an ISO-style code, yet there is no explicit statement that the value should be a two- or three-letter country code, nor any example or format guidance.

  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 a specific action ('Get') and a specific resource ('country profile'), and enumerates the exact data returned: metadata plus GDP, growth, population, inflation, and unemployment. It conveys the aggregate nature of this tool versus single-indicator siblings, but it does not explicitly name any sibling to reinforce differentiation.

  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 when to use the tool: whenever a caller needs a country's metadata plus a set of current economic indicators. However, it provides no explicit guidance about when to prefer get_indicator_data, compare_countries, or find_countries instead, so the sibling selection logic is left to inference.

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

• find_countriesA
  3.5/5.0
  Behavior3/5

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

  Annotations already disclose that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat these. It adds that the tool returns country codes, but it does not explain behavior around partial matches, aggregate handling, or result limits. This is acceptable but minimal given the annotation coverage.

  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 a single efficient sentence with no filler and places the core purpose first. It is concise and easy to scan, though it misses an opportunity to clarify a couple of ambiguous parameters without becoming bloated.

  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 output schema covers return values, and annotations cover safety, so the main gap is parameter semantics. The description is adequate for a simple search tool but leaves includeAggregates and pagination/limit behavior ambiguous, which an agent may need when invoking the tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must carry parameter meaning. It conveys that query relates to name, plus region and incomeLevel, but it leaves limit and includeAggregates completely unexplained. With five parameters, this is insufficient.

  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 ('find'), a clear resource ('World Bank country codes'), and the available search dimensions ('by name, region, or income level'). This clearly distinguishes it from sibling tools focused on indicators, profiles, or comparisons.

  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 when to use the tool: whenever an agent needs country codes filtered by name, region, or income level. However, it provides no explicit contrast with siblings such as get_country_profile or compare_countries, leaving some routing ambiguity.

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

• compare_countriesA
  3.7/5.0
  Behavior3/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, so the description's safety burden is low. It adds a useful behavioral detail by clarifying that the comparison uses the latest non-empty value, but it does not explain edge cases like countries with no data or ordering of 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 a single, tight sentence with no filler. It front-loads the action and includes the most important constraints, making it highly scannable.

  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?

  The read-only and idempotent annotations cover safety, and an output schema presumably documents the return structure. The main missing piece is explicit guidance on alternative tools, but for a simple two-parameter read-only comparison, the definition is reasonably complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must carry parameter meaning, but it only restates 'indicator' and '2 to 20 countries' without explaining formats, code conventions, or value domains. The schema regexes help, but the description adds little beyond what parameter names already imply.

  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?

  Description uses a specific verb ('Compare') and clearly defines scope: 'latest non-empty value for one indicator across 2 to 20 countries.' This distinguishes it from siblings like get_country_profile or get_indicator_data, which imply different operation shapes.

  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 context via 'across 2 to 20 countries' and 'one indicator,' but it never explicitly contrasts this tool with siblings such as get_indicator_data or find_countries. No when-not-to-use guidance is given, so an agent would need to infer routing.

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

• get_indicator_metadataA
  4.1/5.0
  Behavior3/5

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

  Annotations already provide rich behavioral signals (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false). The description adds only the exact-match requirement and lists the returned fields, which is useful but not extensive. 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 a single, front-loaded sentence with no filler. Every word adds meaning: verb, returned content, and the exact-match qualifier are all 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?

  For a simple, read-only, one-parameter metadata lookup with an output schema and safety annotations, the description is complete. An agent has enough information to invoke it correctly without needing additional behavioral or return details.

  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 description coverage is 0%, so the description must carry the meaning of the 'indicator' parameter. It does this by clarifying that the value is an exact World Bank indicator code, which is sufficient for a single, intuitively named parameter.

  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 uses a specific verb ('Get') and names concrete return facets ('definition, source, and topics'), scoped to an exact World Bank indicator code. This clearly distinguishes metadata retrieval from the sibling get_indicator_data tool, which implies data values.

  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 usage context is implied by the tool name and description—use this when you need metadata rather than data series—but it does not explicitly state when to prefer this tool over alternatives like get_indicator_data or get_country_profile. There is no when-not or alternative routing guidance.

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