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 goes beyond that by disclosing the heuristic's actual mechanics: contrast is measured against an opaque Inkscape page background when present, otherwise white, and only direct hex fills are considered. That tells the agent when results will be unreliable, which is valuable behavioral 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 no filler, and the core purpose is front-loaded before the heuristic caveats. The semicolon clause is dense but each part 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?

An output schema exists, so return values need not be explained, and annotations cover the read-only nature. What remains missing is any parameter explanation and any routing guidance among the many inspect/preflight siblings, leaving the definition only minimally complete.

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

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

Schema description coverage is 0% for two required parameters, and the description never mentions path or workspaceId. It does not compensate for the gap, so the agent must infer that path is an SVG file and workspaceId a workspace identifier from the schema patterns alone.

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-plus-resource: heuristic SVG text-contrast and document reading-order diagnostics. That scope is distinct from siblings like document_inspect, document_preflight, and color_management_inspect, so an agent can identify what this tool uniquely covers, though the phrasing is dense.

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 mention of alternatives (document_inspect, document_preflight, color_management_inspect, palette_inspect all sit nearby), and no prerequisites such as needing an SVG document in the workspace. Usage is only implied by the word 'accessibility'.

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 ownership ('owner-bound') and size-limiting ('bounded') context beyond annotations, but never states what happens past the bounds, whether reads are streaming, or any auth/error behavior. With annotations carrying the read-only signal, this is adequate but thin.

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, purpose front-loaded, alternative named second, zero filler. Nothing could be removed without losing routing or scope 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?

An output schema exists so return values need no explanation, but for a 4-param, 0%-coverage read tool the description leaves the offset/length chunking contract unexplained, which is the core usage model. An agent would have to infer how to iterate or how large a chunk may be.

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

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

Schema description coverage is 0% across 4 required params, so the description must compensate. It loosely covers artifactId ('opaque ID'), workspaceId ('owner-bound'), and length ('bounded'), but 'offset' — the parameter that defines the entire chunking mechanism — is never addressed, and no format or range guidance is given.

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?

Specific verb+resource: 'Reads one ... binary artifact chunk', with qualifiers 'owner-bound, bounded' and 'by opaque ID'. An agent can tell it reads raw artifact bytes, not metadata or documents. Sibling differentiation comes only via the generic phrase 'resource links' rather than a named tool, which keeps it from 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?

'Use resource links for ordinary artifact consumption' gives an explicit when-not boundary, implying this tool is for lower-level/chunked access. It stops short of stating the positive trigger (partial reads, offset iteration, or large binaries) or rate/ownership prerequisites.

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 provide destructiveHint=false, so the description carries most of the burden and delivers real value: it states that all package files are published together (atomicity) and that existing files are never overwritten (safety/no-clobber). It still omits what happens on a revision mismatch, permission needs, or whether the output directory must pre-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?

Two sentences, both earning their place, with the core product statement front-loaded and the atomicity/no-overwrite guarantee following immediately. No filler or redundant restatement of the name.

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 output schema exists, so return values need not be explained, and the description covers what is produced and the mutation safety profile. However, four required parameters with zero schema documentation leaves a real gap for an agent about to call this write-style 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 0% across 5 parameters, so the description must compensate and largely does not. Only 'revision manifest' loosely hints at expectedRevision's concurrency role; path, workspaceId, outputDirectory, and the assetLicenses license/sourceUri pair are given no meaning, constraints, or format guidance.

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 ('Creates') and resource ('portable workspace-local SVG package') and even enumerates the package contents (document.svg, rewritten local assets, revision manifest). It is clear what the tool produces, though it never contrasts itself with likely-confusable siblings such as document_export or export_svg, so an agent must infer the difference.

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 mention of alternatives among the many export/document tools in the sibling list. The agent is left to infer that this is the packaging path versus a plain export.

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 destructiveHint=true in the annotations, the description carries real weight and delivers: it discloses the shape constraint ('typed rectangular'), the scoping rule ('from explicit elements'), and a genuine referential-integrity behavior ('prevents deletion while any SVG or CSS reference remains'). It still omits concurrency behavior around expectedRevision and what happens when a guarded delete is rejected.

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 three dense, information-bearing clauses and no filler. It is slightly over-compressed, since the explicit 'delete' action is only implied through the guard clause.

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 four-variant polymorphic tool, the description covers the create/apply/release lifecycle plus a delete constraint, and an output schema exists so return values need not be explained. Remaining gaps (revision/optimistic-concurrency semantics, delete prerequisites) are secondary.

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 reported at 100%, so the baseline is 3; the schema already encodes the four action variants, required fields, patterns, and the spec object. The description adds only marginal meaning ('rectangular' clarifies the spec geometry) and says nothing about expectedRevision or targetIds 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?

The description names the specific resource (typed rectangular SVG clipPaths) and the operations (create, apply, release, and implicitly delete via the deletion guard), so an agent can tell this apart from generic element tools. It does not, however, distinguish itself from the nearby masks_manage sibling or explain the clip-vs-mask boundary.

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 multi-action schema plus the phrase 'applies or releases them from explicit elements' hints at when to use apply/release, but there is no explicit when-to-use, when-not-to-use, or alternative tooling named. The deletion constraint is the closest thing to guidance.

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

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

readOnlyHint=true is already declared, so the safety profile is covered. The description adds real value beyond the annotation by disclaiming what the tool will not do (no CMYK conversion, no PDF/X output-intent validation), which prevents an agent from over-trusting the result.

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 scope disclaimer is tightly integrated rather than 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?

An output schema exists, so return values need not be explained, and the read-only annotation covers safety. However, the two required parameters remain undocumented and there is no usage/routing context, leaving gaps for an agent to fill.

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

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

Schema description coverage is 0% and both required parameters (path, workspaceId) are undocumented in the schema. The description adds no information about what path points to or the workspaceId format, so it fails to compensate for the coverage gap.

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

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

States a specific verb ('Lists') and specific resources ('local SVG color-profile metadata and ICC paint references'), which clearly separates it from write/convert operations. The negative clause sharpens the boundary but the core purpose 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?

No explicit when-to-use or alternatives are named (e.g., palette_inspect, mesh_gradients_inspect). The 'without claiming CMYK conversion or PDF/X output-intent validation' clause does imply a when-not boundary, giving weak scope guidance rather than a genuine routing instruction.

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 destructiveHint=true already declared, the description usefully narrows scope: one typed polyline connector, existing local IDs only, and no SVG/XML or arbitrary connection attributes. It does not explain what a create may overwrite (given destructiveHint) or that expectedRevision guards against stale writes.

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 verb and resource first, and no padding. It is dense but every clause carries information about scope or exclusions.

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 covers return values, but for a 7-parameter mutation tool with 0% schema description coverage the description leaves too much undocumented. An agent cannot infer points format, expectedRevision meaning, or path purpose from either source.

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

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

