hotelumo

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by stating the tool is 'safe' and by listing sensitive data categories that are never returned, which goes beyond what the annotations alone convey.

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 sentences with no filler. The core purpose is front-loaded, and the exclusion list is compact yet specific enough to prevent misuse.

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 single-parameter read-only tool with an output schema and rich annotations, the description sufficiently communicates scope and safety boundaries. Nothing critical is missing for an agent to invoke it correctly.

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 100% because the only parameter, hotelId, already has a clear type, pattern, and description. The tool description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

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 action ('Get') and resource ('one organization-owned hotel') and clarifies the scope as 'safe operational metadata.' It further distinguishes the tool by explicitly enumerating what is never returned, which helps separate it from siblings like get_hotel_availability or show_hotel_overview.

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 explain when to prefer this tool over its siblings. It neither names alternatives nor provides conditional guidance (e.g., 'for availability, use get_hotel_availability'). Usage context is only implied by the phrase 'operational metadata,' which is not explicit enough for a tool with ten siblings.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds substantial behavioral context: the query is bounded (max 30 nights), non-person-linked, and it explicitly lists exclusions (guest records, reservations, room assignments, access data, notes, payments, channel references, photos, free-text descriptions, and credentials). It also states that amounts are in minor currency units. This goes beyond annotations and gives the agent a clear picture of data scope and constraints.

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 sentences, front-loaded with the core purpose and constraints. The long exclusion list is dense but each item is meaningful and earns its place. There is no filler, repetition, or unnecessary detail. It is efficiently structured.

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 the existence of an output schema, the description does not need to explain return values. It covers scope, constraints, exclusions, and currency units comprehensively. It does not explicitly mention pagination or response structure, but those are likely covered by the output schema. The description is complete enough for an agent to call the tool correctly, though a note on the meaning of 'availability' might add minor value.

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 50% (hotelId, checkInDate, checkOutDate have descriptions; adults, infants, children do not). The description compensates by clarifying that hotelId refers to a tenant-owned hotel and that the stay is at most 30 nights, which imposes constraints on the date parameters. It also clarifies the currency unit for price-related outputs. The guest-count parameters are self-explanatory, so the description provides meaningful added semantics for the required parameters without being exhaustive.

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: 'Review bounded, non-person-linked room-type availability and prices'. It clearly distinguishes this from sibling tools by scope (one tenant-owned hotel, max 30 nights) and data type (room-type availability/prices, not guest data or schedules). It leaves no doubt about what the 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 gives no explicit guidance on when to use this tool versus siblings like list_daily_rates or list_room_types. The 'bounded' and 'non-person-linked' phrasing implies a limited query, but there is no explicit 'use this for X, use that for Y' or any alternatives mentioned. The agent must infer the appropriate context.

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?

Annotations already state readOnlyHint=true and destructiveHint=false, which cover the safety profile. The description adds meaningful behavioral transparency by enumerating what is excluded from results (identifiers, guest data, etc.) and the 31-day limit, which is valuable context beyond the annotations.

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 sentences with no filler. The primary function is stated upfront, and the exclusions are listed concisely. Every sentence earns its place and the structure is clean and easy to parse.

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 the presence of an output schema, annotations covering safety, and the description's explicit enumeration of operational counts and exclusions, the tool is fully specified for an agent to call correctly. There is no missing critical information such as return format or authentication requirements.

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 100%, so all three parameters are documented in the schema. The description adds some context about the date range ('at most 31 days') and aggregation by UTC day, but does not deeply elaborate on parameter formatting or relationships beyond what the schema already provides. Baseline 3 is appropriate.

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 ('Count'), the resource ('tenant-owned reservations and active stays by UTC day for one hotel'), and explicitly lists what it returns and what it never returns. This clearly differentiates it from siblings like get_hotel_availability or show_hotel_overview.

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 for operational aggregate counts but does not explicitly state when to use this tool over alternatives or when not to use it. It provides context about scope but no direct comparison or exclusion, so only inferred usage guidance is present.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds valuable behavioral context by explicitly listing what is never returned (free-text descriptions, facilities, photos, etc.), which helps the agent set expectations about the response. This goes beyond the annotations to clarify the scope of data, earning a 4.

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 sentences with zero fluff. The first sentence states the purpose, and the second lists exclusions. It is front-loaded and every word earns its place. No redundancy or unnecessary detail.

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 the tool's simplicity (one parameter, output schema present), the description is complete. It clearly states what is returned (bounded inventory metadata) and what is not, and the output schema covers the return structure. No additional context is needed for an agent to call this correctly.

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 only parameter, roomTypeId, is fully documented in the schema with a description and pattern. Schema description coverage is 100%, so the baseline is 3. The description does not add any additional semantics about the parameter beyond what the schema provides, so no extra credit is warranted.

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 verb 'Get' and the resource 'room type', and specifies 'bounded inventory metadata' which defines the scope. It also explicitly lists what is never returned, distinguishing it from sibling tools like list_room_types (which lists all) and get_hotel (different resource). The purpose is unambiguous and well-differentiated.

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 for fetching a single room type's bounded metadata, but it does not explicitly state when to use this tool versus alternatives like list_room_types. There is no mention of exclusions or alternative tools. The guidance is implied through the phrase 'for one organization-owned room type' but lacks explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 90-day max constraint and what fields are excluded from the response, which is useful behavioral context. But it does not mention pagination, response shape (though output schema exists), or any error conditions. Given the annotations, a 3 is appropriate.

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 a single well-structured sentence that front-loads the core purpose and then adds relevant exclusions. No wasted words, and it reads efficiently.

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 filtered-list tool with full schema documentation and an output schema present, the description covers the essential scope, constraints, and exclusions. Nothing an agent needs to call it correctly is missing.

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 100%, so each parameter (hotelId, ratePlanId, dateFrom, dateTo) already has a clear description and format. The description adds no per-parameter meaning beyond what the schema provides; it only reiterates the date-range and single-rate-plan context. Baseline 3 is correct.

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 action ('List') on a clear resource ('per-day price and stay restrictions of one organization-owned rate plan') with explicit scope (date range up to 90 days). It clearly distinguishes from siblings like list_rate_plans (which lists rate plans) and get_hotel_schedule_summary (which summarizes schedules), so an agent can tell this apart without opening any schema.

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 constraints: it applies to a single rate plan and a date range of at most 90 days, and it excludes guest, payment, channel, credential, and arbitrary metadata. However, it does not explicitly name alternative tools or state 'use this when...' vs. 'use that instead...'. Guidance is present but implicit, not direct.

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?

