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

With no annotations, the description carries full behavioral burden and does so excellently. It discloses that the reply is grounded in specific data, must never invent rates, must omit wifi/door codes, and never sends because send is always false and there is no send endpoint. This is strong, non-redundant behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is three sentences with zero filler. The core purpose is front-loaded, followed by three critical constraints, each sentence earning its place.

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

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

The description covers the tool's behavior and constraints thoroughly, but with no output schema it does not clarify the exact return shape beyond 'suggested reply'. It also assumes the agent understands 'THAT listing's' without explicit context, though this is a minor gap given the tool's simplicity.

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

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

Schema description coverage is only 50% because conversationId has no description, and the tool description does not compensate by explaining what conversationId identifies or how it relates to 'THAT listing's'. The 'question' parameter is adequately documented, but the required parameter remains semantically unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly indicates the tool produces a suggested reply grounded in listing fields, house rules, amenityId values, and calendar prices, distinguishing it from the list/report/get sibling tools. The verb 'draft' is implicit via the name and the output type, so purpose is identifiable but slightly indirect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, but the sibling set makes the purpose clear by exclusion. It does provide operational boundaries (never send, never invent rates), which indirectly guide usage, but explicit when-to-use guidance is missing.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It adds valuable context by explaining that price null means unknown and instructs not to invent a rate, and it discloses that nested reservations are denylist-stripped. This goes beyond basic retrieval semantics, though it stops short of covering auth, errors, or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded with the endpoint, then provides essential response semantics in three focused sentences. No sentence is redundant; each adds either scope, field meaning, or a critical caveat.

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

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

Given there is no output schema, the description does a good job of explaining the key return values: per-day status, isAvailable, price, and reservation stripping. It could be more complete by covering response structure, date range inclusivity, or authentication, but the core information an agent needs to interpret results is present.

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

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

Schema description coverage is 67%, so the schema already documents startDate and endDate formats. The description adds path context for listingId via the endpoint template, but it does not meaningfully expand on the meaning or constraints of the date parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Retrieve listing calendar') and the specific resource, including the endpoint and query parameter. It is distinct from sibling tools like get_listing and list_reservations, though it does not explicitly name or contrast itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used for viewing daily availability and pricing, but it gives no explicit guidance on when to choose this tool over alternatives such as list_reservations or get_listing. There are no prerequisites, exclusions, or use-case conditions stated.

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

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 HTTP method (GET), that resources are included, and that sensitive fields like wifiPassword, door codes, and invoicing contacts are stripped. It does not mention auth, error behavior, or rate limits, but for a simple read operation it is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three sentences with no wasted words. The core action and endpoint are front-loaded, followed by useful inclusion and exclusion details. Every sentence earns its place.

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

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

There is no output schema, so the description compensates by listing what is included and what is stripped, giving the agent a practical picture of the response. It does not explicitly describe the full return structure or error handling, but for a single-parameter read endpoint, the coverage is strong.

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

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 maps the path parameter {id} to the listingId parameter via the endpoint example, but it does not explicitly define what listingId means beyond its name and path usage. This adds some meaning but leaves the agent to infer the rest from the parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Retrieve'), a specific resource ('one listing'), and the exact endpoint. It clearly distinguishes this from siblings like list_listings by emphasizing 'one listing' versus a list operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used when you need a single listing by ID, and the endpoint path makes that clear. However, it does not explicitly state when to prefer this over list_listings or other sibling tools, nor does it provide exclusion criteria.

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

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

No annotations are provided, so the description carries the full transparency burden. It explicitly states 'Does not send replies', which is the key safety-relevant behavioral trait, and it discloses the SLA default and exact filtering logic. It could mention broader side-effect status more clearly, but the main non-mutating behavior is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and information-dense; the unanswered-thread definition and the non-sending caveat both earn their place. The phrasing 'Hostaway's inbox does not compute' is slightly awkward, but there is no unnecessary filler.

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

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

The core concept is explained, but with no output schema and no annotations, the description should clarify what the tool returns and how slaHours/listingId affect the result. It also gives no guidance about how this relates to sibling tools, leaving an agent uncertain about calling conventions and expected output.

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

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 indirectly explains slaHours via 'Default SLA is 2 hours', but it never names either parameter and gives no explanation of listingId's role. An agent can guess listingId means 'filter by listing', but the description does not actually support that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as an unanswered/SLA view of Hostaway's inbox and defines the unanswered condition with concrete criteria (latest message incoming, or hasUnreadMessages with no later host reply). It lacks an explicit verb like 'get' or 'list', but the resource and computation are recognizable, and 'Does not send replies' distinguishes it from reply-sending tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The SLA and unanswered-thread logic imply this tool should be used for triage-style inbox filtering, but the description never says when to prefer it over related sibling tools like list_conversations, list_messages, or report_inbox. There are no explicit exclusions or alternative routing conditions.

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

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

