Server Quality Checklist

Tool Scores

• find-placeA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It describes the tool's behavior well: it accepts various location identifiers and returns a list of matching places with details and coordinates. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, which would be helpful for a tool with no 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.

  Conciseness5/5

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

  The description is appropriately sized and front-loaded. The first sentence states the core purpose, followed by context and details. Every sentence adds value without redundancy, making it efficient and easy to understand.

  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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It explains the purpose, usage context, input types, and output format. However, without an output schema, it could benefit from more details about the return structure (e.g., what 'details' include), but it adequately covers the essentials for an agent to use it correctly.

  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 documents both parameters thoroughly. The description adds some context by mentioning what types of queries are accepted (city names, hotel names, landmarks), but doesn't provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

  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: converting location queries into standardized place information with coordinates. It specifies the verb 'convert' and resource 'user's location query', and distinguishes it from sibling tools like 'search-hotels' by explaining this is for getting coordinates needed for hotel searches, not for searching hotels directly.

  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 explicitly states when to use this tool: 'when you need latitude and longitude for hotel searches but only have a text description.' It provides a clear context and distinguishes from alternatives by implying this is a prerequisite step before using hotel-related tools like 'search-hotels'.

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

• get-hotel-detailsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It describes the tool as retrieving comprehensive details, which implies a read-only operation, but doesn't explicitly state whether it's safe, requires authentication, has rate limits, or what the response format includes. It adds some context about the depth of information but lacks behavioral specifics like error handling or performance.

  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 front-loaded with the core purpose in the first sentence, followed by elaboration and usage guidelines. Every sentence earns its place by adding value—contrasting with search results and specifying when to use it—without redundancy or unnecessary details. It's appropriately sized for the tool's complexity.

  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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, usage, and scope of information returned. However, it lacks details on behavioral aspects like error cases or response structure, which would be helpful since no output schema is provided. It's sufficient but could be more comprehensive.

  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 documents both parameters (hotel_id and session_id) adequately. The description doesn't add any additional meaning beyond what the schema provides, such as explaining why session_id is required or how hotel_id should be sourced. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 verb ('Retrieve comprehensive details') and resource ('about a specific hotel identified by its ID'), distinguishing it from siblings like search-hotels (which finds hotels) and get-facilities (which focuses on amenities). It explicitly contrasts with search results, establishing its unique role in providing deeper information.

  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 explicitly states when to use this tool: 'when a user expresses interest in a specific hotel from search results to provide them with all available options and complete booking information.' This gives clear context and distinguishes it from alternatives like search-hotels (for initial searches) or book-hotel (for booking).

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

• search-hotelsA
  4.2/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 of behavioral disclosure. It effectively describes key traits: it returns a paginated list (50 hotels per request), includes specific hotel details (name, address, rating, etc.), and mentions a session_id for pagination via 'load-more-hotels'. It does not cover aspects like error handling, rate limits, or authentication needs, but provides substantial operational context beyond basic purpose.

  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 appropriately sized and front-loaded, with the first sentence stating the core purpose. Subsequent sentences efficiently add necessary details (returned data, pagination limit, pagination method) without redundancy. Every sentence earns its place by contributing essential information, resulting in zero waste and clear structure.

  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 tool's moderate complexity (9 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, returned data, pagination behavior, and pagination alternative. However, it lacks details on error cases, authentication, or rate limits, which could be relevant for a search tool with many parameters. The absence of an output schema means the description does not explain return values, but it summarizes key details adequately.

  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 documents all 9 parameters thoroughly (e.g., 'adults' as number of adults, 'check_in_date' in YYYY-MM-DD format). The description adds minimal value beyond the schema, mentioning 'location coordinates and booking requirements' which aligns with parameters like latitude/longitude and check-in/out dates, but does not provide additional syntax, format, or usage details not already in the schema.

  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 specific action ('Search for available hotels') and resource ('hotels'), distinguishing it from siblings like 'book-hotel' (booking), 'find-place' (general places), 'get-facilities' (facility info), 'get-hotel-details' (detailed info), and 'load-more-hotels' (pagination). It specifies the search is based on location coordinates and booking requirements, making the purpose explicit and differentiated.

  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 clear context for when to use this tool (searching hotels with location/booking criteria) and explicitly mentions an alternative ('load-more-hotels' for pagination). However, it does not specify when not to use it (e.g., vs. 'find-place' for non-hotel places or 'get-hotel-details' for detailed info), lacking full exclusions or sibling comparisons beyond pagination.

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

