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

With annotations already declaring readOnlyHint=false, idempotentHint=true, and destructiveHint=true, the description adds genuinely useful behavioral context: it preserves original evidence and existing edits, incurs no download or charge, and requires creator review before the source is trusted. It does not explain failure modes or the implications of the destructiveHint flag (e.g., what can still be overwritten), and the 'preserves ... existing edits' claim sits in mild tension with destructiveHint=true, though it does not contradict it.

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 front-loaded sentences with the action first, then guarantees, then next steps; no filler. Slightly dense jargon ('observed readable page capture') but every clause carries information.

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?

An output schema exists, so return-shape explanation is rightly omitted, and the workflow sentence covers the important post-attach step. But for a 6-parameter tool with nested objects and four undocumented identifiers, the description leaves the agent without enough to construct a correct call, which is a meaningful gap given the tool's complexity.

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 only 50%, and the undocumented parameters are the most opaque ones: work_id, request_key, and the nested arguments object with operation_id and example_id. The description says nothing about any of these, so an agent gets no guidance on what identifies the work, what the request key is for, or where operation_id/example_id come from. With half the parameters lacking both schema text and description text, the description fails to compensate.

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 names a specific verb ('Attach') and a specific resource ('an observed readable page capture as a product source in this GenAds project'), which is concrete enough for an agent to distinguish it from siblings like native.genads_save_source or native.genads_read_source_page. It stops short of explicitly naming the alternative tools, but the resource and scope are unambiguous.

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 gives a usable post-call workflow ('Read the captured page, propose productFacts on the returned source, and leave reviewed false until the creator reviews them'), which tells the agent what to do after attaching. However, it never states when to use this versus native.genads_save_source, native.genads_read_source_page, or native.attach_project, and gives no preconditions or exclusions, so selection guidance is only implied.

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