AskWatch Google Search Console MCP

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

Annotations already mark the tool as read-only and non-destructive. The description adds a useful behavioral limitation—the split is only as good as the supplied brand terms and that misspellings/domain names catch more—but it does not describe output format or data source. Adequate but not rich.

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?

Two sentences with no filler. The core concept is front-loaded and the caveat is directly relevant. Every sentence earns its place.

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 description plus the fully documented schema and annotations give an agent enough to select and invoke the tool. The output format is not described, but for a simple split tool the result is reasonably implied.

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%, so the schema already documents all parameters. The description adds value by advising that including misspellings and domain names in brand_terms captures more branded queries, going beyond the schema examples.

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's action: splitting search data into branded versus non-branded based on supplied words. It is specific enough to be understood without opening the schema, though it does not explicitly differentiate from sibling tools by name.

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 a caveat about term quality, but no guidance on when to choose brand_split over alternatives like find_cannibalization or query. There is no explicit when-to-use or when-not-to-use context.

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 establish read-only and non-destructive behavior, so the bar is lower. The description adds useful behavioral context: small rows are filtered out and comparison is against the preceding period. It doesn't explain exactly how the 'previous period' is defined, but this is a reasonable disclosure beyond the 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?

Two short, front-loaded sentences with no filler. The core concept comes first and the example question follows. Every word earns its place, and the description is appropriately sized for the tool's complexity.

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 schema covers all parameters, but there is no output schema and the description does not describe what rows are returned or how the previous period is determined. For a tool with seven parameters and sibling comparisons, a bit more context about output shape or period boundary logic would strengthen completeness. It is adequate but has clear 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?

Schema description coverage is 100%, so every parameter is documented. The description does not add any parameter-specific detail beyond what the schema already provides. A baseline score of 3 is appropriate because the schema carries the full semantic load.

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 communicates the core function: comparing the current period with the previous one and surfacing gains/losses. The example question 'what dropped in the last 28 days' gives a concrete entry point. It doesn't use a strong verb+resource phrasing and doesn't explicitly differentiate from siblings like find_opportunities or top, but the comparison concept is distinct enough.

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 usage through the example question, indicating it is for change-analysis questions like 'what dropped'. However, it provides no explicit guidance on when to prefer this over alternatives, no exclusions, and no mention of sibling tools or conditions that would make another tool a better fit.

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 readOnly and destructive safety, so the main added behavior is the selection filter: only queries with multiple competing pages are returned. The description does not disclose details like ordering, default metrics, or output shape, but with annotations present this is acceptable.

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 one tight sentence that front-loads the core result and includes the key qualifier 'more than one page'. No filler or repeated schema 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?

