Server Quality Checklist

Tool Scores

• get_best_rateB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full behavioral disclosure burden. It states the core outcome (cheapest available rate) but does not disclose output format, error behavior, how optional parameters like date affect results, or any rate-specific details (taxes, currency, etc.).

  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 immediately communicates the core purpose. No redundant words or filler; it earns its place.

  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?

  Given no output schema and no annotations, the description should provide more context about return values or rate details. It also omits the adults/children parameters, which are likely relevant for rate calculation. The description is minimal and leaves significant gaps for a 4-parameter 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 only 25% (property only). The description adds the date format and optionality, which is helpful, but it fails to mention the 'adults' and 'children' parameters that are present in the schema, leaving their semantics unclear. The description does not sufficiently compensate for the low schema coverage.

  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 identifies the resource (property) and scope (cheapest available rate, optional date), distinguishing it from get_rates by explicitly stating 'Cheapest'. However, it lacks an explicit verb, relying on the tool name for the action.

  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 intended usage is implied (when you need the cheapest rate for a property) but the description does not explicitly state when to use this tool versus alternatives like get_rates or get_availability, nor does it provide exclusions or alternative recommendations.

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

• get_calendarB
  3/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It reveals that the tool returns day-by-day availability, but it does not disclose the output format, whether the range is inclusive, or any auth/rate limits. The lack of such details is a significant gap for a tool with no 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 only two sentences, front-loaded with the core behavior and then a practical example. No redundant or filler content is present, making it efficient and well-structured.

  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?

  For a tool with 5 parameters, no output schema, and no annotations, the description is too thin. It does not describe the response structure, meaning of optional parameters (adults/children), or how it relates to the similar-sounding get_availability sibling. The existing context is not enough for an agent to fully anticipate tool behavior.

  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 low (20% – only property has a description). The description mentions a date range and format YYYY-MM-DD, but this is redundant with the schema's pattern. It does not explain the adults/children parameters or how they interact with availability, leaving a large semantic gap.

  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 the tool provides 'day-by-day availability over a date range', which is a specific verb+resource+scope. It distinguishes from siblings through 'day-by-day' granularity, but doesn't explicitly name alternatives like get_availability, so it lacks explicit sibling 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 phrase 'Good for "which days are free in August"' implies a use case for checking availability across a range, but it does not provide explicit when-to-use versus alternatives or exclusions. The guidance is implied through example rather than stated.

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

• get_offersB
  3.1/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 of behavioral disclosure. It adds the scoping detail 'currently active' but omits other important traits such as read-only nature, return format, pagination, or permission requirements. This is minimal disclosure for an unannotated tool.

  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, focused sentence with minimal word count. It front-loads the key information ('Currently active special offers/packages') and contains no filler or redundant phrases.

  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?

  For a simple one-parameter getter, the description conveys the core purpose and scope. However, the absence of annotations and output schema means the agent lacks information about return format, pagination, or access restrictions, leaving noticeable gaps for a complete understanding.

  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 adds no parameter-level details beyond the schema, but the schema coverage is 100% with a clear explanation and example (GOLDENSAND) plus a helpful pointer to list_properties. Per the baseline for high schema coverage, a score of 3 is appropriate.

  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 identifies the resource as 'currently active special offers/packages for a property', which distinguishes it from sibling tools like get_rates or get_availability. However, it is phrased as a noun fragment rather than a verb phrase ('Get active offers'), slightly reducing actionability.

  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?

  No explicit guidance is given on when to use get_offers versus alternatives such as get_rates or get_best_rate. The only contextual hint is 'for a property', which is already evident from the schema. There are no mentions of when-not-to-use or alternative tool references.

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

• get_ratesB
  3.2/5.0
  Behavior2/5

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

  With no annotations present, the description must carry the full burden of behavioral disclosure, but it only states the content ('rate plans with cancellation policies') and the optional filter. It does not explicitly indicate that this is a safe read-only operation, nor does it mention error conditions, permissions, or output structure. The lack of a verb leaves the action implicit, and no behavioral traits beyond a noun phrase are disclosed.

  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, tightly worded sentence that front-loads the core resource and follows with the scope and optional filter. Every word contributes meaningful information with no redundancy, making it highly scannable for an agent.

  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 simple two-parameter read tool with no output schema or annotations, the description adequately conveys what is returned ('rate plans with cancellation policies') and the optional filtering behavior. It does not detail the return shape, but the low complexity and full schema coverage mean this is not a significant gap. Overall, it is sufficiently complete for an agent to understand the tool's basic function.

  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% for both parameters, with property described as the WebHotelier code and room as the code to filter by. The description's phrase 'optionally filtered to one room type' adds no new meaning beyond what the schema already provides for the room parameter. It also does not introduce any syntax or format details, so the baseline 3 is appropriate.

  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 identifies the resource as 'rate plans with cancellation policies' scoped to a property with optional room-type filtering. It does not use an explicit verb like 'get' or 'list', but the tool name and the noun phrase combine to make the purpose unambiguous. This also distinguishes it from siblings like get_best_rate by focusing on rate plans rather than best available rate.

  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?

  There is no guidance on when to use this tool versus alternatives such as get_best_rate, get_availability, or get_offers. The only usage-related hint is the optional room-type filter, which is a parameter detail rather than a selection criterion. No exclusions or alternative recommendations are provided.

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

