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

The description carries a lot the annotations do not: which surfaces the row disappears from, what 'Not for us' means downstream, the early-return triggers (newer crawl reading its own page, position moving 3+ places or into another band with explicit band boundaries), UTC timezone, and that show_again reverses both marks. However it asserts 'idempotent' while annotations set idempotentHint=false, and it frames the operation as freely reversible while destructiveHint=true — a partial tension an agent should be warned about rather than told the opposite.

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?

Purpose and the three modes are front-loaded, and the parenthetical detail on bands and early-return triggers is genuinely load-bearing rather than filler. It is a single dense block with heavy nesting, which costs a little scanability but wastes almost nothing.

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?

A mutating, list-affecting tool with an output schema and annotations is covered well: effects on downstream briefing, reversal path, timezone, exclusion of done/tracked rows. Minor gaps remain — no statement of what happens if the keyword is not in opportunities, or whether market scoping affects which row is amended.

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%, so the baseline is 3, but the description adds real semantics: the constrained `when` vocabulary (tomorrow/week/month or YYYY-MM-DD bounded to tomorrow-through-one-year, UTC) and the behavioral consequence of `mark` values, including that `when` is irrelevant for the other marks.

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?

States a specific verb (set aside / restore) applied to a named resource (a content brief idea from cvl_seo_opportunities, improve or create row) and enumerates the three operations. It is clearly distinguishable from cvl_seo_opportunities (listing) and cvl_seo_opportunity_track (tracking), which are the nearest siblings.

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?

Each mark value is given a use case: not_for_us means never suggest again, later means hide until `when` or until data changes, show_again undoes either. It also states a guard condition (a done or tracked row is not changed). It lacks an explicit 'use cvl_seo_opportunity_track instead when...' routing sentence, so it stops short of a 5.

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