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

Annotations provide readOnlyHint=false and openWorldHint=true, and the description adds substantive behavior on top: the '3 credits, charged only when a brief comes back' cost model and the explicit no-side-effect guarantee ('Creates nothing — no campaign, no product, no discovery'). This is exactly the cost and mutation context an agent needs and that annotations do not supply. No contradiction with the 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 longer than average but every sentence earns its place: purpose first, then cost, then side-effect guarantee, then when-to-use, then usage workflow. The front-loaded purpose and the clear escalation in emphasis make it well structured, with only minor redundancy around the credit note.

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 complexity (external web read, cost, no output schema), the description covers everything an agent needs: when to use it, what it returns (8-15 keywords, suggested title, search_context), how to process the result (cut to 3-8 keywords), and the cost condition. The absence of an exact return-structure spec is minor given the workflow guidance provided.

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% and the schema descriptions are already rich (platform enum with vocabulary explanation, product_id with its sharpening effect). The description adds modest value by tying the output (keywords/search_context) to create_campaign and implying how platform influences output, but does not meaningfully deepen per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb+resource: 'Read a product's website and propose the two fields create_campaign requires.' It names the exact deliverable (keywords, search_context, plus a suggested title), which makes the tool's function unambiguous and clearly positioned relative to the create_campaign sibling.

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?

Exceptionally explicit: 'USE THIS ONLY WHEN YOU CANNOT FETCH THE PAGE YOURSELF' states the primary condition, and the description further differentiates from in-conversation derivation (free, iterable, audience-aware) and gives the fallback trigger ('web access is unavailable or the fetch failed'). It even instructs the agent to disclose the credit cost before calling.

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