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

Annotations already cover read-only and open-world, but the description adds real context beyond them: an auth prerequisite (a [bing] key configured in the site profile) and a freshness expectation (numbers update roughly weekly). Both materially affect whether an agent should call this and how to interpret stale results.

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?

Four short sentences, front-loaded with what data is returned; the auth and freshness notes follow logically. 'Bing feeds Copilot' is the only line of marginal value, but it does justify the tool's existence.

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 no output schema and 0% parameter coverage, an agent still lacks the essentials to invoke this correctly: date format, the days-vs-start/end precedence, and what limit controls. The description covers prerequisites and freshness well but leaves the calling contract 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 description coverage is 0%, so the description carries the full burden for five parameters, yet it only vaguely gestures at 'for a range' and 'by query'. It never explains site format, how days interacts with start/end, what limit bounds, or the date format 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 the specific resource (Bing Webmaster Tools query-level clicks, impressions, average position) and the aggregation (site totals) over a range. The 'Bing' qualifier implicitly separates it from the Google-oriented search_queries/page_queries siblings, though it never says so outright.

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?

'Needs a [bing] key in the site's profile' gives a concrete prerequisite, and 'Bing feeds Copilot' hints at why the data matters. However, there is no guidance on when to pick this over search_queries or page_queries, and no exclusions or caveats about when the data is unusable.

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 and openWorldHint. The description adds meaningful behavioral context: it explains the per-query return shape, includes click/impression/position details, identifies the top page and its share, and states results are ordered by biggest overlap first.

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 and front-loaded: purpose first, then output structure, ordering, and parameter reuse. Every sentence contributes useful information without repetition.

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 compensates well for the lack of an output schema by explaining returned fields and ordering. However, for a 9-parameter tool with zero schema descriptions, it is incomplete on parameter semantics, especially site and limit.

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 9 parameters and 0% schema description coverage, the description must carry the burden. It explains min_impressions and delegates date/filter parameters to search_queries, but leaves site, limit, and the exact semantics of start/end/days/device/country/search_type unclear.

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 analytical purpose: finding queries where multiple pages compete and split clicks (cannibalization). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like page_queries or search_queries beyond the cannibalization framing.

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 implied by the cannibalization definition, and it notes that dates and filters behave like search_queries. However, it gives no explicit when-to-use guidance, no exclusions, and no clear alternative selection criteria versus search_queries or page_queries.

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 read-only/open-world safety profile, and the description layers on genuinely new behavior: a 10–30 second runtime per run, and the caveat that real-user field data only appears "when Google has enough visits." It does not cover failure modes (e.g., what happens for an unindexed or invalid page), which keeps it below a 5.

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?

Four tight sentences, front-loaded with what the tool returns and then the page/site/strategy semantics. Every clause earns its place — even the runtime note is actionable scheduling information rather than filler.

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 no output schema, the description usefully maps the response shape (page_field and site_field with LCP/INP/CLS and Google's rating; lab with performance score, LCP, CLS, TBT, FCP, Speed Index). What remains thin is input formatting guidance for `site`/`page` and any error behavior.

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 must carry the load — and it largely does, giving the default for `page`, the meaning of `page` vs. `site` scoping, and the allowed values for `strategy` ("mobile" or "desktop") that the schema does not enumerate. The `site` parameter's expected format (domain vs. full URL) is left 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+resource: fetches Core Web Vitals for a page from PageSpeed Insights, with an explicit default (the site's home page). It also enumerates the two result families (real-user field data vs. a single Lighthouse lab run), so an agent knows precisely what it gets back. No sibling tool overlaps this performance-metric niche.

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 the usage context (auditing page performance, choosing mobile vs. desktop) and discloses a 10–30 second cost, but never states when to call this instead of something else or when-not to call it. The disambiguation between field and lab data is implicit rather than framed as a selection rule.

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?

Consistent with readOnlyHint=true and openWorldHint=true, and adds real context annotations don't carry: the output is pasteable config, brand_terms suggestions are commented out, and persistence happens only via a separate CLI flag. Auth scope is gestured at ('the key can read') but rate limits and failure modes on unauthorized keys are not described.

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 tight sentences, front-loaded with the resource enumeration and followed by output shape and the read-only caveat. Domain jargon ([[sites]], brand_terms) is justified because those are the literal artifacts produced.

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?