Annotations already declare readOnlyHint and idempotentHint true, so the description is not responsible for safety. It adds behavioral context: results are bounded/paginated, only active catalog items are included, and guest charges, folio data, display colors, and credentials are omitted. This exceeds what annotations convey.

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?

Single sentence that front-loads the action and resource, then appends the key exclusions. Every clause adds information and there is no redundant restatement of the title.

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?

With a full output schema and strong safety annotations, the key missing piece is parameter guidance, especially hotelId. The description covers purpose, scope, and exclusions well, so overall context is adequate though not perfect.

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 there are no property descriptions, so the description must compensate. It implies pagination via 'bounded page' but never explains limit, offset, or hotelId, and hotelId is a meaningful filter absent from the prose. Agents would need to rely on names and constraints.

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?

Description identifies a specific verb ('List'), resource ('active add-on / extra-service catalog'), and scope ('authenticated organization', 'bounded page'). It also names exclusions, which helps disambiguate from other catalog/hotel tools. This clearly differentiates it from siblings focused on hotels, rooms, rates, and availability.

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 gives clear context that this is for the extras/service catalog and notes that it returns only active, bounded results. It does not name alternative tools or explicitly state when not to use it, but the sibling set has no overlapping extras tool, so the context is sufficient. The exclusions of guest charges, folio data, colors, and credentials further warn about scope.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context beyond annotations by specifying that addresses, phone numbers, channel credentials, payment configuration, reminder configuration, and guest data are excluded, and that the scope is the authenticated organization. This sets clear expectations about data content.

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 a single, tight sentence that front-loads the core function, scope, and exclusions. There is no redundant or filler language; every phrase contributes to the agent's understanding.

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 the output schema and strong annotations, the description is largely complete: it names the resource, scope, pagination concept, and sensitive exclusions. It is slightly incomplete in not explicitly linking limit/offset to pagination behavior, but the schema constraints and standard conventions mitigate this.

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 limit or offset explicitly. 'Bounded page' hints at pagination, but the description does not explain how limit controls page size or offset controls position, so the parameters lack semantic guidance beyond their names and constraints.

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 and resource: 'List a bounded page of non-sensitive hotel metadata in the authenticated Hotelumo organization.' It clearly distinguishes this from siblings by scoping to hotels, a paginated list, and non-sensitive fields, while siblings like list_rooms or get_hotel target other entities or full details.

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 when a paginated hotel metadata list is needed, but it does not explicitly name alternatives or state when not to use this tool. It lists exclusions but leaves the agent to infer that sensitive details might come from get_hotel or similar siblings.

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?

Annotations already establish that the operation is read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: results are paginated ('bounded page'), scoped to one hotel, and deliberately exclude channel-manager mappings, integration metadata, and credentials. This tells the agent what it will not find in the response.

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 sentences, no filler, and the primary scope is front-loaded. The first sentence delivers the action, resource, scope, and pagination; the second adds the critical exclusions. Every clause 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?

