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

readOnlyHint=true already declares this is a safe read, lowering the bar. The description adds useful context that the data is historical and fills a gap Search Console does not cover, but it discloses nothing about return shape, granularity, or rate limits. Adequate but thin beyond the annotation.

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 tight sentences that lead with the core purpose and then the market/default guidance. No 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 read-only lookup with three simple params and no output schema, the description covers purpose, defaults, and market scoping adequately. The main gap is not routing the agent among the similarly named bing_* siblings.

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 67% – country and language already carry inline descriptions with their defaults. The description reinforces the default-market behavior and the override path, adding modest value, but contributes nothing for the undocumented keyword parameter beyond its obvious meaning.

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 data type: historical search volumes for a keyword on Bing. This is clearly a keyword-level volume lookup, which is reasonably distinct from the sibling bing_query_stats and bing_page_stats, though it never names them explicitly to remove ambiguity.

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 contextual guidance ('data that Search Console doesn't provide') and parameter defaults (Italy/Italian, override for other markets), which implies when the tool is useful. However, it never states when to use this versus bing_query_stats or another sibling, and offers no explicit exclusions.

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?

readOnlyHint=true already covers the safety profile, and the description adds what annotations cannot: the results are scoped to the caller's own account (implying authentication/account binding) and each entry reports a verification flag. That is real return-shape context and matters more here because no output schema exists.

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 carrying the verb, the resource, the account scope and one return attribute with zero filler. Nothing could be cut without losing 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 covers what it lists, whose data it lists and one field of the response. With no output schema it could say a bit more about the returned fields, but nothing an agent needs in order to invoke it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameter behavior.

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 (list) and resource (sites) scoped to 'your Bing Webmaster Tools account', plus an attribute of the returned items (verification status). The 'Bing' qualifier plainly separates it from the sibling gsc_list_sites, but the description never names that alternative, so it stops short of a 5.

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 explicit when-to-use or when-not-to-use text and no mention of alternatives such as gsc_list_sites. Usage is only implied: an agent infers this is the account-discovery entry point that precedes bing_query_stats, bing_page_stats and bing_keyword_stats.

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 annotation already declares readOnlyHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — nothing about which site is used by default, how the aggregate flag affects the response, or pagination/limit behavior.

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 filler, and the core purpose is front-loaded. It is tight, though the second sentence is purely schema-related rather than the most decision-relevant fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with date filtering, an aggregation toggle, containment filtering and a default-site fallback, plus no output schema, the description is thin. It covers the identity of the result key but leaves the date-range and aggregate semantics entirely to the 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?

Schema coverage is 83%, so the baseline is 3, and the description goes slightly beyond it by clarifying that the `key` field holds the URL — a field that does not even appear in the input schema properties, so this is genuinely additive information.

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 the specific resource (page-level performance on Bing) and the metrics returned (impressions, clicks, average position). The word 'per pagina' implicitly separates it from bing_query_stats and bing_keyword_stats, but it never explicitly names those siblings, so an agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no reference to the sibling tools bing_query_stats or bing_keyword_stats. An agent must guess whether to pick this or the query/keyword variants from the tool name alone.

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?

readOnlyHint=true already covers the safety profile. The description adds useful scope context by noting that results are limited to Bing's available history and pointing to the dataAvailable field in the response. It does not cover auth, rate limits, or default behavior exhaustively.

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 names the metrics, the entity, and the historical scope. No filler or redundancy.

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 names the returned metrics and references dataAvailable in the response. It is nearly complete for calling the tool, though it omits any mention of when to prefer it over siblings.

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 83%, so the schema already documents most parameters (dates, siteUrl, contains, aggregate, limit). The description adds no parameter-specific meaning, which meets the baseline when schema coverage is high.

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 specific metrics (impressions, clicks, average position) and the resource (Bing search queries), with scope 'available history'. It implicitly distinguishes query-level data from sibling page/keyword tools via 'per query di ricerca', though it never names an alternative 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as bing_page_stats or bing_keyword_stats. The agent must infer that this tool is for query-level performance and not for keyword volume or page-level stats.

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, so safety is covered. Description adds that data is real CrUX, 75th percentile, weekly rows up to 40 weeks, which is useful output-shape context, but it omits auth, rate limits, or data freshness caveats.

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, front-loaded with scope and followed by use case. 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?

For a 4-param, no-output-schema tool, the description gives the metric set and weekly granularity, but it does not clarify how url and origin interact, the default weeks value (25), or any output column names. It is adequate but missing details an agent may need.

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 75% (url, origin, formFactor have descriptions; weeks does not). The description mentions 'fino a 40 settimane' which aligns with the weeks parameter maximum, but adds no syntax or default/format detail beyond the schema. Baseline 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?

States a specific resource (real Core Web Vitals trend at 75th percentile), granularity (one row per week, up to 40 weeks), and a concrete use case. It distinguishes itself from crux_query via the historical/trend scope, though it does not explicitly name the sibling.

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?

Provides a clear context: useful for checking whether an intervention improved or worsened performance. However, it does not state when to use this instead of crux_query or other performance tools, nor any exclusions.

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 only supply readOnlyHint and openWorldHint, so the description carries the rest and does so well: it discloses the 28-day aggregation window, the 75th-percentile basis, the good/needs-improvement/poor judgment bands, and the presence of a distribution, plus the ranking-relevance motive. It stops short of stating rate limits or that some URLs lack data, but it adds substantial behavioral context 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?

A single dense sentence front-loads the core identity and then enumerates metrics, percentile, verdicts, and distribution without wasted words. The trailing ranking-relevance sentence is short and earns its place as motivation, though the parenthetical listing is slightly cluttered.

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 query tool with no output schema, the description usefully previews the return shape (metrics, 75th percentile, judgement, distribution), so an agent knows what comes back. Combined with full schema coverage on the inputs, it is nearly complete; only the explicit sibling routing (vs crux_history/psi_analyze) is missing.

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 fully documents url, origin, and formFactor (including the mobile default rationale). The description adds nothing about the parameters, which is acceptable given the coverage but means the baseline of 3 is the correct ceiling here.

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 specific resource (real-user Chrome Core Web Vitals for the last 28 days) and the exact metrics returned (LCP, INP, CLS, FCP, TTFB), so an agent knows precisely what data it gets. It implicitly separates itself from crux_history via the '28 giorni' window, but never names or contrasts with the sibling 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?

There is no explicit when-to-use or when-not-to-use guidance. The line 'Sono i dati che Google usa per il ranking' hints at a use case (assessing ranking-relevant page experience), but it never says how this differs from crux_history or psi_analyze, which are the obvious alternatives in the sibling list.

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

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

Annotations only declare readOnlyHint=true, so the description carries the rest. It usefully discloses that the ranked declines/increases are 'calcolati sulla prima metrica' (a non-obvious behavioral detail for an array-valued metrics param) and that yearAgo means 52 weeks prior rather than a naive same-week comparison.

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, and the core scope is front-loaded ahead of the comparison-mode detail. Efficient, though the second sentence could be tightened.

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 12-parameter read-only tool with no output schema, the description covers the essential semantics plus return shape at a high level. It omits the default dimensions/metrics, the filter mechanics, and that `limit` applies separately to declines and increases, all of which matter when invoking it.

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 75%, so parameters are mostly self-documenting. The description only adds meaning for compareTo (default vs yearAgo = 52 settimane), leaving the other 11 parameters to the schema — an acceptable baseline addition, but not compensating for the remaining 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?

The description states a specific verb and resource ('Confronta due periodi su Google Analytics 4') and describes the returned artifact ('i cali e le crescite più forti'). It also implicitly distinguishes itself from gsc_compare_periods by naming GA4, though it never names a sibling 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?

It explains the default comparison behavior and the 'yearAgo' alternative, which is genuine usage guidance. It does not, however, say when to reach for this tool instead of ga_report or ga_organic_landing_pages, nor when 'custom' is appropriate.

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?

readOnlyHint=true already tells the agent this is a safe non-mutating read. The description adds value by naming the returned fields (ID, account), but says nothing about pagination, result ordering, empty-result behavior, or auth requirements, so it stays at a moderate level.

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, stating action and returned fields. 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?

For a parameterless read-only listing tool with annotations covering safety, the description is nearly sufficient: it names the resource and the fields returned. Only minor gaps remain (ordering, pagination, empty case), and no output schema exists to cover them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies per the rubric. The description correctly clarifies that the output is the accessible property set with ID and account, which is the only semantic detail available for a no-input tool.

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 clear verb+resource: lists accessible Google Analytics 4 properties. It also specifies the returned payload (numeric ID and account), which helps an agent distinguish it from reporting siblings like ga_report. It does not explicitly differentiate itself from those siblings, so it stops short of a 5.

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: an agent can infer this is the discovery step to obtain property IDs before calling ga_report, but the description never says when to use it or when another sibling is preferred. No prerequisites or exclusions are given.

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?

readOnlyHint already declares this as a safe read, so the description only needs to add context. It does add useful output content (sessions, engagement, conversions, revenue), but says nothing about scope limits, default rows, or behavior when dates are omitted despite the schema allowing defaults.

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 tight sentences: the first front-loads what the tool returns, the second adds the pairing rationale. Nothing is redundant, though the second sentence is slightly promotional rather than operational.

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 six optional parameters at 83% schema coverage, no output schema, and read-only annotations, the description covers what data comes back and roughly where it fits, which is close to sufficient; only the distinction from ga_report and the omitted-date default behavior are missing.

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 83%, so the schema already documents days, source, property, startDate and endDate. The description adds no parameter-level meaning (e.g., what 'organic' implies for the source filter), so the baseline of 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 names a specific resource (pagine di destinazione del traffico da ricerca organica) and enumerates the metrics returned (sessioni, coinvolgimento, eventi chiave, ricavi), so an agent knows what it produces. It does not, however, explicitly distinguish it from the sibling ga_report, which is the nearest overlapping GA4 report tool.

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 line 'Si abbina bene a Search Console: le query portano clic, qui si vede cosa succede dopo' gives a genuine context-of-use cue for pairing with GSC tools, but there is no explicit when-to-use / when-not guidance and no comparison against ga_report or ga_compare_periods, so alternatives remain unaddressed.

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, so safety is covered. The description adds genuinely useful behavioral context — the 30-minute freshness window — but says nothing about rate limits, quota behavior, or what the realtime response contains.

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, front-loaded sentences with no filler; the core definition comes first, followed by use case and helpful dimension hints. Slightly terse rather than wasteful.

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 conveys the key return concept (realtime active users) and dimension guidance, and annotations cover the read-only nature. Minor gaps remain around limit/metrics behavior, but the essentials for calling it correctly are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25% (only property is documented), so the description must compensate. It does partially, by naming useful dimensions (unifiedScreenName, country, deviceCategory) that guide the dimensions parameter, but it says nothing about limit or metrics 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 metric and window: active users in the last 30 minutes, which clearly identifies the GA4 realtime report and implicitly separates it from the historical ga_report sibling. It doesn't explicitly name the sibling, so it falls short of a 5.

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 a use case (verify the immediate effect of a publication or campaign), which implies when the tool is appropriate. However, it never states when to prefer ga_report instead, nor any exclusions or prerequisites, leaving the agent to infer the boundary.

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?

Beyond the readOnlyHint annotation, the description discloses the ~1-day data freshness lag, which is a real behavioral trait an agent needs to avoid misreporting 'today's' numbers. It omits rate limits and default-property fallback behavior, so it is useful but not complete.

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, followed by the freshness caveat, then the value lists. The dimension/metric enumerations are long but earn their place by supplying otherwise-missing allowed values.

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 9-parameter, zero-required tool with no output schema, the description covers purpose, data lag, and the free-form array values that the schema under-documents. Filters, limit, and pagination are left to the schema but remain in Italian and self-describing, so nothing critical is missing.

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 67%, and the schema leaves 'dimensions' and 'metrics' as bare string arrays with no enumerated allowed values. The description compensates by listing valid dimensions and metrics, which materially improves correct invocation beyond the schema itself.

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 ('Report libero su Google Analytics 4') with scope modifiers ('dimensioni, metriche e filtri a scelta'). An agent can tell this is the flexible/generic GA query tool distinct from ga_organic_landing_pages or ga_realtime, though 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: 'filtri a scelta' signals this is the build-your-own query tool, and the dimension/metric lists hint at valid usage. There is no explicit when-to-use-this-vs-ga_compare_periods or ga_organic_landing_pages guidance and no exclusions.

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 the safety profile is covered. The description adds useful scope context (which directives are inspected, and 'measured data, without judgments' indicating raw output rather than an evaluation), but does not disclose traits like fetch behavior, caching, or response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the core output followed by the supplementary signals. No filler, though the bot-name list and file list make it slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, one-parameter tool with no output schema, the description does the heavy lifting of explaining what data categories are returned, which is enough for an agent to invoke it correctly. Return formatting details are absent but minor given the clear enumeration of inspected sources.

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% and the single 'url' parameter is fully described in the schema as a site page whose path is evaluated. The description adds no further parameter semantics beyond what the schema already provides, so the baseline 3 for a fully documented one-param schema 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 names a specific resource (AI crawler access for a URL) and enumerates exactly what is returned: per-bot allow/block status, the robots.txt rule responsible, plus llms.txt, Cloudflare Content Signals, TDMRep, meta robots and X-Robots-Tag. It is clearly distinct from siblings like geo_page_metrics or geo_page_sections, though it never names an alternative to differentiate itself 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?

There is no explicit 'use this when...' statement or any named alternative, but the enumerated output (crawler permissions for a given page) makes the intended use strongly implied. An agent can infer the right context, but no exclusions or prerequisites are provided.

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 the safety profile is covered. The description still adds genuinely useful behavior: it reads only initial HTML without JavaScript execution, which explains why results may differ from a rendered page, and it discloses external data sources (RDAP/WHOIS for domain age) implying extra network calls and possible latency. It says nothing about rate limits, auth, or cost.

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 definition before the long field enumeration, and there is no filler. The single sprawling sentence listing a dozen metric families is dense and harder to parse than a short bulleted form, but every item listed is substantive content the agent needs.

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?

There is no output schema, so the description must describe what comes back — and it does so comprehensively, covering page-level metrics, site-level signals, and the comparability of the numbers. For a single-parameter read tool with annotations covering the safety profile, nothing needed to call it correctly is missing.

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?

Only one parameter and schema description coverage is 100%, with the URL format and an example already documented in the schema. The description adds no syntax or format detail beyond that, so the 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?

States a specific verb+resource ('misure oggettive di una pagina') and enumerates exactly what is measured: text, structure, answer-upfront, sections, freshness, author, sources, structured data, entities, plus site signals (HTTPS, domain age). It also explicitly routes one sub-case to the sibling schema_validate, so an agent can distinguish it from that tool without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear implied context (auditing a single page as an AI crawler sees it) and one explicit alternative with its condition: 'per la validazione completa usa schema_validate'. It does not state when-not to use it or differentiate from overlapping siblings such as geo_page_sections or geo_ai_access.

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, so safety is partly covered, but the description adds genuinely non-obvious context: the returned text is scraped from an external site and may contain injected instructions, so it must be treated as data. That injection-safety warning is real value beyond the annotations, though truncation behavior (maxCharsPerSection) is left to the schema.

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 return structure, then the use case, then the safety caveat. No filler — every clause carries information an agent needs.

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 takes on the job of describing the return shape (sections with word/number/list/table counts) and does so adequately. The only gap is that per-section truncation isn't mentioned, which is covered by the schema 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 100% and both parameters (url, maxCharsPerSection) are documented in the schema itself. The description adds no syntax, default, or range detail beyond what is already there, so the baseline of 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?

States a specific resource and output shape: the main content split into one section per H1–H3 heading, each with words, lead-paragraph words, numbers, lists and tables. An agent can distinguish this extraction tool from siblings like geo_page_metrics or geo_ai_access without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear use context — 'valutare passaggio per passaggio se la pagina risponde alle domande' — which tells the agent when this tool is the right choice. It stops short of naming alternatives or stating when not to use it, so it is clear but not fully 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?

readOnlyHint=true already covers the safety profile, and the description adds useful behavioral context: the default comparison window and the precise semantics of the yearAgo comparison. It does not cover pagination or result volume, but for a read-only analysis tool this is solid.

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, front-loaded with the core purpose and return shape, then the comparison-window semantics. No 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?

For an 11-parameter tool with no output schema, the description reliably covers the primary semantic axis (the comparison period) and the returned structure. Remaining parameters (filters, dimensions, limit, days) are documented in the schema, though the custom comparison path is not addressed in the description.

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 73%, and the description adds meaning the schema lacks — the compareTo enum has no per-value description in the schema, yet the description explains that "previous" is the default and "yearAgo" means 52 weeks earlier with the same weekdays. The "custom" value and its dates are left unexplained, which is the one 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 (confronta/compare) and resource (due periodi) plus what it returns: rows with the strongest click declines and growth, plus totals. This clearly distinguishes it from gsc_performance, which reports metrics rather than deltas.

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?

Explains the default behavior (compares against the previous period of equal length) and when to switch (compareTo="yearAgo" for 52 weeks prior with matching weekdays). It does not mention the "custom" option or say when to prefer this tool over gsc_performance, but the context offered is clear.

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?

readOnlyHint=true already tells the agent this is a safe read, but the description adds genuinely useful behavioral context beyond the annotation: the per-property quota of ~2,000 inspections/day, which is a real rate limit an agent must plan around. It also discloses the response contents (canonical chosen by Google, crawl date, rich results), though it omits auth/property-scope requirements and latency.

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, zero waste: the returned-data list is front-loaded and the quota caveat follows. Nothing is padded or repeated.

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 enumerates the return fields and flags the quota limit, so an agent knows what it will get and the cost. Only the property-scope/auth assumption (that the URL must belong to the selected Search Console property) is left to the 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?

Schema description coverage is 100% — url, siteUrl and languageCode are each documented in the schema, including the siteUrl fallback behaviour and format examples. The description adds no parameter-level meaning (canonical/robots.txt refer to output, not input), so the 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 names a specific verb+resource (indexing status of a URL as seen by Google) and enumerates the exact data returned — coverage, last crawl, Google-selected canonical, robots.txt, rich results. This clearly separates it from the list/report siblings (gsc_list_sites, gsc_performance), though it never names an alternative 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?

There is no explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. The only guidance is an implied 'check a URL's indexing state', plus a quota note, which is a constraint rather than usage 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?

The readOnlyHint=true annotation already establishes this as a safe read operation, so the description need not restate that. It does add useful context by naming the fields returned (last download date, errors, warnings, submitted URLs), which matters since no output schema exists, but it says nothing about pagination, sitemap-index expansion, or the behavior when no sitemaps exist.

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 resource front-loaded and the returned fields enumerated efficiently. It is slightly under-specified rather than padded, and the Italian phrasing carries no structural waste.

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 one-parameter, read-only list tool with no output schema, the description covers the essentials: what is listed and what fields come back. It is not fully complete (no guidance on result shape or empty results), but nothing an agent needs to invoke it correctly is missing.

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% for the single siteUrl parameter, and the schema already documents both the accepted formats and the default-property fallback. The description's reference to 'la proprietà' aligns with the parameter but adds no syntax or format detail beyond what the schema provides, so the 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 identifies a specific resource (sitemaps submitted to the property) and enumerates the data returned (last download date, errors, warnings, submitted URLs), which separates it from siblings like gsc_list_sites or gsc_inspect_url. It is a noun phrase rather than a verb+resource statement and is written in Italian while the tool name and siblings are English, but the intent is unambiguous.

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 tool versus alternatives such as gsc_list_sites (sites vs. sitemaps) or gsc_inspect_url, and no prerequisites are given. Usage is only inferable from the tool name itself.

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 readOnlyHint annotation already establishes that this is a safe, non-mutating call, so the description does not need to cover the safety profile. It does contribute one meaningful behavioral detail beyond the annotation: the result is scoped to whatever the configured credentials can access, which explains why the output may be a subset. It says nothing about pagination, ordering, or return shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with the core scoping constraint attached; nothing is padded or redundant. It is efficient rather than especially rich, so it stops short of the top of the range.

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 trivial zero-parameter, read-only list tool this is close to sufficient, and no output schema exists to mandate return-value documentation. The main gap is that it never hints at the return format (a list of site identifiers) or whether the call can be truncated, which an agent would benefit from knowing.

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?

There are no parameters, so the schema carries nothing to interpret and the baseline of 4 applies. The description correctly implies this is an unfiltered listing, adding the only relevant semantic: the credential-based scope of the returned set.

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 ('Elenca') and resource ('le proprietà Search Console'), making clear it is a listing tool for Search Console properties. It implicitly distinguishes itself from the sibling site-listing tools (bing_list_sites, ga_list_properties), though it never names or contrasts them 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?

The stated scope ('accessibili con le credenziali configurate') implies when it applies—when the agent needs the list of reachable properties—but there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives. For a zero-parameter listing tool the usage context is largely self-evident, so a middling score is fair.

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, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data has a ~2-3 day lag, which an agent needs to avoid misinterpreting recent-date results as empty.

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 with no filler; the core purpose is front-loaded and the freshness caveat follows. Nothing is wasted, though there is no structural cue (e.g. parameter groupings) for such a wide 8-param tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned metrics (clicks, impressions, CTR, position), partially covering the return shape. However, for an 8-parameter query tool it omits any mention of filtering, row limits, or date-range selection, leaving those entirely to the 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?

Schema description coverage is 63%, so the schema already documents most parameters (days, endDate, filters, siteUrl, startDate). The description adds only that results are 'grouped by the chosen dimensions' and that CTR is on a 0-1 scale, which is metric semantics rather than extra parameter meaning. Baseline 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?

States a specific verb+resource: returns clicks, impressions, CTR and average position from Google Search Console, grouped by the chosen dimensions. An agent can tell it apart from siblings like gsc_inspect_url or gsc_list_sites, though it does not explicitly name any sibling to differentiate from gsc_compare_periods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance, no mention of alternatives (e.g. gsc_compare_periods for period comparisons, gsc_striking_distance for opportunity queries), and no prerequisites. Usage is only implied by the tool name and its generic metric output.

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, so safety is covered. The description adds one behavioral trait not present in structured fields: results are sorted by impressions. It does not disclose return shape, pagination, or whether the position band is inclusive, so it adds moderate rather than rich context.

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 defining position band and sort order front-loaded before the use-case clause. No filler, though the informational payload is thin for a nine-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter tool with no output schema, the description conveys the core selection logic but leaves date-window behavior, result size, and return fields to inference. Adequate minimum, but not complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 56%, so several of the nine parameters (limit, and undescriptioned numeric bounds) are undocumented. The description does clarify the minPosition/maxPosition defaults (4-20), which is the tool's defining filter, but it says nothing about days, startDate/endDate interaction, siteUrl fallback, or pageContains/minImpressions.

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 concept: queries where the page is already visible but not at the top, with a default position band of 4-20, sorted by impressions. That is concrete enough to distinguish it from siblings like gsc_performance, though the verb 'Query' is generic and it does not name the competing tools.

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 intent is implied by 'le opportunità più rapide da ottimizzare', which tells the agent this is for finding quick-win optimization targets. However, there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives such as gsc_performance or gsc_compare_periods.

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 safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful behavioral context: the 10-30 second latency, the fact that real-world CrUX field data is included only 'se disponibili', and the shape of the result set. It does not mention rate limits or failure behavior, but it exceeds the annotation 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?

One dense but well-ordered sentence: what it does, what it returns, and the time cost are all front-loaded. No filler, though it is a long single sentence rather than being broken into scannable clauses.

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 a fair job summarizing return values (scores, lab metrics, ordered opportunities, SEO checks, CrUX). However, it leaves the strategy/categories inputs unexplained and gives no guidance on interpretation, so it is only adequate for a 3-parameter analysis tool.

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 only 33% (only 'url' is documented). The description says nothing about the 'strategy' parameter (mobile/desktop) or the 'categories' array, both of which have enums/defaults that the description ignores. It therefore fails to compensate for the schema 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?

The description names a specific verb and resource ('Test Lighthouse di una pagina tramite PageSpeed Insights') and enumerates the output contents (scores, lab metrics, opportunities, failed SEO checks, CrUX data). It is clear what the tool does, though it never distinguishes itself from related siblings such as crux_query or geo_page_metrics.

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 explicit guidance on when to choose this tool over crux_query, geo_page_metrics, or other siblings, nor any stated prerequisites. The only usage-relevant hint is the '10-30 secondi' runtime, which helps the agent budget time but does not route it between alternatives.

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?

With only readOnlyHint and openWorldHint, the description carries real burden and largely meets it: it discloses the exact validation layers (syntax, vocabulary with typo-correction suggestions, Google rich-result requirements, page consistency) and states validation runs 'in locale'. It does not describe output format, but the behavioral enrichment here is substantial.

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 long sentence, but front-loaded with the action and inputs, then organized by semicolon-separated validation levels so it is scannable. Dense without being wasteful, though it could be broken into two sentences.

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, so the description should explain what a caller gets — it lists the checks performed but not the shape of the verdict. Given only two optional parameters and thorough scope coverage, this is nearly complete except for the missing description of 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 coverage is 100% and both parameters are self-documented, so the schema already does the work. The description reinforces the url-vs-jsonld mutual exclusivity and the accepted jsonld shapes (oggetto, array, script), but adds no format syntax beyond that — baseline 3 is right.

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 verb (valida) and resource (dati strutturati JSON-LD), states both input modes (url or jsonld), and enumerates the four validation levels with concrete checks. This is far more specific than any sibling SEO tool, so the agent can distinguish it immediately.

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 jsonld parameter note ('prima di pubblicarlo') and the four-level breakdown make the intended use clear: pre-publish and post-publish structured-data validation. It does not, however, state when not to use it or name an alternative, so it stops 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the description only needs to add context. It does add value by disclosing that the tool also returns remediation guidance for broken sources, but it says nothing about whether credentials/keys must already exist, how long the probe takes, or how results are shaped.

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: the object of the check comes first, followed by the added remediation behavior. Nothing could be cut without losing 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?

With no parameters, no output schema and a readOnly annotation, the description carries most of the remaining burden and does cover what is checked and what extra guidance comes back. It stops short of describing the shape of the status report, but that gap is small for a zero-arg diagnostic.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 — there is nothing for the description to disambiguate beyond confirming that no input is required, which the empty schema already makes plain.

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 (verifica/checks) plus the exact resource — which data sources (Search Console, Analytics, Bing, PageSpeed/CrUX) are configured and functional. This diagnostic role is unmistakably distinct from every sibling, which are all data-fetching tools (gsc_*, ga_*, bing_*, psi_*, crux_*).

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 frames a clear context — pre-flight/config validation — and goes further by saying it explains what to do for unconfigured sources, which steers the agent to call it when setup is in doubt. It does not name explicit when-not conditions, but no sibling competes for this job, so the omission is minor.

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