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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered by structured data. The description adds the notion that the contract is 'canonical installed', i.e., reflects the live installation, which is genuinely useful context, but it says nothing about size, pagination, or freshness beyond that.

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 preamble or filler. The trailing enumeration of contents is long but each item carries information, so it stays on the right side of the conciseness line.

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 an output schema present, the description need not explain return values, and with full annotation coverage the safety profile is handled. Listing the contract's sections is enough for an agent to decide to call it; the only real gap is disambiguation from fullbleed_capabilities.

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 there are no parameter semantics to document and the baseline is 4. Nothing in the description misrepresents the argument surface.

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 (Read) and resource (the canonical installed contract) and enumerates what that contract contains (version, commands, schemas, capabilities, profiles, examples, limitations, recommendation boundary). It is clear what the tool returns, though it does not explicitly differentiate itself from the overlapping sibling fullbleed_capabilities, which appears to cover a subset of the same content.

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 'canonical' implies this is the authoritative source to consult, which hints at when to use it. However, no alternative or condition is named — an agent cannot tell from the description whether to call this or the sibling fullbleed_capabilities first. Usage is implied rather than guided.

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 openWorldHint, destructiveHint, and idempotentHint, so the safety profile is partly covered; the description adds real context beyond them by disclosing that install writes workspace assets and may download remote packages, and that results are package details or operation results. It stops short of telling the agent which of the five actions is the destructive one.

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, front-loaded with the verb-resource-actions summary, then the side-effect disclosure, then the routing hint. No sentence is redundant with another.

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 seven-parameter, five-action, open-world tool with a full output schema and rich parameter docs, the description supplies the essentials: scope of actions, write/download behavior, and alternative tools. The remaining gap is which actions are read-only versus destructive, which annotations partly imply but do not attribute to specific actions.

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 the parameter descriptions already explain per-action applicability, defaults, and constraints, so the schema carries the load. The description adds only marginal parameter meaning ('lock ... using add', 'install writes workspace assets') beyond what is already documented.

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 (font, CSS, icon packages) and enumerates the five operations (list/info/install/verify/lock), so an agent knows exactly what the tool does. Sibling differentiation is only partial: it names fullbleed_inspect and fullbleed_verify as alternatives, but does not distinguish itself from the other eight siblings such as fullbleed_compile or fullbleed_render.

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 routes the agent away from this tool for two adjacent tasks ('Use fullbleed_inspect for PDFs and fullbleed_verify for document validation'). It gives clear context for the mutating install path but never states when-not to use it against the remaining asset-adjacent siblings.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds limited extra behavioral context by naming the content type (feature map, PDF profile requirements), but it does not disclose caching, auth requirements, or other operational traits. A 3 is appropriate given the annotations carry the main behavioral load.

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, both front-loaded and purposeful. The first sentence states what is read and when; the second routes to the alternative tool. 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 zero-parameter read-only capability query with rich annotations and an output schema, the description supplies everything an agent needs: what is returned, when to call it, and where to go for deeper schemas or limitations. Return-value details are correctly left to the output schema.

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

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

The tool takes zero parameters, and schema coverage is 100%, so the schema fully defines the call shape. The description appropriately avoids repeating parameter details; baseline 4 applies for a zero-param 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?

The description states a specific verb and resource: 'Read the installed runtime's compact feature map and PDF profile requirements.' It also distinguishes this tool from fullbleed_agent_contract by assigning the latter to command schemas and detailed limitations, letting an agent route correctly without inspecting schemas.

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 gives an explicit timing rule ('before choosing features') and names the alternative tool with its specific purpose for other needs. This is a clear when-to-use and when-to-use-else statement.

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 destructiveHint=true, non-idempotent and non-read-only, so safety is covered. The description adds genuinely useful context the annotations cannot: the returned handle is process-scoped, dies on restart, and is evicted after 64 retained handles, forcing recompilation. It still does not say what the compile writes or whether recompiling is cheap, which keeps it short of a 5.

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

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

Three sentences, no filler: artifact/return value first, then the handle lifecycle caveat, then the alternative route. Every sentence earns its place and the most decision-relevant information is front-loaded.

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

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

