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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no word on quota/rate limits, pagination behavior, which dimension values are valid, or how filters constrain results, all of which matter for a Search Console analytics call.

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 a single front-loaded sentence with no padding, so nothing needs trimming. However, brevity here comes at the cost of saying almost nothing beyond the name, so it is concise without being informative.

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?

An output schema exists, so return values need not be explained, but for a 10-parameter reporting tool the description is far too thin. The valid dimension values, filter format, date conventions, and pagination defaults are all left to inference.

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?

With 10 parameters and 0% schema description coverage, the description must carry the burden, but it only vaguely gestures at the 'dimension' parameter. start_date/end_date formats, the filters array structure, row_limit/start_row pagination semantics, search_type defaults, and data_state are all undocumented anywhere.

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 sentence largely restates the tool name: 'get_dimension_breakdown' becomes 'Get a single-dimension ... breakdown.' The only added information is the domain ('Search Analytics'), which does not distinguish it from siblings like query_performance, get_top_queries, or get_top_pages, whose names suggest overlapping reporting behavior.

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 guidance on when to use this tool versus query_performance, get_top_queries, or get_top_pages, nor any mention of prerequisites or exclusions. An agent must guess which reporting tool to select.

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, idempotentHint, openWorldHint with destructiveHint=false, so the safety profile is well covered and the bar is lower. The description adds nothing beyond restating the aggregate-over-date-range idea: no mention of whether metrics are totals versus averages, data freshness, or result-size limits.

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 no filler or redundancy. It is efficient but under-specified rather than over-long, so the only structural issue is missing content, not wasted content.

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?

An output schema exists, so return values need not be explained, but the definition is otherwise thin for a six-parameter tool with 0% schema coverage and five plausible sibling alternatives. An agent cannot tell from this text how search_type or data_state change results or how the summary differs from query_performance.

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, so the description must compensate and it largely does not. Only the date-range intent of start_date/end_date is implied; account, site_url, data_state, and especially search_type (defaulting to 'web') carry no meaning anywhere.

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 states a specific verb and resource ('Get aggregate performance metrics') scoped by date range and property, which is clear enough to act on. However, it never distinguishes itself from siblings such as query_performance or get_dimension_breakdown, so an agent could reasonably pick the wrong one for a summary-only request.

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. With six sibling tools covering performance querying, top queries/pages, and dimension breakdowns, the description should say this returns totals-only and route users elsewhere for per-item rows, but it does not.

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 this as a safe, read-only, idempotent, open-world operation, so the description's safety burden is low. However, it adds almost no behavioral context: it does not explain what "top" means, how rows are ordered, how pagination works, or what data_state and search_type affect.

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 a single front-loaded sentence with no wasted wording. Its brevity is efficient, though it also reflects under-specification rather than rich concision.

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 moderately complex reporting tool with nine parameters, pagination controls, filters, and multiple scope-related options. The output schema and annotations help, but the description omits critical selection and interpretation details an agent would need to invoke 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?

Schema description coverage is 0% across nine parameters, so the description must compensate and does not. It vaguely implies a property and date range but does not clarify account versus site_url, filters format, row_limit/start_row pagination, data_state, or search_type.

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 states a specific verb and resource ("Get top page rows") and scope ("for a property over a date range"). It is clear enough to identify the tool, but it does not distinguish it from siblings such as get_top_queries or get_dimension_breakdown.

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 guidance on when to use this tool versus alternatives. It does not mention get_top_queries, get_dimension_breakdown, or any conditions under which top pages should be preferred.

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 safe, idempotent read, while the description adds only basic property and date-range scoping. It does not explain what makes a query 'top,' how results are ordered, or how filtering and pagination affect the retrieval.

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 single sentence is front-loaded, readable, and free of filler. Its brevity is efficient, although some additional detail is needed elsewhere to make the tool reliably invocable.

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 output schema and safety annotations reduce some documentation burden, but the description is insufficient for a nine-parameter tool whose schema provides no parameter descriptions. Missing ranking semantics, filter structure, property-selection rules, pagination behavior, and sibling routing are material gaps.

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 description loosely supports the date parameters and property selection, but does not specify date formats or distinguish account from site_url. With 0% schema description coverage, filters, row_limit, start_row, data_state, and search_type remain effectively 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 uses a clear verb and resource—getting top query rows—and adds property and date-range scope. It implies a distinction from get_top_pages by focusing on queries, but does not explicitly differentiate itself from query_performance or get_dimension_breakdown.

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 wording implies use when an agent wants query-level results for one property and period. It gives no explicit selection criteria, prerequisites, or guidance on when to use a sibling tool instead.

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, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior by confirming nothing leaves the machine (no browser launch, no Google API call), but it says nothing about what constitutes a healthy vs unhealthy result or how failures surface.

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 tight sentence with the key constraint front-loaded after the verb phrase; no filler or redundancy. It could have spent a few more words on the account parameter at no real cost to brevity.

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?

