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

No annotations are provided, so the description carries the full behavioral burden, and it does well: it enumerates the four result categories and states that modifications are field-level old -> new, specifically including price and dates. It does not cover edge behavior such as what happens when no snapshot exists at or before `since`, which is the notable remaining gap.

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 dense sentences with no filler, and the scope (arrival month) plus the baseline dependency are front-loaded. The trailing sentence fragment 'The start-of-month correction pass in one call' is a little cryptic but still short and informative.

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 no output schema and no annotations, the description must explain return semantics, and it does so by naming every change category and the old -> new granularity. Entities/companies filtering and the missing-snapshot error case are the only unaddressed pieces, so the definition is largely complete for a 4-parameter diff tool.

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 the schema already documents all four parameters, and the description largely restates the `since` baseline semantics that the schema already defines. It adds arrival-month framing for `month` but says nothing about the `entity` and `company` filters, so it does not meaningfully exceed the schema baseline.

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 the resource (bookings for an arrival month) and enumerates exactly what the call produces: new, modified, cancelled and disappeared bookings. It also anchors itself against the sibling get_bookings, whose snapshot is the comparison baseline, so an agent can distinguish it from get_booking/stays_in_month. It is slightly implicit about the verb (a diff/comparison), which keeps it from a 5.

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 closing phrase 'The start-of-month correction pass in one call' implies the intended scenario (month-start reconciliation), and naming get_bookings hints at the prerequisite of an existing snapshot. However, it never states the prerequisite explicitly (a prior extraction must exist) nor names when to prefer plain get_bookings or get_booking instead. Usage is implied rather than spelled out.

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 supplied, so the description carries the behavioral burden, and it does usefully disclose the return payload (normalized row, price elements, raw Smoobu object). However it is silent on the operation's safety profile, permission requirements, and behavior for a missing/invalid id, which for an unannotated tool is a meaningful gap.

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?

A single dense sentence, front-loaded with the core purpose and then the payload breakdown. Nothing is wasted, though the parenthetical price-element jargon compresses a lot into one clause.

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 no output schema, the description correctly compensates by enumerating the returned fields, and the single required param is covered. Only error/not-found behavior and permission needs are unaddressed, which are minor for a one-param read lookup.

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 100% and the single id parameter is already documented in the schema as the Smoobu booking id (Position column). The description adds only the redundant 'by id' framing, so the schema does the real work; baseline 3 applies.

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 verb and resource ('Full detail of one booking by id') and enumerates exactly what the caller gets back, which clearly separates it from the plural get_bookings and the other list-style siblings. It stops short of an explicit contrast with those siblings, but the 'one booking by id' scoping makes the distinction inferable.

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 a single-record lookup keyed on id but gives no when-to-use guidance: it never says to reach for this only when the id is known, nor when to prefer get_bookings or changes_since instead. The agent must infer the selection criteria entirely from the tool names.

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 burden and does well: it discloses pagination ('Pages through everything'), the header-with-counts return shape, the non-silent handling of cancelled bookings, and the exact eom_blocks column ordering. It does not mention auth/permission needs or whether the pull is read-only, which caps it below 5.

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?

Dense but front-loaded: the date scope comes first, then pagination, then return structure, then the format special case. Sentences earn their place, though the domain shorthand 'ready for G5/N5/U5/Z5' assumes insider knowledge.

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 9-parameter tool with no output schema and no annotations, the description compensates well by describing the return shape (counts/totals header plus normalized rows) and the two output formats. Some gaps remain around epoch permissions and the snapshot/changes_since interplay, but the core call-and-interpret path is covered.

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 100% (baseline 3), and the description still adds value by restating inclusive date semantics and, importantly, explaining what format=eom_blocks actually emits (per-entity rows in EOM column order with DIRETTE having no commission). That output-side meaning goes beyond the schema's terse enum description.

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 verb (get bookings) and a precise scope: arrivals between arrival_from and arrival_to inclusive, or within month. It clearly distinguishes itself from get_booking (single) by describing range/month retrieval, though it does not explicitly name sibling 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?