Schema description coverage is 0% across 7 required parameters, so the description must compensate but largely does not. It only implies fromId/toId via "between two existing local element IDs" and says nothing about id, path, points, workspaceId, or expectedRevision 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 verb ("Creates"), resource ("Inkscape polyline connector"), and scope ("between two existing local element IDs"). An agent can distinguish this from sibling connector_retarget/connector_route, 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?

No when-to-use guidance and no reference to the alternative connector tools (connector_retarget, connector_route). The clause about not accepting SVG/XML is a constraint, not usage guidance, and no prerequisites are 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?

Annotations already flag this as destructive, and the description adds a meaningful behavioral guarantee: the connector's current polyline route is preserved during retargeting. It does not, however, explain what destructive side effects might occur or whether authorization or revision checks apply.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core action and the key preservation guarantee immediately.

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?

Although an output schema exists and the destructive annotation provides some safety context, the input schema has no parameter descriptions. For a six-parameter destructive operation, the description omits required concurrency handling (expectedRevision), workspace scoping, and path semantics, making it too thin for reliable 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?

Schema description coverage is 0% across six required parameters. The description clarifies that two endpoints are involved (fromId and toId) and refers to an existing connector (id), but it does not explain path, workspaceId, or expectedRevision, leaving half the parameters semantically undocumented.

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 precise verb (retargets), a specific resource (existing semantic Inkscape connector), and the action scope (two explicit local endpoints while preserving the polyline route). It clearly distinguishes this mutation from sibling tools like connector_create or connector_route.

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?

Use is implied by 'existing' connector, so an agent can infer this is for modifying rather than creating a connector. However, the description does not explicitly compare against alternatives such as connector_create or connector_route, nor does it state when not to use this tool.

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

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

Annotations only declare destructiveHint=true, and the description does not disclose that the existing connector path is replaced/rewritten or what happens on an unreachable route. It does add algorithmic context beyond annotations (bounded Manhattan routing, obstacles, clearance), which earns partial credit but leaves the destructive side of the operation unexplained.

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 dense, front-loaded sentences with no filler; the action and its routing model come first. Terminology such as 'typed clearance' is slightly opaque but the structure is efficient.

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, 6-required mutation tool with 0% schema coverage, the description omits the meaning of expectedRevision (concurrency guard), path, and id, and offers no failure or permission context. The existence of an output schema excuses return-value explanation, but the input-side gaps are substantial.

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

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

Schema description coverage is 0% for all 9 parameters, so the description must carry the load. It covers the endpoint concept (from/to), obstacleIds ('optional explicit obstacles'), clearance ('typed clearance') and axis ('axis-aligned transforms'), but id, path, workspaceId, and expectedRevision are never clarified, and bounds/semantics of clearance and obstacle limits are absent.

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 (routes) and resource (Inkscape connector) plus the endpoint constraint (rect/circle/ellipse) and routing style (orthogonal). An agent can distinguish it from connector_create, but the description never names or contrasts with those siblings 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?

No guidance on when to use this versus connector_create or connector_retarget, nor prerequisites such as needing an existing connector with both endpoints present. Usage must be inferred from the verb 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?

Annotations only declare destructiveHint=true, and the description adds genuinely useful safety context beyond that: defaults to dry-run, and referenced resources are never rewritten. It stops short of explaining what the plan output contains or how expectedRevision gating behaves.

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 no filler, and the operation plus its safety defaults are front-loaded. It is appropriately sized, though the second sentence is doing parameter work that belongs in the schema.

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 needn't be explained, and the destructive/dry-run behavior is covered. But with 0% parameter description coverage and an undocumented revision guard, an agent lacks enough to invoke this correctly in the non-dry-run case.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate — it only clarifies the dryRun default. Nothing is said about path, workspaceId, or the expectedRevision concurrency token, which is the most consequential parameter to understand.

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: 'Plans or conservatively removes unused top-level SVG definitions.' The scope qualifier (top-level, unused) is useful, but it doesn't differentiate itself from adjacent maintenance siblings such as document_optimize or document_normalize_ids.

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?

'Plans or conservatively removes' plus the dry-run default implies a two-phase plan-then-apply workflow, so usage is inferable. However, it never says when to prefer this over other cleanup/optimization siblings, nor what preconditions (revision match) apply.

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 destructiveHint=true, so the description carries extra burden and delivers: it discloses that operations are validated sequentially against the preceding in-memory result and that a failure leaves the source untouched (all-or-nothing atomicity). That is meaningful behavioral context beyond the annotation and is consistent with destructiveHint. It omits authentication/workspace requirements and dryRun semantics.

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 waste. The purpose is front-loaded in the first clause, and the second sentence adds the atomicity guarantee, so 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 highly complex, many-branch transactional tool with an output schema in place, the description covers atomicity but omits concurrency-control semantics (expectedRevision), the dryRun flag's effect, and any usage routing against sibling mutation tools. Adequate but with clear gaps given 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 description coverage is 0% and the description references none of the six parameters. It says nothing about expectedRevision (optimistic concurrency), dryRun, path, or workspaceId, so it fails to compensate for the prose-description gap. The schema's rich enums/consts describe operation shape structurally, but the top-level control parameters remain unexplained.

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

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

States a specific verb and target: 'Applies a bounded ordered design transaction to an SVG.' The phrase 'design transaction' conveys that this is a batch/atomic operation rather than a single-element mutation, which distinguishes it conceptually from siblings like elements_create or elements_update. However, it never names those siblings or explicitly contrasts the batch approach with the single-operation 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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives. An agent cannot tell from the description why it should batch operations here versus calling elements_create/elements_update/elements_transform individually. The only contextual hint is implicit in the word 'transaction'.

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 only supply destructiveHint=false; the description usefully adds the no-overwrite guarantee ('Existing outputs are never overwritten'), which is real behavioral context. However it does not say what actually happens on path conflict (error vs skip) or note permission/auth requirements, so it adds value but not richness.

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 the core action and creation modes front-loaded, then the no-overwrite guarantee. No filler whatsoever.

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 needn't be explained, and the safety profile is covered by annotations plus the no-overwrite note. But for a 7-parameter creation tool at 0% schema coverage with no preset-vs-custom guidance, the description leaves notable gaps an agent would need to resolve by inspection.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden and largely fails. It loosely gestures at the width/height/unit/preset and outputPath parameters but adds no syntax, format, or constraints (allowed units, preset list, workspaceId format, the pages array).

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 (creates) and resource (SVG document), and names the two creation modes (custom dimensions vs named preset). It clearly reads as a create-new tool rather than the numerous document_import_* siblings, though it does not explicitly contrast itself with import.

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. It never says when to prefer a named preset over bounded custom dimensions, nor does it name an alternative sibling (e.g., document_import) for bringing in existing content.

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 destructiveHint=false. The description adds that conversion runs through a bounded Inkscape pipeline and that legacy vector formats require explicit fidelity acknowledgement, which is useful context, but it omits output write/overwrite semantics, revision checks, and failure 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?

