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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the cache window (results from the last 24 hours served cheaper from cache), the billing model (maximum cost held up front, charged for what is returned, failed calls cost nothing), and the return contents (organic results plus classification tags and page features). This is exactly the behavioral context an agent needs before spending money on a call.

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?

Front-loaded with the action, then five compact sentences each covering a distinct concern (scope, return contents, add-ons, caching, billing). Slightly dense with pricing detail, but nothing is redundant with 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 usefully enumerates what comes back (organic results, classification tags, AI Overview, PAA, Knowledge Graph), and covers cost and cache behavior. The remaining gap is the undocumented gl/hl/location parameters, which an agent cannot infer.

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 only 11% (effectively just idempotency_key), so the description must carry the load and it does for depth (10-100), fresh (live vs cached), and local_pack/shopping. However gl, hl, and location are left entirely unexplained in both the schema and the description, leaving 3 of 9 parameters opaque.

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 ('Execute a full Google SERP search query') and scopes it with 'strict Google provenance (depth 10 to 100)'. It also implicitly differentiates from the extract_shopping_results / extract_local_places siblings by declaring local pack and shopping to be add-on flags on this call. It never names a sibling outright, so it stops short of a 5.

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 clear conditional guidance for the optional behaviors: set local_pack and/or shopping to include those add-ons, set fresh to true to search live rather than hit the 24-hour cache. There are no explicit exclusions or named alternative tools, so it is context without routing.

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