Create customer review response

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

Annotations only provide basic flags (readOnlyHint=false, destructiveHint=false), so the description carries some burden. It adds the behavioral constraint 'One response per review', which is useful context, but does not explain what happens if a response already exists, whether it replaces or errors, or any auth/rate-limit considerations. This is acceptable but not exhaustive.

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 tight sentences, front-loaded with the core purpose and containing no filler. The constraint and pointer to the sibling tool are conveyed efficiently, demonstrating excellent conciseness.

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 simple two-parameter tool with no output schema and neutral annotations, the description covers the essential context: what it does, the one-response limitation, and how to obtain the required ID. It lacks detailed error/edge-case behavior, but given the tool's low complexity, this is sufficient.

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%, with both parameters already described (customerReviewId from list-customer-reviews, responseBody visible to user). The description adds minimal parameter-specific value beyond the schema, mainly reinforcing the source of the review ID. Baseline 3 is appropriate as the schema handles 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?

The description uses a specific verb 'Reply' and resource 'App Store customer review', clearly distinguishing it from read-only siblings like list-customer-reviews. It also adds a key constraint (one response per review) and points to the prerequisite tool for obtaining review IDs, leaving no ambiguity about what the tool does.

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?

It explicitly instructs to use list-customer-reviews to get review IDs, establishing when this tool is appropriate. The 'One response per review' constraint helps the agent understand the operation's limits, though it does not name alternative tools or explicitly state when not to use it. This is clear context but lacks exclusion guidance.

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