The two sentences are front-loaded and free of filler. The format enumeration is long but functional given the schema's many export branches.

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. Yet for a high-complexity multi-format export with 0% schema description coverage, the description is thin: it lacks sibling selection guidance and does not cover workspaceId or important target/revision semantics.

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

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

Schema description coverage is 0%, and the description does not explain workspaceId or the nested ExportSpec fields such as area, source, target, or format-specific options. It only names the ExportSpec as validated, lists formats, and references fidelity limits, leaving most parameter meaning to the schema structure 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?

The description provides a specific verb and resource: exporting a document/selection to a list of graphic formats from a validated ExportSpec through a bounded Inkscape pipeline. It is clear what the tool does, but it does not distinguish itself from sibling export_png, export_pdf, export_svg, or document_export_batch.

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 a prerequisite ('validated ExportSpec') and a conditional rule that legacy vector formats require explicit acknowledgement of fidelity limits. However, it never says when to choose this tool over narrower export siblings or batch/preset alternatives, so usage remains implied.

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 provide only destructiveHint=false, so the description carries most of the burden. It adds genuinely useful publish semantics: all_or_nothing verifies every variant before one logical publish (atomic) versus best_effort publishing verified successes (partial success). However it omits other material behavior: that outputs are written to disk targets, overwrite semantics, the sync/job delivery switch, timeout behavior, and planToken idempotency/planning 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 no filler, and the batch scope is front-loaded ahead of the mode semantics. It is efficient, though arguably under-sized for a tool whose schema is this deep.

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

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

For a tool with 7 parameters, 0% schema description coverage, deeply nested oneOf format branches, and only a destructiveHint annotation, the description is far too thin. The elements an agent most needs (planToken sourcing, delivery mode, timeout, overwrite/expectedRevision concurrency behavior) are absent, though the presence of an output schema excuses it from documenting return values.

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

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

Schema description coverage is 0%, so the description must compensate for 7 parameters, yet it only loosely maps to mode and never mentions specs, preset, delivery, planToken, timeoutMs, or workspaceId. The names 'all_or_nothing' and 'best_effort' roughly correspond to mode enum values, but planToken (which links to the document_export_preset_plan sibling) and delivery are left entirely unexplained.

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

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

States a specific verb and resource ("Renders a bounded batch of ... variants"), which is clearer than a tautology. But the enumerated formats (PNG, PDF, SVG, plain SVG) are only a subset of what the schema actually accepts (ps, eps, emf, wmf, xaml, dxf, hpgl, fxg, sif, gpl, svgz), so the scope statement is partially misleading. It also gives no differentiation from near-identical siblings such as document_export, export_png, export_pdf, or document_export_preset_plan.

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 two clauses explain what the mode values do, not when to pick this tool over document_export, export_png, or document_export_preset_plan. No prerequisites, no exclusions, no guidance on batching vs single export. An agent must infer usage entirely 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?

Consistent with readOnlyHint=true: 'without publishing files' confirms no side effects. Beyond annotations it discloses the owner-bound, single-use, expiring token and that the plan is pinned to the source revision and observed Inkscape capabilities. It omits what happens on expiry or token misuse, so not 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?

Two sentences, front-loaded with the core action and output. Slight redundancy between 'single-use plan token' and 'must use the token before it expires', but every sentence is relevant.

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 no explanation, and the description covers the preflight-then-execute contract. Against a parameter count of 3 with a large nested preset object at 0% coverage, though, the description leaves several structural details to the schema alone.

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

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

Schema coverage is 0%, so the description carries the burden. It meaningfully hints at preset name, source revision (expectedRevision), and TTL ('before it expires'), but never mentions workspaceId or the preset's outputDirectory/metadata/overrides structure. Partial compensation for a deeply nested 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?

Names a specific verb and resource ('Preflights one named export preset'), states the key output ('single-use plan token'), and clarifies it does not publish files, which separates it from the export siblings. It does not name an alternative (e.g., document_export) explicitly, so it stops short of 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 implied: preflight a preset, then execute with the returned token before expiry. However it never names the tool that consumes the token nor states when to prefer this over sibling exports like document_export or document_export_batch, leaving the agent to infer the workflow.

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 carry destructiveHint=true, so the description must carry the rest of the burden. 'This never transforms objects' is a genuinely useful clarification about what is and isn't mutated, but it omits concurrency/optimistic-locking behavior around expectedRevision, permission needs, and what page state changes. Adds real value but leaves major gaps.

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, front-loaded with the core action and followed by the key non-mutation caveat. Nothing is wasted.

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 needn't be described, but a destructive, revision-guarded mutation tool with 7 parameters (5 required), nested margins, and 0% param coverage is under-specified. An agent cannot reliably invoke this without inferring parameter meanings and lock semantics.

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

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

Schema description coverage is 0% across 7 parameters. The description implies 'margins' via 'explicit per-side margins' and touches the scope choice, but leaves unit, path, ids, workspaceId, and expectedRevision entirely unexplained. It only marginally compensates for the coverage gap.

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

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

The description states a specific verb (fits) and resource (page) and clarifies the two bound modes ('native visual drawing or selected-object bounds'), which map to the scope enum. This differentiates it from the page-manipulation siblings (document_resize, document_page_adjust), though it never names them.

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 guidance on when to choose this over document_resize or document_page_adjust, nor on prerequisites such as the required expectedRevision or whether a selection must exist. The 'never transforms objects' note is a behavioral trait, not a usage directive.

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 destructiveHint=false, so the description carries most of the burden, and it usefully discloses that SVGZ expansion is hard-limited, no external resource is fetched, and output is sanitized. It stops short of explaining concurrency/expectedRevision behavior or what happens if outputPath/manifestPath already 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?

Two tightly written sentences with no waste, front-loading the core action and then the safety constraints. Every clause adds 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?

An output schema exists so return values need not be described, and the safety constraints are covered, but with 6 required parameters and zero schema coverage the definition leaves substantial mechanical detail (sanitizeMode default, revision checking, overwrite semantics) for the agent to infer.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate but largely does not. Only 'workspace-local', 'SVG or SVGZ' loosely map to path/workspaceId/format; sanitizeMode, expectedRevision, outputPath, and manifestPath semantics are left entirely to the schema.

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

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

It names a specific verb and resource with scope ('Imports one workspace-local SVG or SVGZ') and states the output artifacts (sanitized SVG plus conversion manifest). This distinguishes it from raster/PDF/PostScript import siblings, though it does not explicitly differentiate itself from the closely related document_import_svg 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?

There is no when-to-use guidance, no prerequisites, and no named alternative despite several competing import tools in the sibling list. The agent is left to infer that this applies to local SVG/SVGZ sources only.

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

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