• get_property_infoA
  3.8/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 burden of behavioral disclosure. It clearly indicates a read operation returning profile and room catalog, but it does not mention potential errors, response format, or any access requirements. For a simple get tool this is adequate, but it adds minimal behavioral context beyond the name.

  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, information-dense sentence that front-loads the main purpose and parenthetically lists the catalog items. Every word adds value and there is no redundancy 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?

  For a simple one-parameter read tool with no output schema, the description is sufficient: it tells the agent exactly what data will be returned (profile and room catalog) and the scope (one property). It could add notes about error behavior or return shape, but those are not critical for selection and invocation.

  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 covers the single parameter fully with a description including an example and a fallback instruction. The tool description adds no additional parameter semantics, but the schema already provides sufficient detail, so the baseline of 3 applies.

  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 a hotel profile and full room catalog (room types, capacities, amenities) for one property. This distinguishes it from siblings like list_properties (which lists properties) and get_rates/get_availability (which focus on pricing and availability). The scope is specific: 'for one property'.

  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 this tool is for fetching comprehensive property details and room catalog for a single property, but it does not explicitly state when to prefer it over siblings. It lacks explicit 'when to use' or 'when not to use' guidance. The schema mentions calling list_properties if the property code is unknown, but that is not in the main description.

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

• get_reservationsA
  3.8/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 usefully discloses the permission requirement (WebHotelier account with reservations access) and the behavior when access is missing (returns a clear permission message). It also adds the date format (YYYY-MM-DD) and confirms that filters are optional. However, it does not explicitly state that the operation is read-only, though 'search' implies it.

  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, consisting of two sentences with no redundant information. The first sentence states the core purpose and filters; the second adds a necessary permission note. Every sentence 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 covers the tool's purpose, optional filters, date format, and a crucial permission prerequisite. Given that all parameters are optional and well-described in the schema, this is sufficient for an agent to select and invoke the tool. The lack of an output schema is not compensated for, but the description implies the tool returns matching bookings, which is adequate for a simple search. Could be slightly improved by mentioning that no filters returns all reservations, but this is not a major gap.

  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 baseline is 3. The description adds no new meaning beyond the schema: the schema already documents each parameter with descriptions (e.g., 'Earliest check-in date', 'WebHotelier property code'). The description merely notes the date format, which the schema's pattern also defines. Therefore, the description does not significantly enhance parameter understanding beyond what the schema already provides.

  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 with a specific verb ('Search') and resource ('bookings'), and specifies optional filters (property, check-in date range). This distinguishes it from sibling tools like get_rates and get_availability, which target other data types.

  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?

  No guidance is given on when to use this tool versus alternatives or when not to use it. The only context provided is the permission requirement, which is more of a prerequisite than a usage guideline. There is no mention of sibling tools or recommended scenarios.

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

• get_availabilityA
  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 disclosure burden. It adds 'live' data context and the dates format, but doesn't disclose response structure, error behavior, or whether both checkout and nights causes issues. It's acceptable 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?

  Three sentences with a clear lead, date format, and usage rule. 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?

  Given the complexity (8 params, no output schema, no annotations), the description communicates the core purpose and essential parameter constraints. However, it omits expected return values (e.g., room types, price breakdown) and edge-case behaviors, leaving the agent with gaps for a complete interaction.

  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 covers only 25% of parameters. The description adds two important semantic details: date format (YYYY-MM-DD) and the checkout-vs-nights mutual exclusivity. This goes beyond schema, though other params like adults/children/rooms are left to names and schema types.

  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 identifies the tool as 'Live availability and prices for a specific stay', specifying the resource (availability/prices) and scope (specific stay). It also positions it as the primary tool for 'is there a room and how much' questions, distinguishing it from siblings like get_rates or get_best_rate.

  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 states this is the primary tool for room availability/pricing queries, providing clear usage context. It also gives a key usage rule ('Provide checkout OR nights') but does not explicitly mention when to prefer alternatives like get_rates for pure pricing or get_calendar for date-level views.

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

• list_propertiesA
  4.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 carries the full burden. It discloses the 'Local lookup — no API call' behavior, which is an important trait (no network latency, likely cached). However, it does not describe the exact return structure or whether the list is sorted/filterable, which for a zero-parameter list tool is 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 two concise sentences, front-loaded with the main action. It avoids wasted words and includes the usage cue in the second sentence.

  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 stateless, zero-parameter lookup tool with no output schema, the description covers the essential points: what it lists (hotels and codes), when to call it (first, when code unknown), and a key behavioral trait (local lookup). This is complete given the tool's simplicity.

  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 takes 0 parameters, and the schema coverage is 100%. The baseline for zero-param tools is 4, and the description does not need to explain parameters. It adds value by clarifying the output includes property codes, but that's not parameter semantics.

  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 'List all known hotels with their WebHotelier property codes,' using a specific verb and resource. It also differentiates from sibling tools (get_rates, get_availability) by focusing on the property registry rather than pricing or availability data.

  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?

  It gives clear guidance: 'Call this first whenever you don't know a property code,' which tells the agent when to invoke this tool. The additional note 'Local lookup — no API call' provides context that it is a fast, prerequisite lookup.

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