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

Beyond readOnlyHint/openWorldHint, it discloses provenance limits (prices are Booking.com landing-page samples from 'top hotels'/'most booked' blocks, usually 10-15 hotels) and the billing model: $0.002 USDC per successful call via x402 on Base/Solana/Arc, with failed calls not charged. This is exactly the kind of context annotations cannot carry.

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?

Front-loaded with the resource and returned fields, then caveats about price freshness and cost. Dense but nearly every clause earns its place; the enumeration of returned fields is slightly redundant given the output schema.

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 an output schema exists, the description need not explain return shapes, yet it still conveys coverage size (10-15 hotels), data freshness limits and payment mechanics. Nothing an agent needs to decide or call 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 coverage is 100%, so the schema already documents city, country and currency formats. The description only adds that the price is rendered 'in the currency you pick', a marginal semantic gain over the schema, so 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+resource (hotels featured on a Booking.com city page) and enumerates exactly what is returned: name, property id, sample nightly price, guest score, review count, stars, district, coordinates, review and URL. It also distinguishes its scope from a live date search, which separates it from price-search siblings like google_hotels_price.

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?

Explicitly frames the tool as a landing-page sample source, not a live date search, which tells the agent when not to use it. It does not name specific alternative siblings (e.g. travel_booking_com_reviews or google_hotels_price) by name, so routing is inferred rather than stated.

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