Annotations only declare readOnlyHint=true, and the description adds genuinely non-obvious behavioral context: the probe is local, and detected types are withheld unless their headless conversion fixture passes, which tells the agent the output may be deliberately incomplete. It does not cover performance or caching behavior, but the fixture-gating disclosure is substantive.

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 free of filler; the key claim (reports observed input types) comes first, with the fixture gate as supporting detail. The phrasing is jargon-dense ('headless fixture gates') but each 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?

An output schema exists, so return values need no explanation, and the tool is parameterless and read-only. The description adequately covers what is reported and the caveat on withheld types; only the routing question of when to invoke it is left open, which is scored under usage guidelines.

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 is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the probe is run without arguments.

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 reports the exact input types observed from a local Inkscape --list-input-types probe. This is distinguishable from the many document_import_* siblings, which perform actual imports, 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?

There is no statement of when to call this versus the import tools (document_import_svg, document_import_raster, etc.) or inkscape_status. An agent must infer usage from the word 'capabilities' alone; 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?

Annotations only supply destructiveHint=false, so the description carries most of the load and does add real context: the conversion runs through the local Inkscape capability, output is sanitized, a conversion manifest is produced, and only a single trusted workspace-local file is processed. It is silent on failure behavior, revision conflicts, and permission requirements, which keeps it below a 5.

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

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

Two sentences, zero filler, with the core action front-loaded and the scope guardrail second. Nothing is repeated from the name or schema and no clause is wasted.

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 no explanation, but for a 7-parameter mutation-ish tool with 0% schema descriptions and no annotations beyond destructiveHint, the description leaves too much unsaid: expectedRevision semantics, dependencyPolicy behavior, sanitizeMode tradeoffs, and error/conflict handling are all absent.

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

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

Schema description coverage is 0% across 7 parameters, including a nested dependencyPolicy object and a regex-constrained expectedRevision. The description only obliquely gestures at workspaceId ('workspace-local'), path ('EMF file'), and sanitizeMode ('sanitized'), and never explains expectedRevision (concurrency guard), manifestPath, outputPath, or dependencyPolicy. It does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Imports one trusted workspace-local EMF file') plus the concrete outputs (sanitized SVG and conversion manifest), which is enough to tell it apart from document_import_svg or document_import_raster. It does not, however, name any sibling importer explicitly, so the differentiation is carried by the tool name rather than the prose.

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: one file, workspace-local, trusted, EMF only. The closing clause 'never accepts arbitrary native formats or arguments' functions as a soft when-not, steering agents toward other import tools for other formats, but no alternative is named and no prerequisites (Inkscape availability) 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?

Annotations only declare destructiveHint=false, and the description adds substantial behavior beyond that: it discloses the produced artifacts (sanitized SVG plus a conversion manifest), that exactly one page is processed, and that non-default importers are capability-gated modes carrying fidelity warnings. It does not cover failure handling or the revision-safety behavior, but this is meaningful added context given the thin annotation set.

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 dense, front-loaded sentences that lead with the core action and outcome, then add the mode caveat. No filler, though the second sentence is jargon-heavy and could read as an afterthought rather than actionable guidance.

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 no explanation, and the description establishes the general workflow (import one page to sanitized SVG + manifest). However, for a 10-parameter tool with nested objects it omits why expectedRevision is required, what the dependencyPolicy does, and how mode capability-gating affects the call, so an agent still lacks enough to invoke it confidently.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only indirectly gestures at mode, page, sanitize/output, and manifestPath. It never explains fontStrategy (six enum values), the nested dependencyPolicy, or the required expectedRevision hash, leaving required parameters undocumented in both schema and prose.

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 (Imports) and resource (exactly one page of a workspace-local PDF) with a clear output (sanitized SVG and conversion manifest), which separates it from the SVG/raster/PostScript/EMF import siblings. It stops short of distinguishing itself from the generic document_import, but the PDF specificity and one-page scope are precise.

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 names the three importers (Inkscape/internal/Poppler) but never says when to pick this tool over document_import, document_import_svg, or the other import siblings, nor when to choose internal vs Poppler. 'Capability-gated' hints that document_import_capabilities should be consulted first, but no alternative or condition is stated explicitly.

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 destructiveHint=false in the annotations, the description carries the burden and adds useful guardrail context: the source must be workspace-local and trusted, output is sanitized, and no arbitrary arguments are accepted. It does not, however, disclose what sanitizeMode or dependencyPolicy actually change, whether existing outputPath/manifestPath contents are overwritten, or how expectedRevision concurrency failures behave.

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 the operation and scope front-loaded; the second sentence's format/argument restriction is a meaningful guardrail rather than filler. Slightly dense phrasing ('observed local Inkscape capability') costs a little, but there is no 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?

Although an output schema exists so return values need not be described, an 8-parameter, 6-required import tool with a nested policy object and a revision token is under-documented when the description explains none of the optional knobs or failure modes. It is enough to identify the tool but not enough to invoke it confidently.

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

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

Schema description coverage is 0% across 8 parameters, including a nested dependencyPolicy object, two enums, and a concurrency token, so the description must compensate and largely does not. It gestures at path/format/workspaceId ('one trusted workspace-local EPS or PostScript file') but says nothing about sanitizeMode, dependencyPolicy, outputPath, manifestPath, or expectedRevision 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?

The description gives a specific verb (imports) and resource (one trusted workspace-local EPS or PostScript file) and states the resulting artifacts (sanitized SVG plus conversion manifest). The explicit format restriction distinguishes it from the many sibling importers (document_import_svg, document_import_pdf, document_import_emf, document_import_raster) without needing to name them.

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

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

Usage is implied rather than stated: the agent can infer this is the importer for EPS/PS sources only, and the 'never accepts arbitrary native formats or arguments' line functions as a partial when-not clause. There is no explicit guidance on when to pick this over document_import or document_import_capabilities, and no prerequisites (e.g., that Inkscape must be available) are called out.

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 destructiveHint=false in annotations, the description carries most of the burden and does it well: byte-sniffing, megapixel bounding, embed-vs-link behavior, and the conversion manifest are all disclosed. It omits what expectedRevision (optimistic concurrency) implies for behavior on a stale revision, which is a notable gap for a write tool.

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 packed sentences with the format scope, output artifact, and safety constraint front-loaded; every clause adds information and nothing is 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?

An output schema exists, so return values need not be described. However, for a 5-required-parameter mutation tool with 0% schema coverage, the missing explanation of expectedRevision, outputPath, and manifestPath leaves the agent guessing at required semantics.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It explains the embedding enum values ('embed the approved bytes or retain one workspace-local relative link') but leaves path, outputPath, manifestPath, workspaceId, and especially the required expectedRevision undocumented in any human-readable form.

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?

Specific verb ('Imports') plus a precisely enumerated resource set (BMP/TIFF/TGA/PNG/JPEG/GIF/WebP) and a clearly stated outcome (a new SVG document with raster wrapper and conversion manifest). It is immediately distinguishable from the sibling importers (document_import_svg, document_import_postscript, document_import_emf, document_import_pdf) by format.

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?