No output schema exists, and the description does cover the return shape well enough to act on. However a 1-param tool whose sole parameter is entirely undocumented leaves the agent guessing about `profile`'s effect on results.

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% and the description never mentions the single `profile` parameter, so the agent cannot tell whether it narrows the scan, names the target config file, or both. With only one optional param the damage is limited, but the description does nothing to compensate for the coverage gap.

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+resource: enumerates Search Console properties and GA4 web streams, matched by domain, plus the shape of what it emits ([[sites]] blocks). 'For any site not in a profile yet' implicitly contrasts with the profile-oriented sibling `sites`, but no sibling is named explicitly.

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 implied rather than stated: you call it to gather config blocks for unprofiled sites. It does clarify the read/write split ('Reads only; the user adds the blocks with `dottide discover --write`'), which tells the agent this tool will not persist anything. No explicit comparison to siblings like `sites` or `traffic`.

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 and openWorldHint, and the description reinforces rather than contradicts them by spelling out what 'read only' means here (never submits a sitemap or requests indexing). It also adds genuinely non-obvious operational context the annotations cannot convey: per-page URL Inspection call consumption, which is a real quota consideration when choosing `pages`.

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?

Front-loaded with the guiding question, then the scope, then the safety/cost caveats — a sensible order with no filler. The long parenthetical enumerations of returned fields add bulk but each item is informative, so trimming would cost real signal.

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 no output schema, the description does its job by naming the return payloads (sitemap list, per-page index verdict, and a plain-language `problems` list) and disclosing the Vision-style cost of URL Inspection calls. Only real gap is the required `site` parameter's accepted format, which an agent needs before it can call the tool 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 coverage is 0%, so the description must carry the load, and it partially does: `pages` is explained as 'top pages by clicks' and `days` as the lookback window, and the cost note ties `pages` to quota. But `site` — the one required parameter — gets no format guidance (property identifier vs URL, sc-domain syntax), and defaults for `days`/`pages` are left to 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?

States a specific diagnostic question plus the two concrete resources it returns: Search Console sitemap entries (errors, warnings, last read, URLs submitted) and index status per page (verdict, coverage, last crawl, canonical). The 'healthy in Google's index' framing plus sitemap/index-status detail clearly separates it from siblings like core_web_vitals, traffic, or search_queries.

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 implied rather than stated: the opening question frames it as a diagnostic check, and the cost note ('each page checked uses one URL Inspection call') hints at a scoped/sampled run. But no sibling is named and there is no explicit when-to-use / when-not-to-use routing, so the agent must infer that this is the index-diagnosis entry point rather than a metrics or vitals tool.

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 and openWorldHint, but the description adds real behavioral substance beyond them: the exact position band (8–20), ranking by impressions, the min_impressions constraint applying to both periods, and the edge-case behavior when low_ctr is empty (low_ctr_note and low_ctr_band_counts). It doesn't cover limits, pagination, or performance.

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?

Front-loaded with the core purpose, then each category and its caveat in dense but purposeful clauses; every sentence carries information. The single run-on sentence structure makes it slightly harder to scan than a bulleted form would be.

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 no output schema, the description does well to enumerate the returned item categories and the low_ctr edge-case fields. However, for a nine-parameter tool with zero schema coverage, it leaves the agent guessing about limit semantics, device/country filtering, and default values.

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 must compensate for nine parameters. It explains min_impressions (both periods), search_type limitations (Discover/News), and defers date params to search_queries' rules, but leaves limit, device, and country completely 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+resource with full detail: it returns prioritized 'what to work on next' items across four named opportunity categories (striking distance, lost clicks, position drops, low CTR). This is clearly distinct from sibling tools like search_queries, which return raw rows rather than curated opportunities.

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?

'What to work on next for a site' frames the prioritization use case, and the note that Discover and Google News have no query rows tells the agent when this tool won't help. It does not explicitly say when to prefer search_queries or page_queries instead, so alternatives are implied rather than named.

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 cover the read-only and open-world profile, and the description goes beyond them by explaining the `hidden` field: clicks/impressions Search Console counts for the page but excludes from query rows due to query anonymization. That is a real reconciliation caveat an agent would otherwise miss.

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 compact sentences that lead with what is returned before explaining the `hidden` nuance. Dense but every clause carries information; nothing is padding.

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?

No output schema exists, and while the description sketches the return shape (query rows plus page-level totals and `hidden`), it leaves limit/pagination behavior and the site/search_type parameters undocumented. Adequate for a lookup tool but not fully self-sufficient.

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 10 parameters, so the description carries the burden. It usefully clarifies the page argument takes a full URL and that dates/compare/filters mirror search_queries, but says nothing about site, limit, search_type, or device/country semantics.

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 resource and scope: the queries that bring traffic to ONE page (full URL), with the page's own totals. The contrast with search_queries is implied via shared parameters rather than stated outright, so the sibling boundary is slightly blurry.

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?

Says it takes 'same dates, compare and filters as search_queries', which tells the agent the two tools are parameter-compatible, but never says when to pick this over search_queries or competing_pages. Usage is inferable from the resource description only.

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 read-only, open-world profile, so the description rightly focuses on behavior. It discloses the non-obvious default window (last `days` days ending three days ago), what compare=true computes, allowed filter values, and that the result echoes the filters used — genuinely useful 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?

