Server Quality Checklist

Tool Scores

• list_propertiesC
  2.8/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden. It implies a read-only operation via 'List', but does not disclose any behavioral traits such as default filtering (active_only), pagination limits, or 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.

  Conciseness4/5

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

  The description is a single concise sentence, which is easy to parse. However, it is under-specified, omitting parameter and usage information, so while concise, it sacrifices completeness.

  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 the tool has two parameters with no descriptions, an output schema, and many sibling list tools, the description is incomplete. It only states the resource and fields but lacks necessary context for correct invocation.

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

  Parameters1/5

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

  The input schema has two parameters (max_items, active_only) with no descriptions, and schema description coverage is 0%. The description does not mention or clarify either parameter, leaving the agent without understanding their meaning or defaults.

  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 'List properties' and specifies the included fields (id, name, address, timezone), which distinguishes it from sibling list tools for owners, bookings, etc. It provides a specific verb and resource.

  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 guidance on when to use this tool versus alternatives such as list_owners or list_bookings. There are no exclusions, prerequisites, or context of any kind.

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

• list_quotesB
  3/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 only says 'List quotes' and mentions filtering, but does not disclose whether it is read-only, how pagination works, what max_items does, response limits, or any error behaviors. This is a minimal description with no added behavioral context.

  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, concise sentence that front-loads the main action ('List quotes') and adds one key detail about filtering. It wastes no words.

  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?

  The tool is simple but the description omits important context: it does not mention the max_items parameter at all, nor does it clarify whether property_ids is a required filter or how the result set is constrained. Although an output schema exists, the description alone is insufficient for an agent to invoke the tool correctly in many situations.

  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. It adds the comma-separated format for property_ids, but does not explain the meaning or usage of max_items. The description leaves one of two parameters completely undocumented.

  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 verb ('List') and resource ('quotes'), and mentions an optional filter. It distinguishes from sibling tools like list_bookings or list_owners by naming quotes, but does not explicitly contrast with them.

  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 this tool (to list quotes, optionally filtered by property IDs), but provides no explicit guidance on when not to use it or which alternatives might be preferable. It lacks a direct comparison to sibling list tools.

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

• list_feesB
  3.1/5.0
  Behavior2/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 of behavioral disclosure. It only states the core action and optional filter, but does not mention pagination, ordering, or what happens when booking_id is null. The max_items parameter suggests a limit behavior that is not explained, leaving uncertainty about result size and whether fees are aggregated or itemized.

  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 of 9 words. Every word earns its place; it states the action, the object, and the optional scope. There is no redundancy or filler, making it highly efficient.

  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?

  While the tool is simple and an output schema exists to document return values, the description omits critical behavioral details such as max_items semantics and default scope (all fees vs. specific booking). Without annotations or parameter descriptions, the agent has insufficient context to use the tool correctly beyond a basic call.

  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. It adds meaning for booking_id ('optionally for a single booking') but completely ignores max_items, which is left undocumented in both schema and description. The agent gets no explanation of what max_items controls or its default behavior, requiring guesswork.

  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 ('List') and the resource ('booking fees'), and it distinguishes from sibling list tools (e.g., list_payments, list_refunds) by focusing specifically on fees. It also adds a scope qualifier ('optionally for a single booking') that clarifies the primary parameter's behavior, 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 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 versus alternatives. While 'List booking fees' implies it is for fee retrieval, it does not explain when not to use it or mention related tools like list_payments or list_quotes. There is no exclusion or alternative mentioned, so the agent must infer usage from the name alone.

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

• list_messagesB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description relies on the verb 'List' to imply a safe read-only operation. It does not disclose ordering, pagination, or side effects like marking messages as read. This is adequate but leaves behavioral traits unstated.

  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 one short sentence with no filler or repetition. It is appropriately sized for a simple list operation and every word contributes to the purpose.

  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?

  Although the schema and output schema cover parameters and return structure, the description lacks any contextual guidance about thread-level scoping versus open messages, or when to use this tool. Given the existence of siblings like list_open_messages and send_message, this minimal description leaves the agent under-informed about the tool's place in the workflow.

  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 additional meaning beyond the schema; it only mentions 'conversation thread' which maps to thread_id. The rich parameter descriptions in the schema do the heavy lifting.

  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 uses a specific verb 'List' and identifies the resource 'messages' scoped to 'a conversation thread', which clearly distinguishes it from sibling tools like list_open_messages. However, it does not explicitly contrast with siblings like send_message or mark_message_handled, so it is clear but not overtly differentiating.

  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 provided about when to use this tool versus alternatives such as list_open_messages or get_message_event. There are no exclusions, prerequisites, or alternative tool mentions. The description only states what it does, not when or why to use it.

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

