Search Console pages

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe to read. The description adds context that it focuses on high-impression low-CTR pages and mentions the ability to fix files in the editor, which implies editing capability but aligns with the read-only hint (edits happen in the editor, not via the tool). It doesn't provide additional behavioral details beyond schema, but given annotations, a 3 is appropriate.

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 two sentences, efficient and front-loaded with the core purpose. It includes a practical use case (fixing underselling titles/descriptions) and a note about being free, all without waste. Slightly less structured than the top-tier example, but still 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?

The tool is simple with one optional param, no output schema, and good annotations. The description covers the purpose, use case, and editing capability, which is sufficient for a read-only list tool. It lacks explicit mention of what the return data looks like, but that's acceptable given the output schema is absent and the tool is straightforward.

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?

The schema covers 100% of the parameter (range_days) with a description indicating 28 or 90. The tool description adds no additional meaning beyond the schema, so baseline 3 applies. The param is simple and well-documented, so no extra explanation is needed.

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 lists a user's pages ranked by search performance, with a specific focus on high-impression low-CTR pages and the ability to fix them in the editor. It distinguishes itself from sibling tools like gsc_overview and gsc_queries by focusing on pages and actionable title/description fixes, though it doesn't explicitly name an alternative.

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 implies the tool is used for identifying and fixing underperforming pages' titles/descriptions, but it doesn't explicitly state when to use it over siblings (e.g., gsc_queries for query-level analysis). It mentions it's free and uses the user's own data, but no exclusions or alternative tool mentions are provided.

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