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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description adds a detailed data accuracy contract, instructing the agent not to invent or infer missing metrics, to label derived metrics with formulas, and to state unavailability. This goes well beyond the structured annotations and clarifies permissible reasoning and output expectations.

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 verbose, packing multiple cross-tool instructions (chart_render usage, response suffix, data accuracy contract) into the tool description. While each section has value, it is not concise and mixes concern that might belong in system prompts or separate guidance. The purpose is front-loaded, but the overall structure is dense.

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 the schema covers parameter specifics and action descriptions (e.g., get_performance lists metrics, inspect_url notes return status), and the description adds behavioral rules for data handling and chart_render routing, the tool is adequately specified. Some return format details are missing, but the schema's action descriptions partially cover them, and annotations cover safety. Overall, sufficient for correct invocation.

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 coverage is 100%, with the action enum and params object fully described in the schema. The description text adds no additional meaning to the parameters beyond what the schema provides. Per the rubric, baseline 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 explicitly states the tool provides SEO and search performance data from Google Search Console, enumerating metrics (clicks, impressions, CTR, position) and actions (sitemaps, URL inspection). This clearly differentiates it from other connectors like GA4, Ahrefs, or Semrush by naming the specific data source and scope.

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 provides explicit guidance to use chart_render for visualizations and mandates a response suffix, which effectively routes follow-up actions. However, it does not explicitly state when to prefer this tool over alternatives like Ahrefs or Semrush, though the source-specific mention implies the context. The absence of clear exclusions keeps it from a 5.

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