Usage context is implied (date-range or month extraction for an EOM close), and 'Pages through everything' signals it handles large pulls. However, it never states when to prefer this over stays_in_month or changes_since, nor any exclusions, leaving the alternative-selection decision to inference.

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 exist, so the description carries the full burden. It usefully discloses that include_live triggers an external Smoobu /api/apartments call and that the result set is fixed at 14 properties, but says nothing about read-only safety, permissions, or response shape for a tool whose safety profile is undocumented.

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 short sentences with no filler; the return contents are front-loaded and the include_live behavior is appended where it belongs. The telegraphic style is dense but readable.

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, zero-required-parameter list tool with a fully documented schema and no output schema, the description supplies enough: what is returned, how filtering works, and the one parameter with a side effect. Only the absence of any read-only/permission framing leaves a small gap.

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 the schema already documents all three parameters, and the description largely restates the enum values verbatim. The one genuinely additive detail is the domain mapping 'Casa 4 Modern = PERLA', which helps interpret the entity values.

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 verb+resource (list the 14 properties) and enumerates the returned fields (Smoobu id, name, EOM entity, fiscal company/bsides account). It is clearly distinguishable from booking-oriented siblings like get_bookings and stays_in_month, though it never names an alternative explicitly.

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?

Usage is only implied: filter with entity/company, and set include_live to reconcile unmapped live apartments. There is no statement of when this tool is preferred over a sibling, no prerequisites, and no exclusions.

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 burden. It discloses what is checked (auth mode, Smoobu user, apartment count, rate-limit status) and a key security property ('Never returns keys'), which is valuable behavioral context. It does not explicitly confirm read-only safety or side effects, but 'Checks' strongly implies a non-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.

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

Two short sentences, front-loaded with the core behavior and followed by a critical output constraint. Every clause earns its place with no 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?

For a zero-parameter diagnostic tool with no annotations and no output schema, the description supplies the essential return fields (auth mode, user, apartment count, rate-limit status) and a security assurance. An agent has enough to decide to call it and interpret 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?

The tool takes zero parameters, so the baseline score of 4 applies. There are no parameter semantics to clarify, and the description appropriately focuses on what the tool inspects rather than inputs.

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 ('Checks') and resource ('each configured account') and enumerates exactly what is inspected: auth mode, Smoobu user, live apartment count, rate-limit status. This clearly distinguishes it from the booking/property siblings, which are all domain operations rather than diagnostics.

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 as a diagnostic/verification tool ('Checks each configured account') but does not explicitly say when to call it versus other tools, nor does it list prerequisites or exclusions. There are no obvious alternatives among siblings, so the implied context is adequate but lacks explicit guidance.

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 full disclosure burden. It does convey real behavior beyond the schema: pro-rata revenue treatment, night-overlap logic, and the three aggregation axes. But it says nothing about read-only nature, permissions, pagination, or how an empty month is handled.

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, front-loaded with the core computation and aggregation grain. The verification rationale in the second sentence is slightly self-referential but does justify the tool's existence, so little is wasted.

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-oriented analytics tool with no output schema and full schema coverage on inputs, the description supplies the essential missing piece: what the result contains (rows plus per-property/portal/entity totals). Pagination and exact return shape remain unstated, but that is a minor gap given the tool's reporting nature.

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%, with all four parameters documented including enum values, so the baseline is 3. The description's mention of totals 'per property, per portal and per entity' loosely maps to the entity/company filters and include_rows, but adds no syntax or format detail beyond the 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 computation (bookings overlapping the month, nights inside the month, pro-rated revenue) and its aggregation grain (per property, per portal, per entity). This clearly distinguishes it from siblings like get_bookings and get_booking, which return raw bookings rather than month-overlap analytics.

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 second sentence hints at a use case (reproducing Smoobu Analytics' convention so results can be verified), which implies when this tool is relevant. However, it never explicitly contrasts this with get_bookings or states when NOT to use it, leaving the agent to infer the choice.

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