Raw Search Console API call

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, setting the safety baseline. The description adds useful non-obvious behaviors: the Bearer token is added automatically, the method defaults to GET, and specific endpoints (sites.add, sitemaps.submit) are PUT with no body and return an empty response on success. This enriches the agent's understanding beyond annotations.

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—roughly three sentences—and front-loaded with the core 'escape hatch' purpose. Every sentence adds value: path format, URL encoding, query strings, auth, default method, and PUT endpoint notes. No wasted words.

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?

Given this is an open-ended raw API tool, the description covers the essentials: usage scope, path encoding, auth, method defaults, and specific endpoint quirks. There is no output schema, but the tool's raw passthrough nature makes return format self-evident. The description is sufficient for an agent to use it 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?

The schema already has 100% coverage, but the description goes further by explaining that siteUrl and feedpath are path segments requiring encodeURIComponent, that paths may include query strings, and clarifies body usage (POST only, PUT endpoints take no body). This added semantics is critical for correctly constructing the path parameter.

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 opens with 'Escape hatch to call any Google Search Console API path directly', which states a specific verb ('call') and resource ('any Google Search Console API path'), clearly distinguishing it from the typed sibling tools. The title 'Raw Search Console API call' reinforces this purpose.

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 says 'for requests the typed tools don't cover', which tells the agent when to use this tool versus the typed alternatives. It also explains that there are two API surfaces ('webmasters/v3/...' and 'v1/...') and provides an example path, giving clear contextual guidance.

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