get_customer_review

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

With readOnlyHint=true already covering the safety profile, the description adds real value: it discloses that the developer response is part of the return payload and flags that title/body/nickname are untrusted public text to be treated as data, not instructions. That prompt-injection guidance is behavioral context an agent cannot get from annotations. It omits any not-found/error behavior, keeping it below 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?

Two sentences, both front-loaded and purposeful: the first states the operation and payload, the second carries the security caveat. No 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?

For a single-parameter read with no output schema and readOnlyHint set, the description is nearly complete: it names the resource, hints at the return content, and warns about untrusted text. It could say slightly more about what the response contains or what happens for an unknown ID, but nothing essential 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% for the single reviewId parameter, so the schema already fully documents it; the description adds no format or constraint detail. Baseline 3 is appropriate when the schema does all the work.

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 (get a single customer review) plus the notable payload detail that the developer response is included when present. It is clearly distinguishable from the sibling list_customer_reviews by the word 'single'.

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 word 'single' implicitly contrasts with list_customer_reviews, giving a hint about when to prefer this tool. However, there is no explicit when-to-use statement, no prerequisites, and no named alternative, so usage is only implied.

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