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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: no SERP query is run, no credits are charged, null positions mean not found within the searched depth, the response's depth number should be used instead of config serpDepth, device columns are only printed when separately measured, and previousPosition may fall back to the earliest snapshot. This is rich and useful transparency.

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 long but well-structured and front-loads the core behavior, parameter modes, cost, and the alternative for triggering checks. The later caveats about null positions, depth, device columns, and previousPosition are valuable because there is no output schema, though the length and repeated emphasis make it slightly verbose rather than perfectly concise.

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?

No output schema exists, so the description carries the burden of explaining return semantics. It covers the return shape for both trackerId modes, null-position interpretation, depth reporting, device-column behavior, and previousPosition caveats. Given the complexity and lack of output schema, it is complete enough for an agent to call and interpret the result correctly.

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 the baseline is 3. The description adds meaning beyond the schema by explaining the behavioral difference of including trackerId: with it, the response returns the config plus the latest snapshot per keyword; without it, the tool lists all trackers in the project. projectId is not elaborated beyond the schema, but the trackerId semantics are clearly expanded.

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 states a specific resource and operation: read-only access to rank tracker configs and their latest results. It also distinguishes the two parameter-dependent modes, with trackerId returning config plus latest snapshot per keyword, and without trackerId listing all trackers in the project. An agent can tell this apart from create_rank_tracker or other rank tools without opening the schema.

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 explicitly explains when to provide trackerId versus when to omit it, and states that new checks are triggered via the dashboard rather than this tool. It also clarifies that the call is free, runs no SERP query, and charges no credits, which sets clear usage expectations. This is strong when/when-not guidance with an explicit alternative for triggering checks.

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