Ask about a hotel

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description goes beyond them by disclosing the beta status, that answers are AI-generated from the hotel's data, and that allowWebSearch pulls in external web content. It does not discuss answer accuracy, latency, or error behavior, keeping it short of a 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?

The overview is front-loaded and scannable, but the body is padded with marketing-style bullets ('Natural language responses', 'Hotel context', 'Natural language') and example questions that repeat the same point several times. Headers help structure but a fair amount of text does not add selection or invocation value.

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 does explain the return shape (AI-generated, natural-language, hotel-specific answers), and it covers all three parameters and the beta caveat. Given the simplicity of a 3-parameter read-only tool, this is nearly complete; only error/edge-case behavior is unaddressed.

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 query, hotelId (MAQAMI format), and allowWebSearch (default false). The description restates these in prose ('Provide the hotelId and your question') without adding format or constraint detail beyond the schema, so the 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?

The overview states a specific verb+resource: answer natural-language questions about a specific hotel using AI. It is clearly distinguishable from sibling data tools like get_data_hotel (fetch hotel record) or get_data_hotels_semantic_search, since this is a free-form Q&A endpoint.

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 'When to Use' section gives concrete scenarios (hotel Q&A, information lookup, conversational interfaces, detailed inquiries), which sets clear context. However, it never names a sibling alternative (e.g. get_data_hotel for raw fields) or states when this tool is NOT appropriate, so routing guidance is incomplete.

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