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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, but the description adds nothing on top of them — no indication of how results are computed, what thresholds mean, or what the output looks like. With zero value added beyond structured data and a 6-parameter surface, this is a real gap.

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?

It is short, but that brevity reflects under-specification rather than economy — there is only a fragment with no sentence structure and nothing front-loaded beyond a category label.

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?

A six-parameter analytical tool with no output schema and no descriptions anywhere needs the description to carry meaning; instead it offers four words. Nothing an agent needs to invoke this correctly — what it returns, what the filters do, when to prefer it over siblings — is present.

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% for six parameters, including non-obvious ones like maxCtr (default 0.02) and minImpressions (default 100), whose filtering role is entirely unexplained. The description does not compensate at all, leaving the agent to guess what these thresholds filter.

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 is essentially a restatement of the tool name plus a category label ('Search Console insight'). It never states a verb or what the tool actually does (e.g., 'find queries where multiple pages compete for the same keyword'), so an agent must infer cannibalization semantics from the name alone.

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?

There is no when-to-use guidance, no mention of how this differs from siblings like striking_distance, low_ctr, or movers, and no prerequisites or exclusions. The agent gets no routing signal beyond the single word 'cannibalization'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: results reflect Google's index, not a live fetch, which tells the agent the answer may be stale. It stops short of permissions, quota costs, or what an inconclusive result looks like.

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?

One short sentence, front-loaded with the verb and resource, with the disambiguating parenthetical placed where it reads naturally. Nothing is padded, though the extreme brevity edges toward under-specification rather than tightness.

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 two required, undocumented parameters, no output schema, and no explanation of what the status response contains (indexed / not indexed / excluded with reason), the definition is too thin for a tool whose output shape the agent must interpret. The index-vs-live distinction is the only substantive detail provided.

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 carries the full burden for two required parameters, and it says nothing about either. It is unclear whether `site` is a domain property, a URL-prefix property, or a verified Search Console site, nor whether `url` must belong to that site.

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?

