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

With no annotations provided, the description carries the disclosure burden and does add useful negative behavioral context: no deposits are created and no order is placed. However, it does not disclose whether the attachment is reversible or idempotent, what state changes occur to the offer or intent, or whether any permissions or preconditions beyond 'posted' apply.

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 short declarative sentences front-load the core action and then add two precise exclusions. Every sentence earns its place; there is no filler, repetition, or irrelevant detail.

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 mutation, the core action and side-effect negatives are present and likely sufficient for basic invocation. Yet with no annotations and no output schema, the description still leaves out observable behavior such as return value, idempotence, and failure cases like a non-posted offer, making it only minimally viable.

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?

The schema provides only bare string names with 0% description coverage, but the description's 'posted offer' and 'buy intent' map naturally to offer_id and intent_id and imply a posted-status precondition. It adds no further constraints, formatting, or relationship details, but the two-parameter shape is simple enough for an agent to infer the mapping.

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 verb 'Attach' plus the object 'posted offer' and target 'buy intent' identifies a specific operation. The exclusions 'No deposits. No order placement.' further distinguish it from commerce-related siblings like open_checkout.

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 gives the exact scenario for use: attaching an existing posted offer to a buy intent. The 'No deposits. No order placement.' clauses serve as implicit when-not guidance, signaling this is not a checkout or payment step, though alternative tools are not named explicitly.

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