• list_refundsB
  3.2/5.0
  Behavior2/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 states the basic listing function and the optional booking filter, but does not disclose behavior like pagination via max_items, default limits, ordering, or whether refunds are read-only (seemingly implied by 'list' but not explicit).

  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?

  A single clear sentence with no filler. It front-loads the core action and the one meaningful variant (single booking), making it easy to scan.

  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 tool is simple with only two optional parameters and an output schema exists, so the description doesn't need to cover return values. However, it lacks guidance on max_items usage and does not position the tool relative to payments/fees, leaving some gaps for an agent trying to decide between list tools.

  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%. The description only hints at booking_id ('optionally for a single booking'), leaving max_items completely undocumented. The schema provides defaults and types, but the description does not explain how max_items behaves or what the parameters actually mean in the refund context.

  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 a specific resource ('guest refunds'), and adds an optional filter ('for a single booking'). This clearly distinguishes it from sibling tools like list_payments or list_bookings.

  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 list_payments or list_fees, and no mention of when filtering by booking_id is appropriate or required. The only hint is the optional booking filter, but no explicit comparison or exclusion.

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

• list_webhook_subscriptionsB
  3.2/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 of disclosing behavior. It does reveal the 'active' filter, which is a meaningful behavioral trait. However, it does not explicitly state that the operation is read-only, nor does it mention pagination, rate limits, or authentication context. For a list tool, this is minimal but not misleading.

  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 sentence with no unnecessary words, making it efficient and front-loaded. However, it is under-specified due to the omission of parameter semantics, which prevents a perfect score.

  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 one optional parameter and an output schema, the description covers the core action but omits the meaning of max_items and any behavioral constraints like pagination or default limits. With no annotations, this leaves significant gaps in the agent's understanding. The output schema does not compensate for missing parameter guidance.

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

  Parameters1/5

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

  The schema defines max_items with a default but no description (0% coverage). The description does not mention this parameter at all, so an agent would not understand what max_items controls or how it affects results. The description fails to compensate for the schema's lack of parameter explanation.

  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 the specific verb 'List' with a clear resource 'webhook subscriptions', scoped to 'active' and 'on the account'. This clearly distinguishes it from sibling tools like create/delete_webhook_subscription and other list tools.

  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 states what the tool does but provides no explicit guidance on when to use it vs alternatives. Usage is implied by the name and verb, but there is no reference to when not to use it or which alternative to prefer.

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

• list_ownersB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It indicates a read-only list operation, but does not explain pagination limits (despite max_items), sorting, filtering, authorization requirements, or what happens if no owners exist. The behavioral context is minimal.

  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 redundancy. Every word earns its place, and it efficiently conveys the core purpose and return fields.

  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 simple with one optional parameter and an output schema, so the description captures the essential resource and return fields. However, it omits any explanation of the max_items parameter's effect, which is a minor gap for a tool this simple. The presence of an output schema covers return value details, so the description is largely 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?

  The only parameter, max_items, is completely unexplained in the description. Schema coverage is 0%, so the description carries the burden, but it fails to convey that max_items limits the number of results or how the default affects behavior. The parameter name gives some semantic hints, but the description adds no value.

  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 ('List'), the resource ('property owners'), and the specific fields returned (id, name, contact). It is distinct from siblings like list_properties, which lists properties rather than owners.

  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 provided on when to use this tool instead of alternatives. The description does not mention any specific scenarios, prerequisites, or references to sibling tools, leaving the agent without context for selection.

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

• send_messageA
  3.5/5.0
  Behavior2/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 of behavioral disclosure. It only states the basic action without mentioning side effects (e.g., that it appends to the thread), failure conditions (e.g., invalid thread_id), or any required permissions. This is a significant gap for a write operation.

  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 that directly conveys the tool's purpose without any wasted words. It is appropriately concise and front-loaded.

  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 tool has a small parameter set with full schema coverage and an output schema, so the description does not need to explain return values. However, because there are no annotations, the description is minimal and does not address potential edge cases or operational context, making it only 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?

  The input schema provides 100% coverage with detailed descriptions for all parameters, including the meaning of thread_id and the attachment size limit. The tool description itself adds no additional parameter context, so the schema does the heavy lifting, warranting 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 ('Send a message'), the target ('a guest'), and the context ('on an existing conversation thread'). It is specific and distinguishes from sibling read-only tools like list_messages and get_message_event.

  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 by requiring an 'existing conversation thread', which suggests the tool is for replies rather than starting new threads. However, it does not explicitly mention when to use this tool over alternatives or provide exclusion criteria, so the guidance is only implied.

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