Format restrictions and the 'never fetches a URL' exclusion give a clear context for use and implicitly route the agent among the import siblings. It does not, however, explicitly say when to prefer this over document_import or document_import_capabilities, so it stops short of full when/alternatives guidance.

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

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

Annotations only provide destructiveHint=false, so the description carries most of the behavioral burden and it does disclose the substantive effect: scripts, event handlers, and forbidden external references are removed, and the result is a NEW document (non-destructive). It still does not elaborate on what the 'selected policy' does or any permission requirements, but the sanitization behavior is concrete and useful.

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, front-loaded with the core action and immediately followed by the sanitization behavior. 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?

An output schema exists, so return values need no explanation, and the behavioral clause is present. However, for a 5-parameter mutating import (4 required, including a revision/concurrency token and a policy enum) with 0% schema coverage, the description leaves key parameter semantics undocumented.

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

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

Schema description coverage is 0% and the description names no parameters. It gestures at 'selected policy' (sanitizeMode), 'workspace-local' (path/workspaceId), and 'new document', but leaves expectedRevision, outputPath, and the sanitizeMode enum values unexplained, so it fails to compensate for the coverage gap.

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

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

States a specific verb ('Imports') with a precise resource ('one workspace-local SVG') and a defined output ('a new sanitized SVG document'). The SVG/format specificity inherently distinguishes it from siblings like document_import_raster, document_import_pdf, document_import_emf, and document_import_postscript.

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 never states when to choose this tool over the generic document_import or the other format-specific importers, nor any exclusions or prerequisites. The only hint is the 'workspace-local' qualifier, which is a scope detail rather than usage guidance.

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

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

Annotations only declare readOnlyHint=true, and the description adds real context beyond that: the document must be authorized, the inventory is bounded and redacted, and the operation is non-mutating. Redaction and bounding are behaviorally meaningful and not derivable from the annotations. It does not, however, say what authorization means or what the bounds are.

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 well-formed sentence with the verb and scope front-loaded and no filler. It is dense but not padded; the only nit is that it compresses several ideas into one clause chain rather than separating them.

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 are covered, but an 8-parameter tool with a constrained enum, regex-validated ids, and an optimistic-concurrency field (expectedRevision) is under-described. The description communicates the spirit of the operation without the detail needed to invoke it correctly on the first attempt.

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

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

Schema description coverage is 0% across 8 parameters, so the description carries the full burden and mostly fails it. "Bounded" loosely gestures at inventoryLimit/inventoryOffset and "redacted" at inventoryKinds, but the level enum (summary/standard/deep), expectedRevision, and includeVisualBounds are never explained, and none of the required path/workspaceId constraints are surfaced.

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 ("Reads") and a concrete resource pair ("SVG settings and a bounded, redacted design inventory"), plus a scope qualifier ("authorized document without mutating it"). An agent can tell this is an inspection tool rather than a mutation tool, though it never names a sibling to contrast with.

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

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

There is no explicit when-to-use statement and no mention of alternatives such as document_snapshot, document_settings, or accessibility_inspect, which are plausible near-neighbors in the sibling list. The read-only framing implies inspection but leaves routing entirely 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 declare only destructiveHint=true; the description usefully adds the exact mutation surface (which reference types get rewritten) and the no-op guarantee that already-valid unique IDs are untouched. That is real added context on top of the annotation, though it omits revision-conflict behavior despite the required expectedRevision parameter.

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, mutation scope front-loaded, preservation guarantee second. No filler, no restatement of the name, nothing that could be cut.

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 destructive, revision-guarded mutation with five undocumented parameters, the description covers what happens to IDs but not the conditions for calling it safely. With 0% schema coverage it should explain at least the prefix and assignMissingIds semantics; the output schema does relieve it of describing return values.

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

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

Schema description coverage is 0% across five parameters, so the schema gives no meaning for path, workspaceId, prefix, assignMissingIds, or expectedRevision. The description loosely implies missing IDs may be assigned ('invalid or duplicate IDs') but never explains prefix defaults, the assignMissingIds toggle, or the revision-matching requirement, so it fails to compensate for the coverage gap.

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

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

The description gives a concrete verb+resource ('normalizes invalid or duplicate SVG IDs') plus the scope of side effects ('rewrites supported local href, URL, ARIA and CSS references'). It is clearly distinguishable in content from vague siblings like defs_vacuum or document_optimize, but it never names or contrasts with an alternative tool, so it stops short of the 5 tier.

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?

Beyond the adverb 'Explicitly' hinting that normalization is a deliberate opt-in step, there is no when-to-use, when-not-to-use, or alternative guidance. An agent cannot tell from the text whether to call this before export, as part of an import cleanup, or instead of defs_vacuum/document_optimize.

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 destructiveHint=false, so the description adds real value by stating 'the source document is never modified' and disclosing the out-of-band dependency on an Inkscape visual-regression render before publication. It still doesn't say what happens if the render mismatches or what gets written to the derived output.

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 dense sentences with the core action front-loaded and zero filler. The second sentence is slightly jargon-heavy but earns its place by conveying the render gate and non-destructive guarantee.

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 no explanation, but for a 7-parameter tool with 0% schema coverage and revision-tracking parameters, the description leaves too much undocumented. It also omits any differentiation from the overlapping 'defs_vacuum' sibling, leaving the agent unable to confidently select this 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 0% across 7 parameters, so the description carries the full burden. It only gestures at dryRun ('Plans or writes') and outputPath ('derived SVG'); visualTolerance, expectedRevision, and expectedOutputRevision are entirely unexplained despite having constrained ranges and patterns.

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 action pair ('Plans or writes a derived SVG') and a precise scope constraint ('removes only unused top-level definitions'), which an agent can act on. It fails to differentiate from the sibling 'defs_vacuum', which appears to operate on the same domain, 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?

The mention that 'Publication requires a deterministic Inkscape visual-regression render' implies a two-phase plan/commit workflow, which is useful context. However, there is no explicit statement of when to use this versus 'defs_vacuum' or when dryRun should be toggled, leaving routing 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?

destructiveHint=true already warns that this mutates irreversibly, but the description does not say what is destroyed (content outside cropped margins) or why expectedRevision is required for concurrency safety. It does add one useful trait beyond the annotations: object geometry is preserved rather than rescaled, which helps distinguish it from resize.

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 with zero filler and the operations front-loaded before the invariant. Efficient, though the compression is partly what leaves the behavioral and parameter gaps unaddressed.

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 destructive 7-parameter mutation tool with 0% schema description coverage, the description is far too thin. Even granting that the output schema covers return values, an agent gets no help on unit/anchor interaction, crop vs expand semantics, or the revision-check workflow.

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

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

Schema description coverage is 0% across 7 parameters. The description only gestures at margins being 'explicit physical margins', mapping loosely to the margins and unit fields, and says nothing about the action enum values, anchor alignment, path, workspaceId, or expectedRevision 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?