"Inspect Google indexed URL status" gives a specific verb (inspect) and a specific resource (a URL's indexed status in Google), and the parenthetical distinguishes it from a live crawl/fetch. It is clearly not one of the analytics-reporting siblings, though it does not name which sibling covers the live-test 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 phrase "(not a live test)" implies the right context: use this when you want Google's cached index verdict rather than fetching the page yourself. However, there is no explicit when-to-use, no prerequisite (e.g. the site must be verified in Search Console), and no named alternative among the siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the qualifier "submitted" — implying it returns sitemaps submitted via Search Console rather than all discovered sitemaps — but says nothing about pagination, result ordering, or whether entries include status/last-downloaded metadata.

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 definition is a single front-loaded phrase with zero filler, which is efficient. Its brevity, however, edges into under-specification rather than disciplined conciseness.

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?

For a tool whose only parameter is undocumented and which has no output schema, the description should at minimum state the identifier format for "site" and what a listed sitemap record contains. Neither is present, so the agent cannot call it confidently.

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 single required parameter "site" has 0% schema description coverage, and the description does not explain what form it takes (bare domain, full URL, or Search Console property identifier like sc-domain:example.com). With no compensating detail, the agent is left guessing at the most error-prone part of the call.

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?

"List submitted sitemaps" gives a specific verb (list) and resource (sitemaps), and the word "submitted" narrows the scope meaningfully. It does not, however, distinguish itself from siblings such as list_sites, which an agent could plausibly confuse with sitemap enumeration.

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?

There is no statement of when to use this versus list_sites or inspect_url, and no prerequisites (e.g., that the site must be verified in Search Console) are mentioned. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing further — no indication of pagination, result ordering, or whether the returned properties are URLs vs. domain properties — but for a zero-argument read-only enumeration the behavioral surface is small, so this is not a severe gap.

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?

A single front-loaded sentence with the resource named first and the access scope immediately after. No filler, no redundancy against the title 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?

For a simple zero-param list tool with no output schema, the description is only minimally sufficient: it does not say the result is the set of site identifiers the other tools consume, nor whether the caller should expect a complete or paginated enumeration. An agent can call it confidently but cannot predict the shape of what comes back.

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 tool takes no parameters, so there is no parameter meaning to convey; baseline is 4 per the zero-parameter rule. The description correctly implies no filtering input is expected.

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 concrete verb and resource ("List Search Console properties") plus the scope qualifier "accessible to your account." No sibling tool (search_analytics, inspect_url, list_sitemaps, etc.) lists properties, so an agent can distinguish it from all of them without opening any schema.

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 gives no when-to-use guidance: it never says this is the discovery step that yields the site identifiers required by search_analytics or inspect_url, and it names no alternatives or exclusions. Usage is only inferable from the verb "List."

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

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

The annotations establish a read-only, non-destructive, open-world operation, and the description does not conflict with them. Beyond naming Search Console, however, it adds no behavioral context about data scope, freshness, request limitations, or how results are selected.

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 text is short, but this is under-specification rather than effective conciseness. "Search Console insight" supplies minimal context and "low_ctr" merely repeats the identifier instead of providing a front-loaded operational summary.

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?

For a six-parameter external analytics tool with no parameter descriptions and no output schema, a bare label is inadequate for confident selection and invocation. The definition lacks the returned resource or metrics, filtering and date behavior, and the tool's relationship to sibling insights.

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%, yet the description explains none of site, days, maxCtr, startDate, endDate, or minImpressions. It does not even connect maxCtr and minImpressions to the low-CTR insight or clarify date-window behavior, so it fails to compensate for the undocumented schema.

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 adds only the broad Search Console domain and the label "insight" while repeating "low_ctr". It does not state what the tool searches or returns, nor distinguish it from search_analytics, striking_distance, cannibalization, or movers.

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?

An agent can infer a general interest in low click-through rate from the name, but the description gives no explicit use case or selection criteria. It provides no when-not guidance, prerequisites, or alternatives among the sibling analytics tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing about behavior beyond that — not the comparison window, the ranking basis, or the result shape.

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?

It is short and has no filler, but it is a bare fragment rather than a structured explanation, so brevity here comes from under-specification rather than efficiency.

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?

For a six-parameter, no-output-schema, insight-generation tool, the description omits the concept itself, the filtering thresholds, and the date-window interaction. An agent cannot reliably select or invoke it correctly from this.

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?

Six parameters with 0% schema description coverage, and the description explains none of them. Critical semantics are left opaque, such as what minImpressions and maxCtr filter, and how startDate/endDate interact with the days default.

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 is essentially the tool name restated: 'Search Console insight: movers'. It signals the data domain (Search Console) but never says what a 'mover' is (e.g., pages/queries with the largest position or impression change) or what the tool returns.

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?

No when-to-use guidance and no differentiation from the closely related insight siblings (low_ctr, striking_distance, cannibalization), which an agent cannot distinguish from this description. There is no exclusion or alternative mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral detail — that results are compared against the equal previous period — but says nothing about the rowLimit ceiling, pagination via startRow, or how comparison halves the result budget, all of which affect how an agent should call it.

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?

A single short clause-sentence with no waste, and the resource and the comparison behavior are front-loaded. The terseness is efficient rather than padded, though it borders on under-specification for a 9-parameter tool.

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?

This is a fairly complex query tool: 9 parameters, 0% schema coverage, an enum-constrained dimension list, and nested filter groups, with no output schema to explain returns. One sentence cannot cover that surface, and key mechanics — pagination, row caps, and filter semantics — are absent.

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% across 9 parameters, so the description must compensate and largely does not. It only implicitly touches two params — "top rows" gestures at rowLimit and "compare with the equal previous period" clarifies the compare flag — while site, type, dimensions, startRow, and the nested dimensionFilterGroups structure are left entirely undocumented.

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 gives a specific verb and resource ("Query top Search Console rows") plus a scope hint ("top" implies ordered/limited results) and the period-over-period comparison behavior. It does not distinguish this from siblings like movers, striking_distance, or low_ctr, which all operate on the same analytics data, so an agent cannot route confidently between them.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives. Given that six of the seven sibling tools (striking_distance, low_ctr, cannibalization, movers) are also Search Console analytics queries, the absence of any routing guidance is a real gap.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds only that this is an 'insight' (an analysis rather than a raw listing), but discloses nothing about thresholds, ranking, aggregation, or output shape.

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?

It is short, but not because it is efficient — it is under-specified. The one phrase present ('Search Console insight') is the only informative content and is not front-loaded with any actionable detail.

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?

For a six-parameter analytical tool with no output schema and zero schema descriptions, the description provides nothing an agent needs to call it correctly or interpret its results. It is completely inadequate for the tool's complexity.

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% across six parameters, and the description does not mention any of them. The meanings of maxCtr (default 0.02), minImpressions (default 100), and the interplay of days vs startDate/endDate are left entirely unexplained, which is a critical gap given the filtering logic defines the tool's output.

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 is essentially the tool name restated with the domain prefix 'Search Console insight'. It never explains what a 'striking_distance' insight computes (implied: queries with high impressions and low CTR in near-ranking positions), so the agent must guess the semantics of the jargon term.

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?

No when-to-use guidance, no exclusions, and no routing relative to siblings such as low_ctr, cannibalization, or movers, which appear to be similar insight tools. Nothing indicates how this differs from low_ctr in particular.

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