For a simple read-only list endpoint with an output schema and safety annotations, the description is nearly complete: it identifies the resource, scope, pagination, and exclusions. It does not explain roomTypeId filtering or pagination defaults, but the schema and output schema fill most of the remaining operational detail.

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%, so the description carries some burden. 'Bounded page' partially conveys limit/offset semantics and 'one organization-owned hotel' clarifies hotelId, but roomTypeId receives no semantic explanation in the description. The gap is clear, though the parameter names are reasonably self-descriptive.

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 uses a specific verb and resource: 'List a bounded page of rate-plan pricing configuration for one organization-owned hotel.' This clearly distinguishes it from sibling list tools by scope ('one hotel') and content ('rate-plan pricing configuration'), and the second sentence states what is excluded, further sharpening the boundary.

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 context: it is for a single organization-owned hotel and returns a bounded page of rate-plan pricing. However, it does not explicitly state when to prefer this over the closely related sibling list_daily_rates, nor does it name any alternative or exclusion condition for tool selection.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful behavioral context beyond these: it specifies the operation returns a bounded page (implying pagination via limit/offset) and explicitly lists excluded data domains. It also states the scope is the authenticated organization, which informs authorization expectations. This aligns with annotations and adds value without contradiction.

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 a single, well-structured sentence that front-loads the core purpose ('bounded page of physical room status metadata') and then clarifies exclusions. There is no wasted wording; every clause adds information. It is appropriately concise for the tool's simplicity.

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 the tool has four optional filter parameters and no schema-level descriptions, the description is incomplete. It fails to explain how to filter by hotelId or roomTypeId, lacks pagination specifics (e.g., defaults, max values), and does not mention that limit/offset are used for the bounded page. While an output schema exists, it does not cover input parameter semantics. The description leaves an agent without enough information to correctly construct calls beyond simple unparameterized requests.

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 0% description coverage, so the description must compensate by explaining parameter usage. It does not mention any of the four parameters (limit, offset, hotelId, roomTypeId) or their semantics. Though parameter names are self-explanatory to a degree, the agent gets no guidance on how to use them (e.g., that hotelId filters rooms for a specific hotel, or that limit/offset control pagination). This is a critical 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 states the tool lists a bounded page of physical room status metadata within the authenticated organization, and explicitly enumerates excluded data categories (reservation, occupant, guest, access-control, channel). This distinguishes it from sibling tools like list_room_types (which returns room types, not physical room status) and get_hotel_availability (which focuses on availability). The verb 'List' with a specific resource makes intent unambiguous.

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 provides context by stating what data is excluded (reservation, occupant, etc.), implying that those aspects should be handled by other tools. However, it does not explicitly name specific alternative tools or provide clear 'when to use' criteria. An agent would need to infer that get_hotel_availability or get_hotel handles reservations, which is not stated. The guidance is adequate but not explicit.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations: the operation is scoped to the authenticated organization, and it explicitly excludes photos, public descriptions, rate-plan internals, channel mappings, and credentials. This prevents an agent from expecting sensitive or detailed fields and does not contradict the annotations.

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?

One tightly written sentence that front-loads the action and scope, followed by a valuable exclusion clause. There is no redundancy or 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?

With an output schema and strong annotations, the description covers the core behavior and important exclusions. However, the 0%-coverage input schema leaves hotelId semantics and pagination defaults unexplained, so an agent must still guess some operational details.

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, but it only hints at 'bounded page' for limit/offset and 'authenticated organization' for scope. It does not explain the optional hotelId filter, default paging behavior, or the meaning of offset/limit beyond what the constraint names suggest.

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'), a concrete resource ('room-type inventory metadata'), and a scope ('in the authenticated organization'). The 'bounded page' phrasing and exclusion list clearly separate it from single-item and sibling tools such as get_room_type, list_rooms, and list_rate_plans.

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 through 'bounded page' and 'authenticated organization', but it never states when to choose this tool over alternatives like get_room_type. It provides no explicit when-to-use or when-not-to-use guidance, so the agent must infer routing from the tool name and sibling list.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the snapshot is bounded to a next-seven-UTC-day sample, is tenant-scoped, and explicitly lists what is excluded. This goes beyond the annotations and helps set expectations about data scope and privacy.

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 a single, information-dense sentence that front-loads the core purpose and then lists exclusions. It is efficient and every clause earns its place, though the long exclusion list makes it slightly dense.

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 the output schema exists and annotations cover safety, the description is largely complete. It clearly defines scope, time window, and exclusions. It could be slightly stronger by explicitly naming sibling tools for comparison, but the aggregate-vs-detail distinction is sufficient for an agent to call it correctly.

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 100% and the single parameter hotelId is fully documented in the schema. The description doesn't add parameter-specific details, but with only one well-documented parameter, the baseline of 3 is appropriate.

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 ('Render') and resource ('bounded tenant-scoped operational snapshot for one Hotelumo hotel'), and clearly distinguishes it from siblings by emphasizing it is an aggregate overview that never exposes individual stays. This makes it easy for an agent to know what this tool does and how it differs from get_hotel or get_hotel_availability.

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 implies this is for a high-level operational snapshot of a single hotel, and the exclusions (no individual stays, no guest identities, etc.) signal when NOT to use it. It doesn't explicitly name sibling alternatives like get_hotel or get_hotel_availability, but the bounded aggregate scope is clear enough to guide selection.

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