For a report tool with no output schema, the description gives only a high-level return concept ('with how each page does on them') and does not specify metric fields or ordering. The parameter schema documents has_more and defaults, which helps, but the absence of an output schema leaves the response shape partly underspecified.

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 descriptions cover 100% of the six parameters, including defaults and overrides such as start_date overriding days and min_impressions being per page. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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 identifies the output: queries where multiple site pages are shown, with per-page performance. The title 'Pages competing for one query' captures the cannibalization concept and separates it from single-query or single-page tools, though it does not explicitly name a sibling 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 intended use case is implied by the cannibalization framing and by the 'more than one page' condition, but the description gives no explicit when-to-use guidance or comparison to page_queries, query, or find_opportunities. An agent must infer when this report is preferable to its 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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the ranking range (5-20), the impression threshold concept, and the CTR comparison criterion, which go beyond the annotations. It doesn't contradict annotations and provides useful execution details.

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, well-structured sentence that front-loads the core criteria (rankings 5-20, impressions, CTR) and concludes with the actionable outcome. There is no fluff or redundant information; every clause earns its place.

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 has 6 optional parameters and no output schema. The description explains the tool's purpose and criteria but does not describe the return format (e.g., whether it returns a list of keywords, URLs, or structured data). For a query tool that returns results, this omission is noticeable, though the name and purpose imply the nature of the output. Given the simplicity and read-only nature, it is adequate but not complete.

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 input schema covers 100% of parameters with descriptive text, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema; it mentions criteria like 'plenty of impressions' which loosely relate to min_impressions but without specific syntax or additional meaning. Since the schema already documents each parameter, the description's contribution here is minimal.

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 ('queries') and resource ('ranking 5-20 with plenty of impressions but a click-through rate below what is typical at their position'), and clearly frames the purpose as identifying where a title or snippet rewrite is worth the most clicks. This is precise and distinguishes it from siblings like find_cannibalization or page_queries, which address different optimization angles.

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 provides clear context on the intended use case—finding CTR improvement opportunities—but does not explicitly mention when not to use it or name alternative tools. It implies the usage scenario well, yet lacks explicit exclusions or sibling comparisons, so it falls short of a 5.

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 declare readOnlyHint=true and destructiveHint=false, so the tool is safe to call. The description adds that it reports data from the 'URL Inspection API', which implies a read-only, query-based behavior. It also specifies the output fields (indexed, last crawled, canonical), which is useful context beyond the annotations. However, it doesn't disclose potential rate limits or authentication requirements, but given the read-only nature, this is minor.

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, concise sentence that front-loads the core purpose and output. It avoids fluff and every word adds value. It is well-structured and immediately actionable.

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 2 parameters, a full schema, and no output schema, so the description doesn't need to explain return values. The description covers the key behavioral aspects (what it returns) and usage context. It is complete for an agent to call it correctly, though it could mention the 'site' parameter's optionality in the description, but the schema already does that.

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 100%, so both 'url' and 'site' are fully described in the schema. The description adds minimal additional parameter context; it mentions the 'site' parameter as 'Search Console property' in the schema but doesn't specify the format in the description. The baseline is 3 because the schema does the heavy lifting.

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 ('inspect'), a specific resource ('URL'), and the exact output (indexed status, last crawl, canonical). It clearly distinguishes itself from sibling tools like 'top' and 'query' which are about performance and rankings, not index status. The title reinforces the purpose, and the description adds detail beyond the title by mentioning the three key data points returned.

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 clearly states when to use this tool: when you need index status for a specific URL. It implicitly contrasts with siblings like 'page_queries' and 'query' which are about search queries, and with 'find_cannibalization' which involves multiple URLs. However, it doesn't explicitly state when NOT to use it (e.g., for bulk indexing or for performance metrics), but the context is clear enough.

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 provide readOnlyHint=true and destructiveHint=false, and the description adds a concrete operational limitation: submitting sitemaps is not possible with read access. It also names the external Google Sitemaps API source, adding useful context beyond the structured 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 two sentences with no redundancy: the first identifies the resource and data returned, and the second clarifies the read-only constraint. It is concise and front-loaded.

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 tool with one optional parameter and annotations covering the read-only/non-destructive profile, the description is nearly complete. It conveys the main output (submitted sitemaps and status) but does not detail the response shape or status values, which would be more critical without an output schema.

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 documents the single optional 'site' parameter with its exact format and optionality, so schema description coverage is 100%. The description adds the property framing but no new detail about the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 that the tool returns sitemaps submitted for a property and their status, tying it to Google's Sitemaps API. It clearly identifies the resource and scope, and the tool can be distinguished from siblings like list_sites by the sitemap-specific focus, though it does not explicitly name alternatives.

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 its use case: viewing submitted sitemaps in a read-only context, and it explicitly says submission is not possible with read access. However, it does not state when to prefer this tool over siblings or provide explicit exclusion criteria, leaving usage guidance mostly implicit.

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 establish readOnlyHint and destructiveHint, and the description aligns with them and adds that the returned output is limited to exact string property values. It does not mention potential pagination or empty results, but for a simple read-only list tool this is adequate.

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?

