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

With no annotations, the description carries the full behavioral burden but only restates the return contents. It omits operationally important traits of a remote PageSpeed Insights call: expected latency, rate limits, whether the request is cached, and any auth/permission requirements.

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 with zero filler; the action is front-loaded and the second sentence cleanly covers what comes back.

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 sketch the return payload (scores, metrics, opportunities), which is helpful. But for a slow external-API tool that overlaps heavily with nine siblings, it should do more to explain selection and 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 100%, so url, strategy, and categories are already fully documented in the schema. The description adds no syntax, default, or format detail beyond what the schema provides, making the baseline 3 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 and resource ('Run a ... Google PageSpeed Insights analysis on a URL') and the scope ('comprehensive', 'all category scores'). However, it never names or contrasts itself against the many granular siblings (get_performance_metrics, get_recommendations, get_js_analysis, etc.), so the agent must infer that this is the aggregate superset rather than one of the focused 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 word 'comprehensive' implies this is the all-in-one entry point, but the description gives no explicit when-to-use versus when-to-prefer-a-sibling, and no prerequisites. Usage is only implied, not stated.

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 no annotations, the description carries the full burden, and it does disclose what the response contains (score deltas across all categories plus key metric comparisons). However, it omits operationally important traits such as the fact that it effectively runs two PSI analyses (latency/cost), any API key or quota requirements, and whether results are cached.

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 filler, with the core comparison scope front-loaded in the first sentence and the outcome in the second. Nothing is repeated from the name or title.

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 adequately summarizes the return surface (score differences and metric comparisons). It is close to complete for a simple two-parameter read tool, losing a point only for the missing usage routing and cost/quota context.

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

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

Schema description coverage is 100%, so both url and categories are already documented in the schema; that sets the baseline at 3. The description adds nothing about parameter behavior beyond the phrase 'across all categories', which only loosely gestures at the categories default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compare) and a precisely scoped resource (mobile vs desktop PageSpeed Insights results side-by-side for a URL). No sibling tool does a cross-strategy comparison, so an agent can distinguish it from analyze_url and the other single-dimension getters 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?

Usage is only implied: the description gives a rationale ('to identify strategy-specific issues') that hints at when the tool is appropriate, but it never states when to prefer this over analyze_url or any sibling, nor any prerequisites or 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?

No annotations are provided, so the description carries the full burden. It does disclose the return shape (score, failing checks grouped by impact level, affected elements, remediation guidance), which is genuinely useful given there is no output schema. However it says nothing about permissions, rate limits, or which URL scopes are valid, and the read-only nature is only implied.

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 tightly written sentences with zero waste; the purpose is front-loaded and the return-value detail follows immediately. Nothing needs trimming.

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 summarizes the returned content (impact grouping, affected elements, remediation guidance), and the input schema fully covers both parameters. A mention of auth requirements or a usage precondition would be needed for a 5.

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% (both 'url' and 'strategy' are documented, with an enum for strategy), so the schema already does the heavy lifting. The description adds no syntax, default, or format detail beyond it, making the baseline 3 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 uses a specific verb ('Get') and resource ('accessibility audit results for a URL'), clearly distinguishing it from siblings like get_performance_metrics and get_network_analysis by domain. It does not explicitly name or contrast with a sibling, so it falls short of a full 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?

The description states what the tool does but gives no when-to-use vs when-not guidance, no prerequisites, and does not reference any of the nine sibling analysis tools as alternatives. The agent must infer routing purely from the resource name.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It describes what the analysis identifies, but never states whether the operation is read-only, whether it modifies the site, what permissions are needed, or how results are returned. This leaves important behavioral traits undisclosed.

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 followed by a compact list of detection targets. 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?

For a two-parameter analysis tool with full schema coverage and no output schema, the description covers purpose and output categories. However, with no annotations and no usage guidance, it omits behavioral context that an agent would need to confidently select and invoke it among many sibling analysis tools.

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%: the url and strategy parameters are fully described in the schema, including format and enum default. The description adds no additional meaning about parameter syntax, constraints, or the effect of the strategy choice beyond what the schema already provides.

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: get image optimization analysis for a URL, and enumerates the findings (compression, format conversion, lazy-loading, layout shifts). It does not name any sibling or explain how it differs from get_performance_metrics or get_recommendations, so it is clear but lacks sibling differentiation.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling analysis tools. The only implied usage is that an agent should call it when image optimization analysis is wanted, which is minimal.

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 no annotations, the description carries the full behavioral burden. It usefully discloses the return contents (JS boot-up time, main-thread breakdown, unused JS, most expensive scripts), which partly compensates for the absent output schema, but says nothing about cost, latency, auth, or side effects.

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, front-loaded with the purpose and followed by the concrete return breakdown. 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?

For a simple two-parameter read analysis with full schema coverage, the description is nearly complete: it names the resource and enumerates the returns, compensating for the missing output schema. The one gap is the lack of relationship to analyze_url and the other dimension tools, and no indication of whether prior analysis is required.

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

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

Schema description coverage is 100%, so both url and strategy are fully documented in the schema. The description adds no parameter detail (e.g. what mobile vs desktop changes, or URL format constraints) beyond the schema, 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?

Clear specific verb+resource: 'Get JavaScript execution analysis for a URL', with the returned artifacts enumerated. It is distinguishable from siblings like get_network_analysis and get_render_blocking by the JS-execution focus, though it never explicitly differentiates itself from them or from the parent analyze_url.

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

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

