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

Goes well past the annotations: quantifies the work (up to 9 live SERP calls plus 9 reverse-geocode calls), warns about tight rate limiting, and names the exact failure mode (SEO_DATA_UNAVAILABLE where the provider cannot override location per point). Annotations already cover the safety profile (non-read-only, non-idempotent, open-world), so this added cost/limit/error detail is genuine extra value.

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?

Three tight sentences, front-loaded with what the tool does, then the output semantics, then the failure mode and rate-limit warning. No filler and no repetition of the schema or annotations.

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?

With no output schema, the description does carry the key return semantics (organic rank per grid point) and the failure mode. It stops short of saying whether the run persists results for later retrieval via get_local_rank_grid, and gives no sense of the response shape or grid size, which an agent planning a follow-up call would want.

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% and both parameters are documented there, including the provenance of configId and projectId. The description adds no syntax, format, or constraint information about the parameters, so the baseline of 3 is correct.

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 and resource ('Runs a geo-grid rank check now') and pins down the exact semantics of the output: organic rank at each grid point, never local-pack position. That distinction cleanly separates it from run_local_pack_rank_check and from the read-side get_local_rank_grid without the agent needing to open either 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?

Gives an explicit when-not instruction ('Tightly rate limited, so do not loop it') and 'now' implies immediate execution rather than retrieving stored history. It never names the alternatives it competes with (get_local_rank_grid for stored results, create_local_rank_grid_config for setup), so the routing is implied rather than spelled out.

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