• create_webhook_subscriptionA
  3.7/5.0
  Behavior2/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 only states the action without disclosing side effects, idempotency, permissions required, or what happens upon successful registration. The mention of HTTPS is redundant with the URL parameter description. There is a lack of important behavioral context for a mutating operation.

  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 sentence that is front-loaded with the core action and resource, contains no filler or redundancy, and is immediately understandable.

  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 tool with only two parameters, full schema coverage, and an output schema, the description is minimally acceptable. However, the lack of behavioral details (e.g., whether the URL is verified, if duplicates are allowed) leaves gaps that are not compensated by annotations, warranting a score below 4.

  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%: both 'url' and 'category' already have descriptive text. The tool description adds no additional meaning beyond what the schema provides, so it meets the baseline with no extra value, but does not need to compensate for missing parameter info.

  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 'Subscribe' and clearly states the resource ('OwnerRez events') and mechanism ('registering an HTTPS callback URL'). It distinguishes itself from sibling tools by focusing on creation rather than listing or deleting webhook subscriptions.

  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 implies clear usage context: use this when you need to receive event notifications by registering a callback URL. It does not explicitly mention alternatives or exclusions, but the intent is clear enough for an agent to select this tool over list_webhook_subscriptions or delete_webhook_subscription.

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

• delete_webhook_subscriptionA
  3.8/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 of behavioral disclosure. It states the tool is destructive ('Remove') and adds a specific operational constraint: 'Blocked in read-only mode.' This is valuable context beyond the schema, but it does not disclose other important behaviors such as irreversibility, failure modes, or permission requirements. It provides some transparency but not comprehensive behavioral detail.

  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 exceptionally concise, consisting of two short sentences. Each sentence provides distinct, useful information: the action and a critical operational constraint. There is no redundancy or filler, making it easy for an agent to parse quickly.

  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 delete operation with a single parameter and an output schema, the description covers the essential purpose and a key constraint. The output schema presumably documents return values, so the description does not need to. It is adequate, though it could optionally mention that deletion is permanent, which would make it more complete. Overall, it is sufficiently complete for the tool's simplicity.

  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 has zero description coverage for the single parameter, so the description must compensate. It does so partially by saying 'by its ID' which clarifies that subscription_id is the identifier of the subscription to remove, matching the parameter name. However, it offers no additional meaning about the parameter's format, range, or where to find valid IDs, so the compensation is minimal.

  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 ('Remove'), the resource ('webhook subscription'), and the scope ('by its ID'). It unambiguously distinguishes this tool from its siblings like 'create_webhook_subscription' and 'list_webhook_subscriptions', which perform different actions on the same resource.

  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 is implied: an agent would use this to delete a webhook subscription when it has the ID. However, there is no explicit mention of when to use this versus alternatives, nor any guidance on prerequisites (e.g., how to obtain the ID, such as by using list_webhook_subscriptions). The read-only mode restriction provides a constraint but does not offer comparative usage guidance.

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

• find_guestA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It reveals that the endpoint is bounded by created_since_utc, which is a useful behavioral trait. However, it does not describe other behaviors such as pagination, authentication, or whether search is case-insensitive, leaving some opacity.

  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 exactly two sentences, front-loaded with the purpose, and contains no redundant information. 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?

  For a simple optional-parameter search/list tool, the description is mostly complete: it states the purpose and the key bound. An output schema exists so return values are documented. However, it lacks explicit differentiation from potentially overlapping siblings like who_is_staying, and it doesn't clarify the search-vs-list behavior (e.g., 'with no query, lists all'). Still, given the low complexity, it's adequate.

  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 provides full descriptions for all three parameters (coverage 100%), so the baseline is 3. The description adds minimal extra meaning by explaining that the endpoint is bounded by created_since_utc, giving context for that parameter, but it does not elaborate on query or max_items.

  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 'Search or list guests,' which clearly identifies the operation (search/list) and the resource (guests). This differentiates it from sibling tools like list_owners and list_bookings, which operate on different entities. The mention of the OwnerRez bound adds specificity without confusing the purpose.

  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 the tool is for finding guests but does not explicitly state when to use it versus alternatives like who_is_staying or list_bookings. It provides no exclusionary guidance or named alternatives, though the resource type itself helps. The bound on created_since_utc offers some context about result scope.

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