• get-facilitiesA
  4.3/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 of behavioral disclosure. It clearly describes the tool's role in the workflow (returns IDs for filtering), the necessity of using it before search-hotels, and the impact on search results. However, it lacks details on rate limits, error handling, or response format, which would be helpful for a tool with no output schema.

  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 appropriately sized and front-loaded with the most critical information ('IMPORTANT: ALWAYS USE THIS TOOL FIRST'). It uses bullet points and an example workflow efficiently, though it could be slightly more concise by integrating some bullet points into prose.

  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 tool's complexity (simple parameter, no output schema, no annotations), the description is largely complete. It explains the purpose, usage, and workflow integration thoroughly. However, without an output schema, it could benefit from more details on the return format (e.g., structure of facility IDs).

  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 description coverage is 100%, so the schema already documents the single parameter (language). The description does not add any parameter-specific information beyond what's in the schema, such as how language affects facility names or default behavior. Baseline 3 is appropriate when the schema handles parameter documentation.

  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 explicitly states the tool's purpose: to return facility IDs that must be used with the search-hotels tool's facilities parameter. It specifies the verb ('returns facility IDs') and resource ('facilities'), and clearly distinguishes it from sibling tools like search-hotels by explaining its role in the workflow.

  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 guidance on when to use this tool vs. alternatives: 'ALWAYS USE THIS TOOL FIRST when a user mentions ANY specific hotel amenities or requirements' and 'must be called BEFORE search-hotels'. It lists specific examples of requirements that trigger its use and explains the consequence of not using it ('searches will not correctly filter').

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

• book-hotelA
  4.4/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 of behavioral disclosure. It effectively describes key behaviors: the tool generates a secure payment link (not completing the booking), requires user action in a browser, and returns specific booking details. It doesn't mention error conditions or rate limits, but covers the core transactional behavior well.

  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 well-structured with clear sections: purpose statement, numbered workflow steps, and response handling. Every sentence adds value - the workflow steps are essential guidance, and the response details ensure proper user interaction. No wasted words or redundancy.

  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 booking tool with no annotations and no output schema, the description provides strong context about the workflow, user interaction requirements, and response expectations. It could be more complete by mentioning error cases or confirmation mechanisms, but covers the essential transactional nature and user workflow adequately.

  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%, providing good parameter documentation. The description adds context about parameter relationships (rate_id comes from user selection after get-hotel-details, session_id from previous search) but doesn't provide additional semantic details beyond what the schema already describes. This meets 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 purpose with specific verbs ('initiate a hotel booking process') and resources ('specific hotel and rate option'). It distinguishes from sibling tools like 'get-hotel-details' by focusing on booking initiation rather than information retrieval.

  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 workflow guidance: it specifies when to use this tool (after presenting rate options via 'get-hotel-details' and user selection), when not to use it (without those prerequisites), and names the alternative tool ('get-hotel-details') for the prerequisite step.

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

• load-more-hotelsA
  4.6/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 discloses key behavioral traits: it's a read operation (implied by 'retrieve'), returns results in batches, maintains format consistency with search-hotels, and indicates pagination status. However, it doesn't mention rate limits, authentication needs, or error conditions.

  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 front-loaded with the core purpose in the first sentence, followed by supporting details. Every sentence adds value: explaining pagination continuation, response format consistency, and pagination status indication. No wasted words.

  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 pagination tool with 1 parameter, 100% schema coverage, and no output schema, the description is largely complete. It explains the tool's purpose, usage context, and response behavior. However, it could benefit from mentioning error handling (e.g., invalid session_id) or performance considerations.

  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 description coverage is 100%, so the schema already documents the single parameter. The description adds context by explaining that session_id comes from 'a previous search-hotels or load-more-hotels response,' which clarifies the parameter's origin and purpose beyond the schema's basic 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's purpose: 'Retrieve additional hotel results from a previous search using the session_id' and 'continues pagination from a previous search-hotels request.' It distinguishes itself from sibling tools like 'search-hotels' by specifying it's for pagination continuation rather than initial 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?

  The description explicitly states when to use this tool: 'from a previous search-hotels request' and 'continues pagination.' It also references the alternative 'search-hotels' for initial searches, providing clear guidance on tool selection.

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