Names three specific operations (crop, expand, toggle orientation) on a specific resource (page) with a stated invariant (preserving object geometry). It is clearly distinguishable from a generic resize, but it never names the closest siblings (document_resize, document_fit_page) to draw the boundary.

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 guidance on when to choose this over document_resize, document_fit_page, or images_crop, nor any mention of prerequisites such as needing the current revision or being scoped to a workspace. The agent must infer selection from the 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?

Annotations supply only destructiveHint=true, so the description must carry more weight than it does. It does add genuine context beyond the annotation — optimistic-concurrency via "current document revision" and stable-ID addressing — but never says which of the five actions actually destroys data (delete), nor what "safely" guarantees.

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 operation scope front-loaded and the mutation precondition second. The only soft spot is the vague adverb "safely," which costs a word without adding testable meaning.

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 needn't be described, but for a tool with five actions, nested page/patch objects, and three required parameters, two sentences is far too thin. Which parameter applies to which action, and the irreversibility of delete, are not covered anywhere structured.

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

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

Schema description coverage is 0% across 8 parameters, including two nested objects, so the description must compensate and mostly doesn't. It only hints at pageId/pageIds ("stable page ID") and expectedRevision ("current document revision"), leaving page, patch, action values, and workspaceId unexplained for a 5-action 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 specific verb pair ("Lists or safely changes") and a concrete resource ("explicit Inkscape 1.4 pages"), plus a key qualifier: addressing is by stable page ID. That distinguishes it from ID-churn operations like document_normalize_ids, though it does not separate itself from the adjacent document_page_adjust / document_page_validate 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?

Provides one real prerequisite (mutations require the current document revision), which tells the agent to fetch a revision first. It gives no when-to-use-vs-alternatives guidance, so the agent cannot tell from the description why to pick this over document_page_adjust or document_page_validate.

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 inspection. The description adds genuinely useful method context ('using native visual bounds'), clarifying the basis of the geometric checks. It stops short of describing what a failed validation yields or whether it mutates anything, but with annotations carrying the safety profile a 3 is fair.

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 that front-loads the verb and enumerates the checks in order of importance. No filler, though the phrase is packed enough that it verges on hard to parse.

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 no explanation, and readOnlyHint covers safety. The gap is the unconveyed expectedRevision contract and any behavior on revision mismatch, which matter for correct invocation of a 3-required-parameter 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 0% across three required parameters, so the schema contributes no semantics. The description explains none of them, and notably ignores expectedRevision, whose 64-hex pattern strongly implies an optimistic-concurrency/revision-match contract that the agent cannot learn from anywhere else.

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 ('Validates') plus three concrete checks: page overlap, empty pages, and objects outside every page. An agent knows exactly what condition set is tested. It does not, however, distinguish itself from the closely related sibling document_preflight, which likely performs a similar validation pass.

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 guidance on when to run this versus document_preflight, document_inspect, or document_pages, and no mention of prerequisites such as needing a workspace-bound path. Usage must be inferred entirely from the name and description.

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, and the description usefully corroborates and extends this: it repeats 'read-only' and adds the meaningful constraint that linked resources are not opened, so the caller knows external assets won't be fetched or mutated. It stops short of describing cost, error reporting, or pagination-like behaviors.

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 read-only and no-linked-resource qualifiers are packed into the same clause rather than padding the description.

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 four parameters, a nested bleed object, and 0% schema coverage, the description is too thin: it never explains what bleed/behavior mean or how path and workspaceId are expected to be supplied. The existence of an output schema excuses it from describing return values, but the input side remains under-specified for a non-trivial 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 0%, so the description carries the full burden, yet it only restates the profile enum values already visible in the schema. The nested bleed object (behavior enum, per-side unit/value pairs) and the workspaceId pattern requirement get no explanation at all.

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 (runs) and resource (preflight) and enumerates the supported profiles (basic, web, print, interchange), which is more than a tautology. It does not explicitly distinguish itself from the sibling fonts_preflight, leaving that distinction to be inferred from the name.

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 run a preflight versus alternatives like document_inspect, document_page_validate, or fonts_preflight, nor any prerequisites such as when a profile should be chosen. The profile list hints at a selection decision but offers no guidance on making it.

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 supply only destructiveHint=false, so the description carries most of the burden and delivers real value: non-destructive ('without changing the source document'), transparency, inline return for small results, and a defined save destination ('authorized workspace path'). It stops short of permissions, rate limits, or failure 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 tight sentences, front-loaded with the core action and followed by the output behavior. 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?

An output schema exists, so return values need not be described, but for a 10-parameter tool with 0% schema coverage and minimal annotations the description leaves major gaps — notably optimistic-concurrency revisions and selection/area targeting. It is not complete enough for an agent to invoke confidently without reading 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 0% across 10 parameters, so the description must compensate and largely does not. Only 'bounded' vaguely gestures at the width/height limits and 'workspace path' at outputPath/workspaceId; the concurrency semantics of expectedRevision/expectedOutputRevision and the meaning of area/pageId/selectionId are unexplained.

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

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

States a specific verb and resource ('Renders a ... PNG preview') with useful scope qualifiers ('bounded', 'transparent', 'without changing the source document'). It does not explicitly distinguish itself from siblings like export_png or document_export, so an agent must infer the preview-vs-export 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 named alternatives, and no conditions for choosing this over export_png or other render/export siblings. Usage is only implied by the word '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?

With only destructiveHint=true provided, the description usefully adds that element geometry is preserved, that the return is a bounded semantic diff, and that the current revision is required. That said, it doesn't explain what is actually destroyed or how the destructive mode variants behave, so it stops short of full disclosure.

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 dense sentences with the core operation, its semantics, and its prerequisite front-loaded. 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?

The output schema covers the semantic diff, so return values needn't be re-explained, but with 9 parameters at 0% coverage and no sibling differentiation, the description is thin for a complex mutation tool. Key parameters (unit, anchor, dryRun) remain unexplained.

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

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

Schema description coverage is 0% across 9 parameters, so the description must carry the load, but it only clarifies mode ('page_only') and alludes to revision. It says nothing about unit, anchor, dryRun, path, or workspaceId, leaving most parameters undocumented.

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 (changes the SVG page size) with a scoping qualifier (page_only semantics) and the preservation guarantee. However, it does not distinguish itself from plausible siblings like document_page_adjust or document_fit_page, leaving the agent to open schemas to disambiguate.

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, and no alternative tool is named despite several page-related siblings. The only conditional information is the prerequisite (requires current revision), which is implied rather than framed as selection criteria.

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 supply only destructiveHint=true, so the description carries most of the burden. It usefully discloses the exact-revision precondition and implies an ownership/authorization boundary via 'owner-bound', but it never says what happens to existing content, whether the restore is reversible, or how a revision conflict surfaces.

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 sentence, zero filler, and the gating precondition is front-loaded. It is efficient, though arguably too terse given the undocumented parameters it should be compensating for.

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 explained. However, for a destructive, 4-parameter operation with no annotation depth and 0% schema coverage, the description leaves the parameter contract and failure behavior unaddressed.

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

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