An output schema exists, so return values need not be described, and the offline/local behavior is well covered. What remains missing is any explanation of the 'account' argument and any explicit trigger condition for running a health check, which for a diagnostic tool is a meaningful omission.

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 'account' parameter has 0% schema description coverage and the description never mentions it, so the agent has no guidance on what account values are accepted (email? index? alias?) or what happens when it is omitted. This is the main semantic gap in the definition.

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 ('Check') and specific resources ('local configuration and saved sign-in status'), and adds a scope boundary ('without opening a browser or calling Google') that separates it from the data-querying siblings like list_sites or query_performance. It doesn't name a sibling explicitly, but the local/offline framing makes the distinction clear.

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?

Usage is only implied: the phrase 'saved sign-in status' hints at diagnosing auth/credential problems, but there is no explicit 'use this when X' or 'use this before calling Y'. An agent must infer the diagnostic intent from context rather than being told.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description's 'does not request indexing' largely restates readOnlyHint rather than adding new behavior, and it says nothing about quota, per-property auth, or failure modes for inaccessible properties.

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 compact sentence with the primary action front-loaded and the disambiguation clause second. Every word earns its place; nothing is padded or redundant.

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 output schema exists, so return values need no explanation, which helps. But with four parameters at 0% description coverage and no annotations for auth or quota, the description leaves real gaps around language_code and account/property selection that an agent would have to guess at.

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 burden for four parameters and mostly does not. 'Within an accessible property' loosely gestures at site_url/account, and inspection_url is self-evident, but language_code is never mentioned and the account-vs-site_url relationship is unexplained.

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 specific verb and resource: 'Read Google's indexed status for a URL within an accessible property.' It also preempts a likely confusion by stating 'does not request indexing.' Sibling differentiation is only implicit, since none of the listed siblings (query_performance, get_top_queries, list_sites) overlap in 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?

The phrase 'within an accessible property' implies a precondition (the property must be accessible), and the negative clause excludes the request-indexing use case. However, there is no explicit guidance on when to prefer this over sibling tools, or what to do when a property is not accessible.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds materially new behavior: it may open a browser sign-in flow and persist or refresh a local token. It also explicitly bounds the side effects by stating it does not modify Search Console properties, resolving the apparent tension between a token write and readOnlyHint=true.

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?

Three short sentences, front-loaded with the primary action and the sequencing constraint, followed by the side effect and the explicit non-effect. Nothing is redundant or padded.

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?

An output schema exists, so return values need no explanation, and the description covers the auth side effect, the non-destructive scope, and when to call it. The only remaining gap is the meaning and accepted values of the optional `account` parameter.

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 the single `account` parameter, so the description carries the burden of explaining it. It only implies that the account is a selector ("the selected Google account") and does not say what values are accepted, whether it is an email, an index, or what happens when it is omitted.

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 specific verb and resource ("List properties available to the selected Google account") and implicitly distinguishes itself from siblings by positioning it as the step "before choosing a site to analyse", which the sibling tools (get_site_summary, query_performance, etc.) all require. It never names a sibling explicitly, so it falls short of full differentiation.

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?

Gives clear sequencing guidance: run this before analysing a site, because it establishes which properties are available. It does not state any when-not-to-use condition or name the alternative tools, so there is no explicit alternative routing.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of row_limit/start_row pagination behavior, the 1000-row default, data freshness (data_state), or Search Console API quota constraints that materially affect calls.

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 sentence with no filler, and the resource is front-loaded. It is concise to the point of being under-specified for an 11-parameter tool, so brevity here costs more than it saves.

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?

An output schema exists, so return values need not be explained, but the request side is badly under-covered: 11 parameters at 0% schema description coverage and no guidance on which sibling to prefer. For a complex, open-ended query tool this leaves too much undocumented.

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 11 parameters, so the description carries the full burden and only names two of them ('dimensions', 'filters'). It says nothing about site_url vs account selection, search_type's default of 'web', aggregation_type, data_state, or the paging pair start_row/row_limit.

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 concrete verb ('Query') and resource ('Search Analytics performance data') plus the two levers the tool exposes (dimensions, filters), so an agent can tell it retrieves performance metrics. It does not, however, distinguish this from siblings like get_top_queries, get_top_pages, or get_dimension_breakdown, which appear to be convenience wrappers over the same surface.

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 generic query tool versus the more specific siblings, and no prerequisites or exclusions are mentioned. The agent must infer routing from the tool names alone.

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