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

Annotations already disclose destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the call must carry an "exact observed revision" — implying optimistic-concurrency checking, and the "Zero creates a resource" line implies a create-vs-update branch. It does not explain what gets overwritten on a mutation, what a revision-mismatch failure looks like, or why the operation is flagged destructive.

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 short sentences, front-loaded and free of filler, which is appropriate for the size. The second sentence, "Zero creates a resource," is syntactically ambiguous — the reader cannot tell whether "zero" is the revision, the count of matches, or a return value — so the brevity costs clarity rather than serving it.

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 destructive, open-world mutation with a nested object payload and an output schema, the description omits the essentials: what a "source" record contains, the optimistic-concurrency contract on expected_revision, the skill-proof requirement, and how it differs from native.genads_save_source. The presence of an output schema excuses it from documenting return values, but nothing compensates for the missing call contract.

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 50%, so the baseline is 3; the description touches expected_revision indirectly through "exact observed revision" and "Zero creates a resource," which is the single most important semantic for that field. But with 6 parameters, a deeply nested body (kind, rights, provider, pageEvidence, productFacts, reference union), and required read_skills/request_key/expected_catalog_version, the description adds no meaning beyond that one hint.

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 verb ("Save") and a resource ("a source in a linked GenAds project"), which is more than a restatement of the name. However, it never distinguishes this tool from the near-identical siblings in the save family (native.genads_save_source, native.save_genads_brief, native.save_genads_concept, native.save_genads_media, native.save_genads_pack), and the phrase "using its native command" describes mechanism rather than purpose, leaving the agent unsure which save tool to pick.

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?

There is no explicit when-to-use guidance, no prerequisites (e.g. the project must already be linked via native.link_genads_project), and no exclusion naming an alternative. The only orienting statement is the cryptic "Zero creates a resource," which hints at upsert-on-create semantics for expected_revision but never says so plainly or says which parameter carries the zero.

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