With an output schema present, the description needn't explain returns, and it correctly focuses on what structured data cannot convey: handle lifetime and the sibling split. The remaining gap is behavioral detail around the destructive/non-idempotent profile (what is written where, cost of recompiling), which matters for a 12-parameter compile 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 100% across 12 parameters, including the nested pdf_vt_job hierarchy and profile requirements, so the schema carries the load. The description only reinforces the inline HTML/CSS nature of the input and adds nothing about individual parameters (profiles, intents, timestamps), which is the baseline 3 case.

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 ('Compile inline HTML/CSS') and names its output artifact (compile_id plus template statistics), which immediately distinguishes it from the render tools. It also explicitly differentiates itself from fullbleed_compile_vdp, so an agent can route without opening either 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 when-to-use ('for repeated calls to fullbleed_render_compiled') and names an alternative (fullbleed_compile_vdp) with the condition that selects it (single variable-data job without retaining a handle). It does not address the other compile-adjacent siblings such as fullbleed_render or preflight presets, so routing is clear for the main fork but not exhaustive.

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=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description adds non-obvious lifecycle context ('Releases the temporary handle after rendering') and summarizes outputs, though the output schema already carries return values. It does not contradict 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?

Three front-loaded sentences with zero waste: purpose, lifecycle, then alternative routing. The output summary is brief and skimmable, earning its place without bloating the definition.

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 complex 16-parameter tool with nested objects and an output schema, the description adequately covers purpose, alternative workflow, and handle lifecycle. It does not restate required parameters or PDF profile requirements, which the exhaustive schema and annotations already handle, so it is complete enough without being maximal.

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 all 16 parameters—including nested objects, enums, and PDF profile constraints—are fully documented in the schema. The description only briefly echoes 'inline HTML/CSS' and 'columnar variable records' without adding syntax or format detail 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?

States specific verbs ('Compile and render') and resources ('inline HTML/CSS', 'columnar variable records', 'one PDF'), and explicitly distinguishes itself from fullbleed_compile plus fullbleed_render_compiled. An agent can tell this is the one-shot VDP compile-and-render tool without opening 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 an explicit routing rule: use this tool for one-shot compile-and-render, and use fullbleed_compile plus fullbleed_render_compiled when reusing a template across calls. The alternative is named with the condition that selects it, leaving little 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 declare the write/non-idempotent profile, and the description adds the key behavioral constraint that the target must be absent or empty plus the fact that artifacts and next actions are returned. It does not say what happens if the directory is non-empty, which is the main remaining gap.

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 what is produced, the second gives the trigger and the follow-up tools. No filler and the important scoping constraint is front-loaded.

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

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

With an output schema present, the description need not explain return values, and it still notes that artifacts and next actions come back. Combined with the annotations and complete schema, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100%, with the template enum and target_path fully documented in the schema. The description's mention of an 'absent or empty workspace directory' merely restates the target_path constraint rather than adding syntax or format detail.

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 (create) and resource (agent-ready project or document scaffold), and names the sibling tools that consume the output (fullbleed_render, fullbleed_render_preview), so it is clearly distinguished from the render family.

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 says when to use it ('when starting a project') and routes to the correct downstream tools. It does not, however, explain the choice between render vs render_preview or when a scaffold is unnecessary, so it stops short of full when/when-not coverage.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's 'without changing it' merely restates readOnlyHint and it adds no new behavioral detail such as failure modes on malformed PDFs or path-resolution behavior. Adequate but not additive over the structured fields.

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: the first front-loads what gets read and enumerates the outputs, the second handles disambiguation. No filler and no 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?

An output schema exists, so return values need not be described, and the one input parameter is fully covered by the schema. Combined with explicit sibling routing, an agent has everything needed to call this 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?

There is a single parameter and schema coverage is 100%; the schema itself already disambiguates that the path points to a PDF and not HTML source. The description adds no parameter-level syntax, so baseline 4 for a one-param, fully documented 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?

States a specific verb (Read/Inspect) and resource (existing PDF) and enumerates exactly what is exposed: version, page count, profile claims, warnings, and template-composition compatibility. It also implicitly separates itself from render/verify siblings by scoping to an existing PDF rather than source.

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 routes the agent: use fullbleed_verify for rendering/checking HTML/CSS source and fullbleed_assets with action='verify' for asset packages. Both the when-to-use and the concrete alternative invocations are given, leaving nothing 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 declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the write/replace profile is covered structurally. The description adds useful non-annotation context: it returns render diagnostics, does not execute JavaScript, and does not fetch live sites. It could go further on overwrite/atomicity behavior, but the added boundaries are real value.

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, front-loaded with the action and return value, then the exclusivity constraint, then sibling routing. No filler and nothing an agent must read past to find the core capability.

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 an output schema present, return values need not be explained, and the description covers capability, inputs constraint, and sibling selection for a complex nested-schema tool. It leaves profile/pdf_profile interaction and the destructive overwrite of output_path to the schema, which is acceptable but slightly thin for a 19-parameter destructive 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 100% across all 19 parameters, including the tricky profile-vs-pdf_profile split and the ICC output-intent prerequisites, so the schema carries the semantics. The description only restates the html/html_path exclusivity already documented in both parameter descriptions, adding no syntax or format detail beyond it.

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

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

