Server Quality Checklist

Tool Scores

• plan_tripA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden. It discloses the core comparison behavior and the fact that it returns a cheaper option, but does not elaborate on output format, data sources, assumptions, or limitations. This is adequate but not rich.

  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: two sentences that front-load the core purpose and then provide a direct usage guideline. Every sentence adds value, with no redundant or fluffy content.

  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 tool is relatively simple: three parameters, no output schema, no annotations. The description covers the tool's purpose, its comparison logic, and when to use it, which is sufficient for a basic understanding. It lacks detail on return value structure but does mention 'says which is cheaper,' offering minimal output guidance. This is complete enough given the tool's moderate 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?

  The schema provides 100% coverage with detailed descriptions for all three parameters, so the baseline is 3. The description does not add significant parameter-level meaning beyond what the schema already states; it merely references the multi-country aspect. Therefore, a 3 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's purpose with a specific verb ('work out') and resource ('the cheapest way to stay connected across several countries'). It distinguishes itself from siblings by focusing on multi-country trip cost comparison, contrasting a single regional plan versus per-country local plans, and explicitly says it outputs which is cheaper.

  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 provides a clear usage condition: 'Use this whenever the user names more than one destination.' This gives explicit when-to-use guidance. However, it does not explicitly mention when NOT to use or name alternative tools for single-destination scenarios, so it falls short of a 5.

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

• search_destinationsA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses that it matches by full or partial name and that the purpose is to retrieve a country code, but it does not specify the return format (e.g., a list of countries with codes), behavior for no matches, or any pagination/limitations. This leaves room for inference, making it only minimally viable.

  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 sentences, each serving a distinct role: stating the purpose, giving the when-to-use scenario, and listing alternatives with explicit not-to-use cases. There is no redundant or filler language.

  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 tool with a single parameter and no annotations or output schema, the description covers the core context effectively: what it does, when to use it, and what it returns (implied country codes). It could explicitly state the output structure or edge cases like no results, but the simplicity of the tool makes the current description nearly complete.

  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 schema already describes the query parameter as 'Country name or partial name, for example "jap" or "south kor"', giving 100% coverage. The description repeats the 'full or partial name' concept without adding new semantics, so it does not exceed the baseline for high schema 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's function: 'Find countries CheapereSIM sells eSIM plans for, by full or partial name.' It specifies the verb (find), the resource (countries), and the method (full or partial name), making it distinct from sibling tools that list plans or compare prices.

  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?

  The description provides explicit usage guidance: 'Use this when the user names a place and you need its country code before looking up plans.' It also includes exclusions and alternatives: 'Do not use it to compare prices or list plans: use list_plans for a single country, or plan_trip for several.'

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

• list_plansA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses the 'cheapest first' ordering and the single-country limitation, which are behavioral details not in the schema. However, it does not mention result size limits (the 'limit' param) or potential error behavior, so it is not fully transparent.

  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 compact sentences with no filler. The first sentence states the primary action and ordering; the second gives a conditional alternative. Every word earns its place.

  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 description is sufficient for a simple list tool: it specifies the single-country scope, ordering, and a sibling alternative. While there is no output schema and no mention of pagination or return format, the limited complexity of the operation and full schema parameter coverage make this adequately complete.

  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 already explains all parameters (country, days, limit, min_data_gb). The description adds no extra parameter meaning beyond the single-country scope already reflected in the schema, thus baseline 3 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 uses a specific verb ('List') and resource ('eSIM plans'), scopes to 'one country', and adds ordering ('cheapest first'). It also distinguishes from the sibling tool plan_trip for multi-country trips, making it unambiguous.

  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 states when NOT to use: 'Use plan_trip instead when the user is visiting more than one country.' This provides a clear exclusion and names the alternative tool, giving strong usage guidance.

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

• get_plan_coverageA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses a key behavioral trait: local plans have null group_id and cover only their own country, implying the tool is for regional/global plans. The verb 'List' also implies a read-only operation. It doesn't detail error handling or output format, but for a simple listing tool this 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 sentences, front-loaded with the main purpose, and no extraneous information. Every word earns its place, making it highly efficient.

  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 tool with a single parameter and no output schema, the description is complete: it states what it does, where the input comes from, and an important edge case (local plans). The return type (list of countries) is implied by the purpose statement, so no further detail is needed.

  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 already covers the parameter with 100% description coverage, but the tool description adds value by explaining where the group_id comes from (a plan returned by plan_trip or list_plans) and the null group_id caveat. This goes beyond the schema's basic field 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?

  The description clearly states the tool lists countries covered by a plan, using a specific verb ('List') and resource ('every country a regional or global plan covers'). It distinguishes from sibling tools like list_plans (which lists plans) and search_destinations, making the purpose unambiguous.

  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?

  It explains where to obtain the group_id (from plan_trip or list_plans) and clarifies that local plans with null group_id are not applicable. This gives clear context for when to use the tool, though it doesn't explicitly mention alternatives or exclusions beyond the local plan case.

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

• list_popular_destinationsA
  4.7/5.0
  Behavior4/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 conveys the read-only nature of listing, states what output includes (destinations and starting price), and gives usage constraints. However, it stops short of disclosing details like result limits or exact return format, leaving a minor gap.

  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 concise and well-structured. The first sentence states the action and includes a key detail (starting price); the second sentence provides decision logic with alternatives. No unnecessary words.

  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 tool with no parameters and no output schema, the description is remarkably complete. It explains what the tool does, when to use it, and how it relates to sibling tools, giving an AI agent enough context to invoke it correctly.

  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 tool has zero parameters, so schema coverage is trivially 100%. Per guidelines, a baseline of 4 applies for 0-parameter tools. The description adds context about the tool's scope but no parameter-specific details are needed.

  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 lists popular eSIM destinations with starting prices, using a specific verb ('List') and resource ('destinations'). It distinguishes itself from siblings by specifying when to use it versus alternatives like list_plans and plan_trip.

  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?

  Explicit guidance is provided: use only when the user hasn't named a destination and wants ideas. It directly names alternatives (list_plans for one country, plan_trip for several), giving clear when-to-use and when-not-to-use criteria.

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