gsc_queries_for_page

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a valuable behavioral trait: the returned queries reflect what the page actually earns impressions on, not necessarily what it was written to target. It also discloses that page_url can be an exact URL or a loose substring. It does not cover details like read-only guarantees or date-filter behavior, but the core interpretation insight is well conveyed.

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 compact and front-loaded: the first sentence states the core output, the second explains the practical use case, and the Args section covers the key parameter. Every sentence earns its place with no filler or repetition.

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?

The description is adequate for the main use case and the required page_url parameter, and an output schema exists to explain return values. However, it leaves several optional parameters undocumented and does not clarify how date ranges or site_url affect results. For a 6-parameter tool with no annotations, this creates meaningful gaps for an agent trying to make non-default calls.

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 0%, so the description must compensate by explaining the parameters. It only documents page_url, adding the useful exact-or-substring matching semantics, but says nothing about days, limit, end_date, start_date, or site_url. With six parameters and five left unexplained, the description falls short of what an agent needs to confidently tune or filter the query.

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 identifies the tool's purpose: retrieving every query a specific URL ranks for. It adds a concrete use case ('before rewriting a page') and distinguishes itself from the broader GSC sibling tools by narrowing scope to a single page. However, it does not explicitly name a sibling alternative, so it stops just 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?

The description explicitly tells the agent when to use the tool: 'Use this before rewriting a page.' It also explains why, noting the page's actual impression-earning queries often differ from its intended target keywords. It does not mention exclusions or compare against alternatives like gsc_top_queries or gsc_search_analytics, so it lacks full when-not-to-use guidance.

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