States a specific verb and resource (render static HTML/CSS to PDF), names the concrete outputs (output paths and render diagnostics), and draws a hard boundary ('Does not capture live websites') that separates it from a browser-capture tool. An agent can distinguish it from fullbleed_render_preview or fullbleed_render_compiled 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 routes the agent: fullbleed_render_preview for visual iteration, fullbleed_verify for delivery checks, fullbleed_compile_vdp for variable records, and states the mutual-exclusion rule 'Supply exactly one of html or html_path.' Both the when-to-use and the selection conditions are present.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is largely covered. The description adds the session-bound nature of compile_id and the returned artifacts (path, counts, SHA-256), but does not itself warn that an existing output file is replaced (that detail lives in the schema). Modest added value on top of 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 tight sentences: the write action and input first, the mode choice and return values second, the sibling routing last. No filler and the operative information is front-loaded.

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

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

With an output schema present, return values need not be spelled out, yet the description briefly confirms them; the session-scoped compile_id constraint and mode selection are covered. Slightly incomplete about what 'choose' means operationally and when to prefer the non-VDP render 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 100%, so every parameter including mode, bindings, copies, and compression is already documented with enum semantics. The description's 'static copies, fixed geometry, or content reflow' merely paraphrases the enum values and adds no format or constraint 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?

Starts with a specific verb+resource ('Write a PDF') and immediately scopes the input to a compile_id from fullbleed_compile in the same session. This distinguishes it from fullbleed_compile, fullbleed_render, and fullbleed_render_preview without opening another 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 routes one alternative use case ('Use fullbleed_compile_vdp to compile and render a variable-data job in one call'), which tells the agent when to prefer a sibling. It stops short of naming the conditions for the other render siblings (fullbleed_render, fullbleed_render_preview).

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the write/overwrite safety profile is covered by structured data. The description adds that artifacts are paths returned and frames this as a post-change visual check, but does not elaborate on which files get replaced or how outputs are named (that detail lives only in the output_dir schema). With annotations carrying the risk profile, a 3 is appropriate.

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

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

Three tight clauses with zero filler, front-loaded on purpose and output, followed by the input constraint, then sibling routing. 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?

With an output schema present and a fully documented schema, the description needn't explain return values or parameter mechanics, and it correctly focuses on purpose and routing. It is slightly thin on the destructive-replace behavior mentioned only in the output_dir schema, but that is a minor gap given the annotation 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% across all 18 parameters, so the schema already documents every argument in detail (dpi bounds, font registration, ICC/output-intent requirements, etc.). The description adds the 'supply exactly one of html or html_path' constraint, but that is already stated in both parameter descriptions, so it is repetition. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description gives a specific verb+resource (render a PDF plus PNG page previews) and even states the return shape ('returns their artifact paths'). It explicitly distinguishes itself from two siblings, fullbleed_render and fullbleed_verify, so an agent can select it without opening any 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?

It states the context of use ('after document changes; for visual inspection') and names both alternatives with the condition that selects them: fullbleed_render for PDF-only output, fullbleed_verify for explicit failure checks. It also states the one-of constraint on html/html_path, removing ambiguity.

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 destructiveHint=true and readOnlyHint=false; the description does not contradict these, but it also fails to explain the destructive nature (e.g., emit_pdf_path replacing files). It does add valuable context that JavaScript is not executed, internal checks do not establish independent standards conformance, and budget checks require the CLI, which are not inferable from 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, front-loaded with the core action and output, then usage constraints, then a critical scope caveat. No redundancy, 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 complex tool with 17 parameters, nested schema, and an output schema, the description covers the main entry points (html/html_path exclusivity, fail_on, alternative tool) and a key behavioral caveat. It omits guidance on the many PDF export parameters (pdf_profile, emit_pdf_path, document metadata), which are left to the exhaustive schema, but the output schema exists so return values need not be explained.

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

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

Schema description coverage is 100%, so the schema already documents all 17 parameters, including the fail_on enum and pdf_vt_job hierarchy. The description mentions selecting fail_on explicitly but adds no syntax or format details beyond the schema, so it earns the baseline 3.

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: renders HTML/CSS through the validation path and returns diagnostics/failures before delivery. It distinguishes from fullbleed_inspect by name, but does not clarify how it differs from the render siblings (fullbleed_render, fullbleed_render_preview, fullbleed_render_compiled), which is a missed routing opportunity.

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 concrete usage conditions: supply exactly one of html or html_path, select fail_on checks explicitly, and use fullbleed_inspect for existing PDFs. It lacks 'when not to use' beyond that single alternative, so it doesn't fully meet the 5-level bar of explicit alternatives and exclusions.

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