With no annotations, the description carries the behavioral transparency burden. It does disclose meaningful behavior: the operation is a GET (read-only) and nested Reservation objects are denylist-stripped. However, it omits pagination, response format, auth expectations, and error behavior, so transparency is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The definition is two short sentences, action first, with no filler. The endpoint and the denylist-stripping caveat are both useful and earn their place.

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

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

For a tool with two undocumented optional parameters, no output schema, and no annotations, this is incomplete. It does not explain what listingId and reservationId do, how results are paginated or ordered, or what the response looks like, and it lacks sibling disambiguation.

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

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

Schema description coverage is 0%, and the description never mentions listingId or reservationId or how they affect the result. The schema provides only names and types, so the agent must guess the filter semantics. The only query parameter mentioned, includeResources=1, is part of the endpoint, not one of the input-schema parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the action ('List') and the resource ('inbox threads'), and pins it to the exact endpoint 'GET /v1/conversations?includeResources=1'. This makes it semantically distinct from siblings such as list_reservations or list_messages, which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this tool over list_reservations, list_messages, or inbox_triage. No exclusions, prerequisites, or alternative conditions are stated. 'List inbox threads' gives only an implicit use case.

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

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 does a strong job: it reveals the default specialStatus[]=active filter, explains that availability filters behave exactly as Hostaway does, warns that amenities expect IDs rather than free-text names, constrains check-in/out hours to 0–23, and notes that denylisted fields are stripped from responses. Minor gaps include pagination and return shape, but the description is transparent about the tool's notable behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is tightly written: four short sentences, each carrying distinct information. It is front-loaded with the main purpose, then covers default behavior, filtering semantics, and caveats without wasted words.

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

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

For a read-only listing tool with no output schema and no annotations, the description covers the main invocation details: default filters, optional parameters, value formats, and stripped fields. It falls slightly short of full completeness because it does not mention pagination or the overall response envelope, but the essential information needed to select and call the tool correctly is present.

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

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

Schema coverage is 67%, not at the high threshold, so the description meaningfully compensates. It explains that availabilityDateStart, availabilityDateEnd, and availabilityGuestNumber work together as Hostaway-style filters, and it clarifies the default active status relevant to includeArchived. However, the `city` parameter is left undocumented in both schema and description, which prevents a perfect score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List Hostaway listings.' It immediately distinguishes this from sibling list tools (list_reservations, list_conversations, list_messages) because the resource is clearly listings, not another entity. Additional context about default active status and stripped fields further clarifies exactly what this tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the usage context clear: it lists Hostaway listings, defaults to active entries, and supports optional availability-based filtering. It does not explicitly state 'use this instead of get_listing' or 'do not use for reservations,' but the resource target is obvious from the first sentence and sibling tools.

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

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

With no annotations present, the description must carry the safety/behavioral burden. It explicitly discloses that the operation is read-only and uses GET, which rules out side effects. It does not mention pagination, authentication, or response shape, but for a simple list operation this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences deliver the operation, endpoint, side-effect profile, and a tool-ecosystem note with no redundancy. The essential action is front-loaded.

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

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

For a low-complexity tool with a single integer parameter and no output schema, the description provides enough context to call it correctly. It could be more complete by mentioning what the response contains or how messages are ordered, but that is not critical.

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

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

Schema coverage is 0%, so the description needs to clarify the conversationId parameter. The endpoint path /v1/conversations/{id}/messages maps {id} to conversationId and explains that it is the conversation/thread identifier, adding meaning beyond the bare integer schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('List messages in a thread') with an explicit endpoint, making the tool's purpose unambiguous and distinct from sibling listing tools like list_conversations. The read-only note reinforces that it is a retrieval operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly establishes when to use the tool: to read the messages of a specific conversation/thread. 'Read-only. There is no send tool' provides context and a limitation, though it does not name alternative sibling tools or explicitly state when to prefer them.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly states the tool is read-only, which is a key safety trait, and reveals that doorCode fields are stripped from results. It also notes that create reservation is not implemented. These are meaningful disclosures, though pagination, response shape, and rate limits are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is three short sentences, front-loaded with the primary purpose. Every sentence carries useful information: endpoint, read-only behavior, field stripping, and a limitation. There is no waste or redundancy.

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

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