Dense but front-loaded: metrics first, then date semantics, then compare, then filters. Every sentence carries information; the only cost is that it reads as a single run-on paragraph rather than separated concerns.

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 10-parameter tool with no schema descriptions and no output schema, the description covers metrics, dimensions, date logic, comparison, and three of the filter parameters well. Missing coverage of `limit` and `site` keeps it from being fully 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?

Schema description coverage is 0%, so the description carries the full burden and does most of it: exact date format, the days fallback rule, the compare semantics, country as three-letter ISO, and enumerated device/search_type values (default 'web'). It leaves `site` and `limit` (default 25) unexplained, which is the main gap.

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?

Names a specific resource (Search Console clicks, impressions, CTR, average position) and the two dimensions it can be grouped by, which implicitly separates it from page_queries. It stops short of naming the sibling, so the differentiation is inferred rather than stated.

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 implied through the 'by query or page' framing and the note that Discover and Google News have page rows only, which steers an agent toward `by=page` for those search types. There is no explicit when-to-use/when-not statement and no reference to page_queries or other 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 flag readOnlyHint and openWorldHint, and the description usefully adds that the access check is a live, point-in-time probe made during the call — meaningful context for an agent diagnosing auth failures. It does not describe the response shape, but for a read-only inventory tool this is a modest omission.

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 that states scope, per-site credential mapping, and access status with zero filler. Every clause carries 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 no-parameter, no-output-schema inventory tool this covers what an agent needs: what is returned and that access status is checked live. It could go one step further by hinting at the return structure (e.g. a list with key names and boolean access flags).

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?

Zero parameters, so the baseline of 4 applies; the description correctly implies no inputs are needed to enumerate all sites. It adds nothing more because there is nothing more to add.

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 names the resource concretely (every configured site) and specifies the payload: key coverage per site plus live Search Console/GA4 access status. That clearly separates it from siblings like traffic or search_queries, though the verb is implicit (enumerate/list) and no sibling is named explicitly.

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 'at the moment of the call' suggests a discovery/preflight role (find sites, check credential health before pulling data), but the description never states when to prefer it or what to do when access fails. No alternatives are referenced.

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 openWorldHint=true, so safety and network reach are covered. The description adds one genuinely useful behavioral fact beyond that — these are live public numbers requiring no API keys — but says nothing about rate limits, freshness, or failure behavior for external stores that may 404.

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 compact clauses with no filler, and the key capability ('no keys required') is placed up front. The parenthetical metric lists are dense but readable.

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 with one undocumented parameter and no output schema, the description leaves too much open: what 'profile' selects, whether results cover all three stores at once or one at a time, and what the returned shape looks like. It reads as a capability blurb rather than a usable invocation spec.

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%, and the single 'profile' parameter is completely unexplained in both schema and description. The name is ambiguous — it could mean a store profile, a user profile, or a preset — and since it defaults to null, the agent cannot tell what omitting it does. The description should compensate here and does not.

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 names the exact data resources (WordPress.org plugins, Firefox Add-ons, GitHub stars) and the metrics returned, so the subject matter is clear. But it never states the action — no verb like 'fetch' or 'retrieve' — and the name 'store_stats' alone would not tell an agent what is produced. Sibling differentiation is only implicit, since the sibling tools are all SEO/traffic tools and this one is clearly off-topic.

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 call this tool, when not to, or what alternatives exist. An agent has to infer usage purely from the list of data sources. The 'need no keys' note hints at a prerequisite but is not framed as guidance.

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 openWorldHint=true, so safety is covered. The description adds useful behavior: aggregation by source/medium, separate AI-referral totals, per-assistant landing pages ordered 'most sessions first', and the GA4-only constraint. It says nothing about date window handling, compare behavior, or truncation via limit.

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 tight sentences, front-loaded with the primary output and followed by the AI-referral nuance and the eligibility caveat. No filler, though the landing-page ordering detail could be trimmed.

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 no output schema, 6 undocumented parameters, and a compare flag, the description is too thin to call the tool correctly. Return shape is sketched but the request-side semantics, the most important gap, are entirely 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 6 parameters, so the description carries the full burden and fails it: site is only implied, and days/start/end/limit/compare are never mentioned. An agent cannot learn the default 28-day window or what limit and compare do from this text.

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+resource: GA4 sessions broken out by source/medium, plus AI assistant referral totals with landing pages per assistant. That is specific enough to separate it from search_queries/bing_queries/page_queries, though it never names a sibling to contrast with.

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 only guidance is the eligibility gate 'Only for sites with GA4.' There is no statement of when to pick this over the query tools, no mention of date-range expectations, and no exclusions beyond the GA4 prerequisite.

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