Schema description coverage is 0% — none of the four required parameters (path, snapshotId, workspaceId, expectedRevision) are documented in the schema. The description only indirectly gestures at expectedRevision via 'current document revision' and at workspaceId via 'owner-bound'; it adds no meaning for path or snapshotId and no format guidance despite strict patterns.

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 ('Restores') and resource ('owner-bound snapshot'), which separates it from sibling document_snapshot and document_import tools. The scope is clear, though 'owner-bound' is unexplained jargon that an agent may not decode.

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 one real precondition: the current document revision must match exactly. That is usable guidance, but there is no explicit when-not clause, no naming of alternatives (e.g. re-snapshotting instead of restoring), and no statement of what to do on mismatch.

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 only annotation is destructiveHint=true, and the description does add real behavioral context beyond it: updates require the current document revision, implying optimistic concurrency. It does not disclose permission needs, what read mode returns, or what happens to settings fields not supplied.

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, and the read/write nature is front-loaded before the write prerequisite. 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?

An output schema exists so return values need not be explained. Yet for a tool that both reads and mutates with destructiveHint=true, 0% schema coverage, and a nested settings object, the description omits auth requirements and merge/replace semantics for supplied settings.

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

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

Schema description coverage is 0% across four parameters, so the description carries the burden. It partially compensates by naming the settings domains (page, desk, border) and explaining expectedRevision as 'the current document revision', but says nothing about path or workspaceId 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 concrete verb pair and resource: reads/updates Inkscape page, desk and border display settings. This distinguishes it from neighbors like guides_grids_manage and document_page_adjust, though the read/write dual nature and 'typed' remain slightly vague.

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 prerequisite for writes is given ('Updates require the current document revision'), which is useful. However, there is no guidance on when to choose this over sibling tools such as document_page_adjust or guides_grids_manage, and no when-not conditions.

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 destructiveHint=false; the description adds meaningful context about revision verification, owner-binding, and opacity. However it omits whether the snapshot fails on revision mismatch, TTL expiry behavior, or storage/auth implications of ownership.

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 well-formed sentence with the verification precondition front-loaded. No waste, though it packs two concepts (creation and verification) that could be clarified.

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?

Output schema exists, so return values need no explanation. The description covers the essential precondition and mutation semantics for a 4-param mutation tool; only failure modes on revision mismatch remain unstated.

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

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

Schema description coverage is 0% across 4 parameters, but the schema itself enforces constraints (pattern, min/max, default) that document syntax well. The description names only 'revision' semantics; ttlMs, workspaceId, and path carry no added meaning beyond the schema. Baseline 3 per high structured enforcement.

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: 'Creates... snapshot of a document.' The 'opaque, owner-bound' qualifiers distinguish it from export/render siblings, though it doesn't name an alternative tool. A clear, self-contained purpose.

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?

Implies use via 'after verifying its exact revision', suggesting optimistic-concurrency use, but gives no explicit when-to-use vs alternatives (e.g., vs document_render_preview or export tools) and no when-not-to-use guidance.

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

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

The annotation set only carries destructiveHint=true, so the description adds real value by disclosing that alignment is computed against Inkscape visual bounds and that selected ancestors and descendants are rejected. It is consistent with the destructive hint (alignment mutates positions) but does not elaborate on what state is altered.

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 leads with the action and target, with no filler. The ancestor/descendant rejection clause is somewhat compressed into the same sentence but remains readable.

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

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

An output schema exists so return values need not be explained, and the base purpose is covered. However, for a 6-parameter mutation tool with 0% schema description coverage, nothing explains ids/path selection semantics or the concurrency role of expectedRevision, leaving material gaps.

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

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

Schema description coverage is 0% across 6 parameters. The mention of selection/page/coordinate/element merely restates the anchor oneOf const values already encoded in the schema and says nothing about the alignment enum, ids, path, expectedRevision, or workspaceId. With near-zero schema coverage, the description does not compensate.

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 (Aligns) and resource (SVG elements) and enumerates the four anchor targets (selection, page, coordinate, another element), so the operation is concrete. It does not explicitly contrast itself with near-siblings like elements_arrange or elements_distribute, so it falls 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?

Usage is implied by the enumeration of anchor targets, and the rejection of ancestors/descendants hints at a precondition, but there is no explicit when-to-use guidance, no statement of prerequisites (e.g., expectedRevision/workspaceId requirements), and no routing to alternatives such as elements_arrange.

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 only annotation is destructiveHint=true; the description adds no behavioral context beyond restating that elements move. It never mentions that ordering changes are persisted mutations requiring expectedRevision for optimistic-concurrency conflict detection, whether the operation is atomic across multiple ids, or what happens when ids are not siblings. For a destructive mutation tool these are real gaps.

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 verb first and the operation enumeration in the same breath. No filler, no restatement of the tool name, and 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?

An output schema exists so return values need not be explained, and the action semantics are covered. However, for a destructive, revision-guarded mutation with a 3-branch oneOf contract, the description omits the mutation/conflict model and error conditions, leaving the agent to infer the write semantics from the schema alone.

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 baseline is 3, but the description adds meaning beyond the raw enum values: it clarifies that lower/raise are "one step", that index is "deterministic" sibling placement, and that before/after acts relative to a sibling. This maps the three oneOf branches to intent, though it says nothing about ids, path, or expectedRevision format constraints.

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 ("Moves") plus a precise resource and constraint ("same-parent SVG elements"), then enumerates the full operation space: front, back, one step, deterministic sibling index, before/after. This z-order semantics is clearly distinguishable from spatial siblings like elements_align or elements_distribute 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?

The action vocabulary implies when each mode applies, but there is no explicit guidance on when to choose elements_arrange over elements_align, elements_distribute, or elements_transform, and no stated preconditions (e.g. that elements must share a parent). Usage is inferable but 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 only destructiveHint=true annotated, the description adds some context ('bounded batch' implies an item cap, and the no-XML/arbitrary-attributes constraint is a real behavioral limit). However, it does not explain the destructive nature flagged by the annotation, nor the concurrency role of expectedRevision. It neither contradicts the annotation nor fully discharges the burden the annotation leaves.

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 verb first and no filler. It is efficient, though the brevity comes at the cost of the missing details noted elsewhere.

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

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

For a tool with 100+ nested shape variants, four required params, and only a destructiveHint annotation, one sentence is thin. The output schema covers return values, but the description omits expectedRevision semantics, the destructive/optimistic-locking behavior, and where elements are placed, so an agent lacks enough context to invoke it confidently.

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

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