No when-to-use guidance, no prerequisites (e.g. whether the URL must first be analyzed), and no mention of when to prefer this over analyze_url or the other per-dimension siblings. Usage is only implied by the tool name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It describes what is returned but not mutation/read-only nature, cost of call, latency, or whether the URL is fetched live versus analyzed from a cache.

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 enumerates the three output categories with no filler. 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 read-only analysis tool with fully documented parameters, the description is minimally viable. Without annotations or an output schema, it should disclose whether the analysis is live or cached and roughly what the response contains beyond the three named categories.

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

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

Schema coverage is 100%, so both parameters (url, strategy) are already documented with format and enum in the schema. The description adds no parameter-level meaning beyond what the schema provides; 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 and resource ('Get detailed network analysis for a URL') and enumerates the outputs (resource breakdown, transfer sizes, largest resources). This distinguishes it from most siblings, though it doesn't explicitly differentiate from close alternatives like get_render_blocking or get_performance_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?

No when-to-use guidance or alternatives are mentioned. Given nine siblings with overlapping analysis domains (analyze_url, get_performance_metrics, compare_strategies), the agent is left to infer which tool to call.

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 no annotations, the description carries the full burden, and it does disclose the returned metric set (score, LCP, CLS, TBT, FCP, Speed Index, TTI, TTFB with ratings). However it says nothing about cost/latency of the live analysis, failure modes for unreachable URLs, or that it is a read-only fetch.

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 with zero filler; the purpose leads and the return contract follows. Every element earns its place, especially since no output schema exists.

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?

Because there is no output schema, enumerating the returned metrics is genuinely useful and largely closes the return-value gap. What remains missing is operational context (expected runtime, error behavior, whether results are cached) for what is likely an expensive live audit.

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 url and strategy (including the mobile/desktop enum and mobile default) are already fully documented in the schema. The description adds only 'for a URL' and says nothing about what strategy changes, so 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 (Get) and resource (Core Web Vitals and key performance metrics) plus the target (a URL), which separates it from sibling diagnostics like get_network_analysis or get_js_analysis. It does not name a sibling it is not, so it stops short of full differentiation.

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

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

There is no when-to-use guidance, no prerequisite, and no mention of alternatives such as analyze_url or compare_strategies, which sit right next to it in the toolset. The agent must infer that this is the overall-performance entry point purely from the name.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return behavior (sorted by estimated impact, savings in ms and bytes), which is genuinely useful, but says nothing about permissions, caching, rate limits, or whether the analysis is live vs cached.

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 purpose and followed by return behavior. Every sentence earns its place with no 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?

With no output schema and no annotations, the description usefully covers the return shape (prioritized, impact-sorted, ms and bytes). For a simple two-parameter read tool this is largely sufficient, though it could state prerequisites or that it is read-only.

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

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

Schema description coverage is 100%, so both 'url' and 'strategy' are fully documented in the schema, including the enum and default. The description adds no format or constraint details 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 and resource: 'get prioritized performance improvement recommendations for a URL.' This distinguishes it from raw-metric siblings like get_performance_metrics, but it never names or contrasts an alternative, so it stops short of full sibling differentiation.

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

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

The word 'recommendations' implies the use case (wanting prioritized fixes rather than raw data), but there is no explicit when-to-use, when-not, or reference to siblings like analyze_url or compare_strategies. Usage must be inferred.

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 no annotations provided, the description carries the full disclosure burden. It usefully clarifies the scope of the analysis (first-paint blocking, critical chains), but says nothing about authentication, rate limits, cost, or whether results are cached — behavioral traits an agent would want before invoking it.

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

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

Two sentences, front-loaded with the core purpose and then the specifics of what is identified. No filler and nothing redundant.

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

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

For a two-parameter analysis tool with no output schema and no annotations, the description tells the agent what the analysis is about but not what the response contains or how it differs operationally from sibling analyses. It is adequate but leaves the agent to infer the return shape and comparative value.

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

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

Schema description coverage is 100%, so both 'url' and 'strategy' are already fully documented in the schema with an example and a default. The description adds no syntax, format, or defaulting nuance beyond the schema, 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 states a specific verb and resource: 'Get render-blocking resource analysis for a URL', and then enumerates what the analysis covers (CSS/JS blocking first paint, critical request chains, preconnect/preload opportunities). This distinguishes it from siblings like get_js_analysis and get_network_analysis, though it never names those alternatives directly.

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 it should call this when it wants render-blocking diagnostics for a page. There is no explicit when-to-use, when-not-to-use, or routing to sibling tools such as get_js_analysis or analyze_url, which is a clear gap in a nine-tool family.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully describes the analysis output (which providers load, transfer sizes, main-thread blocking time, facade opportunities), which matters because no output schema exists. However, it omits authentication requirements, rate limits, and any explicit read-only or side-effect profile, leaving gaps for a tool with zero annotation coverage.

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 states the purpose and scope, the second lists the return content. It is front-loaded and every clause earns its place with 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 a simple two-parameter read-only analytics tool with no output schema, the description explains what the tool does and what the analysis returns. It is nearly complete, though it does not clarify strategy parameter behavior or safety context, which is largely acceptable given the 'Get' naming and full schema coverage.

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

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

Schema description coverage is 100%, so the schema already documents both parameters including the strategy enum and default. The description only mentions 'for a URL' and adds no format, constraint, or interpretation details beyond what the schema provides. 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 'Get' and resource 'third-party script impact analysis for a URL', and names the concrete outputs (providers, transfer sizes, blocking time, facade opportunities). It distinguishes its scope from siblings like get_network_analysis and get_js_analysis, but does not explicitly differentiate itself from those alternatives.

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

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

No when-to-use or when-not-to-use guidance is provided. It does not mention prerequisites, alternatives, or conditions under which an agent should choose get_network_analysis or get_render_blocking instead. Usage is only implied by the tool's purpose.

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