• get_message_eventA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries burden. It discloses that the response includes raw webhook payload, which adds context. However, it doesn't explicitly state read-only nature or error behavior.

  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?

  Single sentence, 11 words, front-loaded with verb, no 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?

  Simple get-by-id tool with output schema available; description covers the main purpose and the raw payload characteristic. Lacks usage guidance but is otherwise adequate.

  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 0% with only event_id. Description says 'by id' which confirms the parameter's role as the identifier, but adds no format or sourcing details beyond that.

  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?

  Clear verb 'Get' with specific resource 'stored message event' and scope 'by id'. Distinguishes from sibling tools like list_messages which lists events, and mark_message_handled which mutates.

  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?

  Implies usage when you have an event_id, but does not explicitly contrast with list_messages or other retrieval tools. No when-not-to-use guidance.

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

• list_paymentsA
  3.8/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. The verb 'List' implies a read-only, non-destructive operation, and the optional booking filter adds scope clarity. But it does not explicitly state that it is safe, nor does it disclose any side effects, auth requirements, or pagination behavior beyond what can be inferred from the parameter names.

  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 states the purpose and optional filter with no unnecessary words. It is concise and every phrase 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 tool has only two optional parameters and an output schema, so the description covers the core purpose and the main filtering option. The max_items parameter is not described but is intuitive, and return values are covered by the output schema. This is sufficient for a simple list operation.

  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 0%, so the description must compensate. It explains the booking_id parameter ('optionally for a single booking'), but does not describe max_items, which is left to be inferred from its name. Since max_items is fairly self-explanatory, the partial compensation is adequate for this simple tool.

  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 (List) and resource (guest payments), and the optional booking filter distinguishes it from sibling tools like list_refunds and list_bookings. It is specific and avoids ambiguity.

  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 by stating the tool lists guest payments and can be filtered by booking, providing clear context. However, it does not explicitly mention when to use this tool over alternatives such as list_refunds or list_bookings, nor does it state any exclusions.

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

• get_bookingA
  3.9/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. It indicates that the output will be 'full details' and that lookup is by OwnerRez ID, implying a read-only operation. However, it does not disclose potential error behavior, permissions needed, or clarify that include_guest may affect the response. The description is adequate but lacks deeper behavioral context.

  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 sentence, concise and front-loaded, with no wasted words. It efficiently conveys the core purpose and identifier without redundancy.

  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 simplicity of the tool, the description covers the essential purpose and primary identifier. However, the include_guest parameter is unexplained, which is a notable omission since it affects the response contents. The presence of an output schema reduces the need to describe return values, but the parameter gap prevents full contextual completeness.

  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 0%, so the description must compensate. It adds meaning to booking_id by referring to it as the OwnerRez ID, but it entirely ignores include_guest, leaving its purpose and effect undocumented. This partial coverage of one parameter with no mention of the other is a clear gap.

  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'), the resource ('full details for a single booking'), and the method of identification ('by its OwnerRez ID'). This unambiguously distinguishes it from list_bookings, which likely returns a collection without full detail for each item.

  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 implies usage: when you need complete information about one specific booking rather than a list. It does not explicitly mention when not to use it or name alternatives (e.g., list_bookings for summaries), so it lacks explicit exclusion criteria but provides clear contextual direction.

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

• list_open_messagesA
  4.2/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 state filter (unhandled), the returned fields, and a prerequisite (webhook running/subscribed). It does not mention sorting or error behavior, but for a simple read-only list tool this is sufficient context.

  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, front-loaded with the main purpose, then a useful detail about returned fields and thread_id, then a prerequisite and a cross-reference. Every sentence earns its place with no filler.

  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 one optional parameter and an output schema, the description fully covers what it does, what it returns, why it exists, and what must be true before calling it. The prerequisite and the thread_id usage hint make it complete in context.

  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?

  The schema description coverage is 0%. The only parameter, limit, is completely absent from the description. The description does not add any meaning such as 'maximum number of messages to return' or clarify default behavior beyond the schema's default value of 50.

  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') with a clearly bounded resource ('inbound guest messages... that haven't been marked handled yet'). It establishes the tool as the 'open messages inbox,' which clearly distinguishes it from sibling list_messages.

  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 gives a clear context (open messages inbox) and explicitly states a prerequisite: the webhook receiver must be running and subscribed, with a pointer to create_webhook_subscription. It does not explicitly name alternative tools for when the user wants all messages, but it defines the relevant filter.

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