Two sentences, no filler, and the most important semantic point—the exact site argument strings—is front-loaded and reinforced. Every sentence contributes useful information.

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 zero-parameter read-only listing tool, the description is complete: it explains what is returned, where it comes from, and the practical purpose of the returned values. No output schema exists, but the description supplies the needed return-value semantics.

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 has zero parameters, so the baseline is 4; the description does not need to explain parameters. It also clarifies the relationship between its output and the site argument used elsewhere, which adds meaningful context.

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 identifies a specific verb and resource: listing the Search Console properties this connection can read from Google's Sites API, and clarifies that the result is the exact strings used for the site argument. It is clear but does not explicitly differentiate itself from siblings such as list_sitemaps or site_overview.

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 statement 'These are the exact strings the site argument takes' signals the intended use: retrieve allowed site identifiers before supplying the site argument to other tools. It gives clear context but does not explicitly state when to prefer this tool over alternatives or when not to use it.

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 establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds no behavioral detail beyond the annotations—no mention of return shape, pagination, site-scoping behavior, or default date handling—leaving it at baseline.

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 only one sentence, which is concise in length, but it is awkwardly worded and lacks a clear predicate. A clear sentence like 'Returns search queries that match a specific page' would be both shorter and more useful; the current sentence is under-specified rather than well-structured.

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 7 parameters, no output schema, and several sibling tools, the definition needs to clarify what the response contains and how this tool differs from the broadly named query sibling. The schema documents mechanics, but the description leaves the core semantics and output shape ambiguous.

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 100%, so the seven parameters and their defaults, bounds, and enum are fully documented there. The tool description adds nothing about parameter semantics, so the schema carries the burden and baseline 3 applies.

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 'What searches a specific page is shown for.' is a fragment, not a clear statement of an action, and it essentially restates the title 'Queries for a page'. It names the resource (a page) but has no verb and no differentiation from sibling tools like query or inspect_url.

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 provides no when-to-use guidance and names no alternatives. An agent cannot tell from the text when to prefer page_queries over query, top, or inspect_url; it must infer this from parameter names and sibling titles.

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 and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: parameters are passed through unchanged, and the schema's parameter descriptions add details like 'has_more' and 'next_start_row' for pagination. The description itself is brief but the combination with schema descriptions gives good transparency.

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 sentence that front-loads the core purpose and the key pass-through behavior. No wasted words; every part earns its place.

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 read-only pass-through tool with 100% schema coverage and no output schema, the description plus schema covers the essentials. The only minor gap is that the description doesn't explain what the response looks like beyond the schema's hints about has_more and next_start_row, but for a pass-through tool that's acceptable.

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 100%, so the schema already documents all 8 parameters thoroughly. The description adds the key semantic that all parameters are passed through unchanged to Google's API, which helps an agent understand that the schema descriptions mirror Google's own semantics. This is useful but not extensive beyond the 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 states a specific verb ('Direct query') and resource ('Google's Search Analytics API'), and clarifies that parameters are passed through unchanged. It distinguishes itself from higher-level analytics tools by emphasizing the raw, pass-through nature, though it doesn't explicitly name a sibling 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 this is the low-level tool to use when you want the raw API behavior without abstraction, and the sibling list (top, page_queries, site_overview) suggests the alternatives. It doesn't explicitly state when not to use it, but the 'passed through unchanged' phrasing gives clear context for selecting it over the more processed sibling 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 and destructiveHint=false, so safety is covered. The description adds that it compares to the previous period and lists the metrics, which is useful behavioral context, but it does not describe output format, pagination, or data availability nuances. Given the 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?

Two sentences with no fluff. The main purpose is front-loaded, and the metrics are enumerated efficiently. Every word earns its place.

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 read-only overview tool with fully documented parameters and no output schema, the description is sufficient. It explains the comparison logic and metrics returned. Minor gaps like handling of missing data or date edge cases are not critical for a safe read-only operation.

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 100%, so the schema fully documents all four parameters. The description does not add parameter-specific guidance beyond what the schema provides, so it meets the baseline but does not exceed it.

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 clear purpose: reporting site performance metrics (clicks, impressions, CTR, average position) over a period compared to the previous one, and it directly answers 'how is my site doing'. It is specific and distinct from sibling tools like 'query' or 'top', though it does not explicitly name alternatives.

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 usage for site-level performance overviews, but it does not explicitly state when to use this tool versus siblings like 'changes' or 'top'. It offers a general question it answers but lacks explicit exclusions or 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=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context such as rate limits, data freshness, or filter edge cases, but it also does not contradict the annotations. Given the existing annotation coverage, this is an adequate baseline.

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?

Two short sentences with no wasted words. The primary function is front-loaded, and the example is both illustrative and economical. Every sentence earns its place.

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 has nine optional parameters and no output schema, so the description could reasonably explain what the returned rows contain or mention pagination behavior. It does not, but the schema is largely self-documenting and the example conveys the core interaction. Overall, the description is adequate but leaves the output shape 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 89% schema description coverage, the schema does most of the parameter documentation. The description adds practical meaning by illustrating how the 'dimension' parameter combines with country/device filters ('top pages in Germany on mobile'), which clarifies that country and device act as filters rather than grouping dimensions. This exceeds the baseline.

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 identifies the tool as retrieving 'Top queries, pages, countries or devices for a period' and gives a concrete example that shows the possible scope. It does not explicitly contrast itself with sibling tools like 'query' or 'page_queries', 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?

There is no guidance on when to choose this tool over alternatives such as 'query' or 'page_queries'. The example 'top pages in Germany on mobile' demonstrates capability but does not state conditions, exclusions, or relative suitability, leaving the selection entirely to inference.

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