The description is adequate for a simple read-only listing tool, but it leaves gaps. There is no output schema, and the description does not clarify response contents, date parameter formats, or how the stripped fields affect the result. For correct filtering, an agent would benefit from more detail on arrivalStartDate and arrivalEndDate.

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

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

Schema description coverage is only 25%: only 'match' has a description. The description adds no parameter-level detail and does not compensate for the undocumented listingId, arrivalEndDate, or arrivalStartDate parameters. Date formats and filter semantics are left entirely to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific operation ('List reservations'), the HTTP endpoint (GET /v1/reservations), and the read-only nature. It distinguishes itself from sibling tools like list_conversations and report_occupancy by naming the exact resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: it is the tool for listing reservations and is read-only. It also warns that creation is not implemented, which helps prevent misuse. However, it does not explicitly describe when to prefer this tool over siblings or provide alternative tool routing.

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

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

With no annotations, the description carries the behavioral burden. 'From reads' suggests a read-only operation and the enumeration of missing-fields checks adds transparency, but it does not explicitly state that no data is modified, what the output looks like, or any error behavior. The behavior is partially disclosed but not fully.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two short sentences, front-loaded with the core purpose and followed by a useful exclusion. Every phrase contributes: the missing-fields list clarifies scope, and 'Not a financial report' prevents misuse. There is no redundant or padding content.

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

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

For a simple one-parameter report tool, the description conveys the core function and specific checks performed. However, it omits the meaning of the optional listingId, how results are returned, and when to choose this over sibling reporting tools. These gaps make it adequate but not fully complete.

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

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

The schema has a single listingId parameter with 0% description coverage, and the tool description never mentions listingId or explains how it is used. The parameter is inferable from its name and context, but the description adds no semantic value beyond what the schema property name already implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and action: reporting listing completeness by identifying missing photos, house rules, and amenities. It differentiates itself from financial reports, which helps distinguish it from report_occupancy and similar siblings, though it does not name a sibling directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Not a financial report' sentence provides a negative usage signal, and the content implies it should be used when checking listing completeness. However, it does not explicitly state when to use this tool versus alternatives like get_listing or report_occupancy, leaving usage context largely implied.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose the computation source ('computed from conversation reads') and positions the output as counts, which adds real context beyond the name. But it does not clarify side effects, the definition of 'unanswered,' or why it is explicitly not a Hostaway owner statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is short and front-loads the main functionality in the first sentence. The second sentence is a compact disambiguation, though its meaning is somewhat opaque and slightly hurts clarity.

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

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

There is no output schema and no annotations, so the description must convey enough about inputs and results. It explains the general shape of the report but not the meaning of slaHours, what the output structure looks like, or how this report compares to related inbox/report tools. The odd negative statement about Hostaway adds more confusion than completeness.

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

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 indirectly maps to listingId via 'by listing' but entirely omits slaHours, leaving its meaning, units, and effect on the report unclear. For a tool with only two parameters, this is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's core purpose: reporting unanswered thread counts grouped by listing. It also adds a useful source qualifier ('computed from conversation reads') that distinguishes it from raw conversation/message listing tools. However, it lacks a verb and does not explicitly differentiate it from sibling tools like inbox_triage or report_occupancy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is appropriate for aggregate unanswered-thread reporting, and the phrase 'Not a Hostaway owner statement' provides a partial exclusion. However, it does not name any sibling alternatives or give explicit criteria for when to choose this report over list_conversations, inbox_triage, or report_occupancy.

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

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 explains the calculation formula, the data source (calendar reads), and what the report is not. It does not describe side effects, permissions, or edge-case behavior, but the read-only nature is strongly implied by 'computed from calendar reads.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four short sentences, each adding information: what is computed, how occupancy is calculated, how blocked holes are defined, and what is excluded. It is front-loaded with the core purpose and contains no filler.

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

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

The description thoroughly explains the report's content and exclusions, but it lacks parameter semantics and return-format details. With no output schema and no annotations, an agent still has to infer what the report response looks like and how the optional listingId changes the result.

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

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

Schema description coverage is 0%, and the description does not mention startDate, endDate, or listingId at all. The parameter names are self-explanatory, and the formula implies a date-range-based calculation, but the description does not clarify required vs optional usage, date formats, or how listingId affects results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and computed metrics: occupancy and blocked holes from calendar reads. The formula for occupancy and the definition of blocked holes make the purpose unambiguous. It also adds negative scope ('Not an owner statement. No financials.') which helps distinguish it from financial or owner-facing reports, though it does not name sibling tools directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear: use this tool when occupancy or blocked-hole metrics are needed. The negative statements ('Not an owner statement. No financials.') provide explicit exclusions. However, no sibling alternative is named, so an agent must infer which other report tool to choose instead.

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