Delivery: prohibit acceptance [sandbox]

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

The description adds value beyond annotations by stating the tool is a cancellation step, returns a success status, and is partner-only. Annotations already indicate it is destructive and not idempotent. The description adequately discloses behavioral traits without contradicting annotations.

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 description is concise, with two sentences that efficiently convey the core action, effect, and usage constraints. No unnecessary words.

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 the tool's simplicity (3 parameters, no output schema), the description covers purpose, flow context, and access restrictions. It could mention the response format in more detail, but the current content is sufficient for correct usage.

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 baseline applies. The description does not provide additional meaning for parameters beyond what the schema already offers.

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 clearly states the tool's purpose: 'Prohibits the delivery service from accepting a parcel from the sender — the parcel will not be taken into processing.' It distinguishes itself from siblings by noting it is a step in the parcel-cancellation flow and pairs with delivery_sandbox_cancel_parcel.

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 description provides explicit context: it is part of the parcel-cancellation flow and should be used in conjunction with delivery_sandbox_cancel_parcel. It also specifies that it is for delivery-service PARTNERS only, with regular sellers receiving 403/404 errors.

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