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

Annotations already declare read-only, non-destructive, idempotent behavior, so the description adds meaningful context by revealing the external W3C Jigsaw validation step and the authorization requirement. This goes beyond what annotations alone would convey.

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 concise sentences with no filler. The core action is front-loaded, and the important authorization caveat is placed second without 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?

The tool is simple with one parameter, full schema coverage, rich annotations, and an output schema. The description covers the critical behavioral and authorization context, leaving no essential gap for an agent to call it correctly.

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

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

The schema covers the single parameter fully at 100%, describing filePath as a CSS file path. The description adds no extra semantics beyond the schema, which matches the baseline for fully documented schema coverage.

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 ('Reads') and resource ('a bounded local CSS file') and clarifies the tool's purpose: sending the file to the W3C Jigsaw CSS Validator. This distinguishes it from sibling tools like html.url or links.broken.

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

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

The phrase 'Use only files the user is authorized to share' provides clear usage context and a constraint on acceptable inputs. It does not explicitly name alternatives or when-not-to-use conditions, but the local CSS scope and sibling tool names imply 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?

Annotations already declare read-only, open-world, idempotent, and non-destructive. The description adds that the file's markup is sent to an external service (W3C), that .xhtml uses application/xhtml+xml parsing, and that content must be shareable, disclosing external data transmission and parsing semantics beyond 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?

Three sentences with no filler. The first states the core operation, the second adds a specific parsing detail, and the third adds a critical usage constraint. All earn their 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 one-parameter tool with a rich output schema and annotations, the description covers the input, the external validation behavior, parsing semantics, and an authorization constraint. There are no significant gaps for correct invocation.

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

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

The schema already documents filePath as an absolute or workspace-relative path; the description adds that it must be bounded, local, and only for authorized files, and clarifies .xhtml parsing behavior, enriching the parameter's meaning beyond the schema.

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

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

The description states a specific action (reads a local HTML or .xhtml file and sends it to the W3C Nu HTML Checker), names the resource, and the title reinforces validation. The 'local' qualifier distinguishes it from html.url and other siblings.

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 clear context: use with local HTML/.xhtml files, and only files the user is authorized to share. It does not explicitly name alternatives like html.url, but the 'local' scope and authorization constraint effectively guide selection.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful context beyond those hints: the fetch is bounded, it delegates to the W3C Nu HTML Checker, and specific destination classes are rejected. No contradiction with annotations is present.

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 scoped sentences that front-load the core mechanism and then state rejection constraints. Every sentence earns its place with no filler or repetition.

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

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

For a single-parameter tool with a full output schema, the description covers the operation, the external checker dependency, and the boundary conditions. Nothing an agent needs in order to correctly select and invoke this tool for a public URL 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 input schema already documents the url parameter as a public HTTP(S) URL on port 80 or 443. The description reinforces this constraint but adds no substantial new parameter-level semantics beyond what the schema states, so the baseline score of 3 is appropriate.

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

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

Description opens with a concrete action—fetching a bounded public HTTP(S) page and sending its markup to the W3C Nu HTML Checker—and the title 'Validate a public URL' reinforces the operation. The explicit focus on remote public pages distinguishes it from local and CSS-specific sibling validators like html.local and css.local.

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

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

The description clearly states when to use the tool: validating a public HTTP(S) URL. It also gives explicit when-not conditions by rejecting private, reserved, credentialed, and nonstandard-port destinations. It stops short of explicitly naming sibling alternatives such as html.local, so it is not a full routing guide.

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 annotations, the description adds meaningful behavioral details: redirects are reported but not followed, and response bodies are discarded. These are important for understanding how links are checked and align with readOnlyHint and idempotentHint. No contradiction.

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 concise behavioral constraints. Every clause adds information, and there is 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?

Given the output schema exists, return values don't need description. The description covers limit, redirect handling, and body handling, which are the key operational details an agent needs before invoking. It doesn't mention possible errors or network dependencies, but annotations and schema cover much of that 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 the baseline is 3. The description does not directly explain parameters but reinforces maxLinks ('up to 25') and htmlContent ('supplied HTML'), while baseUrl is left to the schema. No extra value beyond schema, but no 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 clearly states the tool checks public HTTP(S) links in supplied HTML, with a precise verb ('checks') and resource ('up to 25 public HTTP(S) links'). It also distinguishes itself by noting redirects are reported but not followed and response bodies are discarded, making its function specific and 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?

The description implies usage for link checking in HTML but does not explicitly state when to prefer this tool over alternatives or when not to use it. It doesn't mention sibling tools like html.url or report.validation, leaving the selection partly to inference.

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

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints, so the description's burden is lighter. It adds meaningful behavior: it performs combined W3C/local/JSON-LD/public-link checks and produces both Markdown and structured output. The 'bounded public-link check' clue also hints at external network behavior without contradicting 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?

