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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds that optional related collections can be embedded rather than fetched separately, which is useful behavioral context, but says nothing about auth needs, rate limits, or not-found behavior.

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 terse sentences with the core action front-loaded and zero filler. The endpoint and embed note are compact add-ons rather than padding.

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 read-only fetch with fully covered parameters and annotations declaring the safety profile, this is nearly complete; the embedding hint clarifies the response shape somewhat. The absence of an output schema means return structure is only partly conveyed, which keeps it short of a 5.

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 four parameters are already documented in the schema. The description only restates the include_* flags as "opt into embedded charges/guest/tags," adding no syntax or defaults beyond the structured data. Baseline 3 applies when the schema does the heavy lifting.

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 (Fetch) and resource (a single booking) and pins the lookup to an id, which implicitly separates it from the list_bookings sibling. It even names the backing endpoint, GET /v2/bookings/{id}. It stops short of explicitly naming which sibling to use instead for bulk retrieval.

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?

"Opt into embedded charges/guest/tags" implies when to flip the flags, but there is no explicit when-to-use versus list_bookings or get_guest, and no prerequisites or error conditions. Usage 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.