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

With no annotations provided, the description carries the full burden and does so admirably. It discloses that there is no built-in CTR table, that positions between curve points are linearly interpolated, that positions beyond the curve clamp and are counted in clamped_row_count, and that calibration output reports deviation from observed clicks. This goes far beyond a basic summary.

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 front-loaded with a clear purpose, followed by a concise rationale, guidance, and key behavioral details. Every sentence earns its place; the tone is direct and avoids fluff. At roughly 150 words, it is appropriately sized for the tool's complexity.

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 tool with nested objects, no annotations, and no output schema, the description covers all critical context: purpose, why there is no built-in curve, how to source the curve, interpolation/clamping behavior, and diagnostic output. It even names clamped_row_count and calibration reporting. This is well-rounded and complete.

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 100%, so baseline is 3. The description adds meaning by emphasizing that the ctr_curve must be user-supplied and based on real measurements, and it clarifies behavior around interpolation/clamping that connects to the rows and curve parameters. It does not elaborate on target_position semantics beyond what the schema offers, but the overall context is enhanced.

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 clearly states the tool's function: 'Project how many clicks a set of query rows would earn at a target position instead of their current position, using a CTR curve THAT YOU SUPPLY.' This is specific and the verb 'project' plus the resource 'clicks from CTR curve' distinguishes it from siblings like share_of_voice or impression_weighted_position.

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 provides strong contextual guidance: it explicitly instructs the user to supply their own measured curve, warns against built-in tables ('every published average-CTR-by-position table is a third-party estimate'), and suggests Search Console as an honest source. It does not explicitly exclude alternatives among sibling tools, 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.