One dense, front-loaded sentence communicates the tool's purpose, scope, and output format with no filler. Every part of the sentence adds useful information.

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

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

For an aggregate validation tool with a rich output schema and strong annotations, the description is largely complete. The main gap is optional-parameter behavior: an agent cannot tell from the description how omitting cssFilePath or baseUrl affects which checks run, nor exactly what 'bounded' means for the public-link check.

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 baseline is 3. The description's check categories map loosely to the parameters, but it adds no explicit detail about whether cssFilePath gates CSS validation or whether baseUrl gates the public-link check. The schema itself already carries the parameter 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?

The description states a specific verb and resource: it combines validations 'into a Markdown and structured report.' It enumerates the exact check categories, which clearly distinguishes this aggregate tool from single-purpose siblings like html.local, css.local, links.broken, schema.markup, and seo.metadata.

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

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

The description implies this is the all-in-one validation tool, but it never explicitly says when to prefer report.validation over the individual sibling tools or when not to use it. The aggregation language gives useful context, but the agent must infer the tool-selection logic.

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 convey read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context beyond annotations: processing is local, not network-based, and it specifically detects empty blocks and JSON syntax errors. No contradiction 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?

Two sentences carry the core action, output scope, and an important limitation with zero filler. The primary behavior is front-loaded, and 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 simple one-parameter tool with rich annotations and an output schema, the description fully covers what the tool does, where it runs, what it reports, and what it deliberately omits. An agent has enough information to invoke it correctly and set expectations.

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

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

The input schema has 100% coverage with a clear description of 'htmlContent' as raw HTML containing JSON-LD script blocks. The tool description mostly restates this relationship and adds context about local parsing and error reporting, but it provides little additional parameter-level meaning beyond the schema.

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

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

The description specifies a concrete action ('Parses JSON-LD blocks in supplied HTML'), the exact scope ('locally'), and the kinds of results it reports ('empty blocks or JSON syntax errors'). It also distinguishes itself by explicitly stating what it does not do: 'does not validate vocabulary semantics.'

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

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

The phrase 'in supplied HTML locally' gives a clear context for when to use this tool: when the input is a local HTML string rather than a URL. The explicit non-goal of not validating vocabulary semantics provides a when-not signal, though it does not name any alternative sibling tool.

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

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

The description adds meaningful behavioral details beyond the annotations: sandboxed Chromium, first-use browser download, and possible replacement of existing files. These details enrich the destructiveHint and openWorldHint annotations without contradicting them.

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 well-ordered sentences: the core rendering/writing behavior, the runtime browser download behavior, and the destructive caveat. Every sentence earns its place with no filler or repetition.

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

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

The schema and annotations cover parameter details, safety, and idempotency, while the description adds the non-obvious runtime facts: sandboxing, first-run browser download, and potential file replacement. Nothing essential for invoking the tool 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%, and each parameter already has a clear description. The description's reference to the 'requested directory' adds little beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the action ('writes PNG screenshots') and the resource ('local HTML file or HTTP(S) URL'), which distinguishes it from sibling tools focused on HTML, CSS, SEO metadata, and validation. However, it does not explicitly contrast itself with any sibling, so it stops just 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?

The description states what inputs are accepted but gives no guidance about when to use screenshot.capture versus the sibling tools. There is no mention of use cases such as visual verification, or exclusions such as 'use html.local for DOM inspection instead.'

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world; the description's 'supplied HTML' and 'offline' wording reinforces that nothing is fetched, which is useful confirmation. It also scopes exactly which audit categories run, but says nothing about the result shape or how issues are counted/severity-ranked — acceptable given an 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?

Two sentences, zero filler. The capability statement is front-loaded and the disambiguation/routing clause follows, which is exactly the order 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 annotations covering the safety profile and an output schema covering return values, the remaining burden on the description is scope and sibling routing — both fully discharged. Nothing an agent needs in order to call this 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 the schema already documents it at 100% coverage, so the baseline applies. The description still adds a meaningful disambiguation beyond the schema: the input is 'supplied HTML' inspected locally, making clear the parameter is raw markup rather than a URL or path.

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 (audits) and resource (supplied HTML) plus the exact check categories: SEO metadata, headings, viewport, image alternatives, Open Graph. The word 'offline' scopes it against the URL-fetching siblings, so an agent can distinguish it from html.url 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?

Explicitly states the selection rule ('use for a quick on-page check') and then routes three named alternatives to their specific conditions: html.local/html.url for W3C validation, schema.markup for JSON-LD, report.validation for a combined local-file report. Both when-to-use and when-to-look-elsewhere are covered.

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