• mark_message_handledA
  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 explicitly states that the operation is 'local bookkeeping only' and 'does not call OwnerRez,' which is a critical side-effect disclosure. It also mentions the effect on the open list and the ability to reopen, giving a good sense of the tool's impact.

  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 exactly two sentences, front-loaded with the primary purpose and followed by a critical caveat. Every word earns its place, with no fluff or redundancy. It's highly concise and well-structured.

  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 tool with only two parameters and an output schema, the description covers the core behavior and the external integration boundary. It doesn't explain return values, but the output schema covers that. The only minor gap is no explicit prerequisites or edge cases, but the 'stored message' and 'local bookkeeping' context imply the necessary preconditions.

  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 0%, so the description must compensate. While it doesn't name the parameters, the phrase 'mark as handled (or reopen it)' indirectly maps to the 'handled' boolean (true/false), and 'stored message' implies the event_id. The parameter names are self-explanatory, and the description adds some semantic context, but it doesn't explicitly explain each parameter's role.

  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: 'Mark a stored message as handled (or reopen it), removing it from the open list.' This uses a specific verb ('mark') and resource ('stored message'), and distinguishes it from list/message viewing tools like list_messages or get_message_event. It also clarifies the reversible nature (reopen) and the effect on the open list.

  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 when-not guideline: 'Local bookkeeping only — does not call OwnerRez.' This tells the agent not to use this tool when an actual OwnerRez update is needed, and implies it's for local state changes. It doesn't explicitly name alternative tools, but this exclusionary context is clear and useful for distinguishing from sibling tools.

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

• list_bookingsA
  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 full burden. It discloses a key behavioral trait: the endpoint always uses a time bound (since_utc) and is not bound by stay dates, which is critical for correct usage. It does not mention pagination or rate limits, but output schema exists.

  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 short sentences, front-loaded with 'List bookings.' Each sentence earns its place: the first states purpose, the second explains the time-bound behavior, and the third gives a clear filtering instruction. No unnecessary information or 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?

  For an 8-parameter list tool with output schema and no annotations, the description focuses on the most important nuance that wouldn't be obvious from the schema alone. The parameter descriptions cover defaults and filters, so the description doesn't need to restate them. Minor gaps exist around pagination and max_items, but these are documented in the schema.

  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 100%, so baseline is 3. The description adds meaning by explaining the relationship between since_utc and arrival filters: since_utc is the actual API bound, while arrival_start/arrival_end are client-side narrowing. This clarifies the intended usage of these parameters beyond their 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 opens with 'List bookings.' which clearly identifies the verb and resource. It further explains the scope (bookings created or changed since a UTC time), distinguishing it from singular and other resource-specific list tools.

  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 that the endpoint is bounded by since_utc rather than stay dates, and explicitly instructs to use arrival_start/arrival_end to narrow by stay window client-side. It does not explicitly reference alternatives like get_booking, but the guidance is clear and actionable.

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

• who_is_stayingA
  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 full burden and does well by disclosing the exact stay date condition, the default behavior, and the internal data window (~last year of changed bookings). It does not mention auth, rate limits, or pagination, but for a non-mutating query tool these are less 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?

  Three sentences, each earning its place: purpose, returned row structure, and default/implementation note. Front-loaded with the main verb and resource, and 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?

  The description is sufficiently complete for a simple read-only tool with one optional parameter. It defines the row semantics and the internal data limitation, although it does not address edge cases like bookings older than the ~year window or output ordering. The presence of an output schema (not shown) likely covers 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?

  The only parameter, on_date, has no schema description, but the tool description compensates by explaining its meaning ('Defaults to today') and how it fits in the active-stay predicate. It doesn't specify the expected date format, but the parameter is simple and optional.

  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 ('Show') and clearly identifies the resource ('who is currently staying in each property'). It differentiates from sibling tools like list_bookings by focusing on active/in-house guests and explicitly defines the active stay condition (arrival <= on_date < departure), making the purpose unmistakable.

  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 gives clear context: it defaults to today and explains the date filtering logic, implying when the tool is appropriate (current occupancy). However, it does not explicitly mention alternatives or when not to use it, 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.