Schema description coverage is 0% with four required parameters (elements, expectedRevision, path, workspaceId), so the description must compensate and largely fails to. It alludes to the 'batch' of shapes but says nothing about expectedRevision conflict handling, path scoping, or workspaceId, leaving critical call semantics undocumented.

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 ('Creates a bounded batch of typed SVG basic shapes') and adds a meaningful scope qualifier ('without accepting XML or arbitrary attributes') that implicitly contrasts with import-based siblings like document_import_svg. It stops short of naming an alternative explicitly, so it is clear but not sibling-differentiating at the highest level.

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 and no reference to alternatives such as elements_update, elements_duplicate, or document_apply_operations. Usage is only weakly implied by the verb 'Creates', leaving the agent to infer when this tool is the correct choice over the many other element-mutation siblings.

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

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

Annotations only state destructiveHint=true; the description adds a genuinely non-obvious behavioral rule — deletions that would break fragment references are rejected, so the agent can expect partial/blocked failure modes. It still omits cascade behavior for child elements and how expectedRevision conflicts are handled.

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 sentence, front-loaded with the action and resource, with no filler. It is tight, though the brevity contributes to the parameter and usage gaps rather than compensating for them.

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 destructive hint is covered. However, for a four-parameter mutation with a required concurrency token and no schema descriptions, an agent still lacks enough to call it correctly without inspecting 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 0% across four required parameters. The description only implies that 'ids' are explicit element identifiers; it says nothing about expectedRevision (optimistic-concurrency token), path, or workspaceId, leaving most parameters undocumented in both places.

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?

Specific verb + resource: 'Deletes ... SVG elements.' The qualifier 'explicitly selected' usefully narrows scope (ID-based, not query-based deletion), which separates it from siblings like elements_query or elements_update without naming them.

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 guidance and no alternatives named. An agent gets no help deciding between this, elements_update, document_apply_operations, or defs_vacuum, nor any prerequisite about resolving element IDs before deletion.

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, so the mutation profile is already flagged. The description still adds real behavioral value by disclosing that spacing is computed from 'native Inkscape bounds' and that the first and last element are pinned on the chosen axis — a non-obvious outcome. It omits the concurrency/revision guard and the minimum-three-element requirement.

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 tight sentence that front-loads the verb and packs mode meanings plus the endpoint-preservation behavior without filler. Slightly dense, but nothing is wasted.

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 no explanation, and annotations cover the destructive profile. However, for a six-param mutation tool with zero schema descriptions, leaving the revision/workspace contract and the 3-element minimum undocumented is a meaningful gap.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only illuminates two of six parameters: axis ('chosen axis') and mode (edges/centres/gaps). The ids, path, workspaceId, and expectedRevision parameters — including the 3–100 count constraint and the 64-hex revision token — get no explanation anywhere.

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 ('distributes SVG elements') and enumerates the three operative modes (visual edges, centres, gaps), which separates it from a generic transform. It does not name or contrast with the closest sibling, elements_align, so the agent must infer the align-vs-distribute boundary.

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 explains what distribution does but never says when to reach for it instead of elements_align or elements_arrange, nor what prerequisites apply. No explicit when/when-not guidance is 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?

With only destructiveHint=true available, the description adds meaningful behavior: deterministic local-ID remapping, the precise scope of reference rewriting ('Only internal fragment references in a copied subtree'), and a precondition on malformed IDs. It does not explain why the operation is flagged destructive or what document state changes occur, which keeps it from 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?

Two dense sentences with no filler, and the core action is front-loaded before the constraint. The second sentence packs edge-case detail ('only internal fragment references... rewritten') that is somewhat compressed but still 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?

An output schema exists, so return values need not be described, and the description supplies solid behavioral context for a mutation tool. The notable gap is parameter semantics for a 7-param required-heavy schema, plus no explanation of the destructive annotation, leaving the definition only partially complete.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate but only gesture at 'mode' via copy/use and 'id' via the malformed-ID precondition. newId, parentId, path, workspaceId, and expectedRevision are left entirely undocumented, so most parameters lack semantic guidance.

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 ('Duplicates') plus resource ('bounded SVG subtree') and names the alternative behavior ('or creates an explicit SVG use clone'), making the two modes distinguishable. It does not explicitly name a sibling like elements_create to differentiate, 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?

It implies mode selection (copy vs use clone) and states a prerequisite ('malformed source IDs must be normalized first'), which routes the agent to document_normalize_ids. However, there is no explicit when-to-use vs when-not-to-use guidance relative to sibling creation/grouping tools.

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 destructiveHint=true; the description adds real value by explaining what mutation occurs (transforms are replaced by baked geometry) and that unsupported inputs are rejected rather than silently altering SVG semantics. It does not disclose the revision-guard/concurrency behavior implied by expectedRevision.

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, front-loaded with the core action and followed by the constraint. 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?

Output schema exists so return values need no explanation, and the operation semantics are well covered. But for a destructive batch tool with four undocumented required parameters and a maxItems=100 constraint, the description leaves important operational context unaddressed.

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

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

Schema description coverage is 0% across 4 required parameters, so the description must carry the burden and it does not. It says nothing about ids, path, workspaceId, or the optimistic-concurrency expectedRevision token, leaving an agent with no meaning beyond raw patterns.

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 (bakes) and resource (axis-aligned translate/scale/matrix transforms) and states the outcome (safe primitive geometry). An agent can distinguish it from elements_transform and paths_flatten by the 'own axis-aligned' scope, 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?

The rejection list (rotation, skew, paths, inherited transforms) functions as implicit when-not-to-use guidance, which is genuinely useful. However, it never says when to prefer this over siblings like elements_transform or paths_flatten, so the routing decision is left 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 only declare destructiveHint=true; the description adds genuinely useful behavior beyond that: child order is preserved, broken href references are rejected, and ungrouping is limited to a single non-layer group. It does not discuss atomicity or expectedRevision conflict behavior, keeping it out of 5 territory.

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 that front-loads the action and follows with the governing constraints. Every clause carries information, though the run-on construction packs three constraints together and slightly taxes readability.

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 (destructiveHint) and an output schema present, the description need not explain return values, and it covers the mutation's constraints and failure mode (broken hrefs). It omits anything about revision/optimistic-concurrency failure, which the expectedRevision parameter implies but does not explain.

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 the baseline is 3, but the description contributes real constraints the schema cannot express: the grouped elements must share a parent, and ungroup operates on exactly one non-layer group. These operational rules materially guide correct invocation.

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 ('Groups ... SVG elements') and covers the inverse operation ('or ungroups'), so the dual group/ungroup nature mapped to the `action` enum is clear. It does not explicitly name a sibling it must be distinguished from (e.g. elements_reparent), 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?

Usage is implied through the two actions: grouping applies to 'same-parent' elements, ungrouping to 'one non-layer group'. There is no explicit statement of when to prefer this tool over siblings like elements_reparent, elements_arrange or elements_duplicate, nor any stated prerequisites.

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