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

With no annotations, the description carries the load and mostly succeeds: it discloses the return shape (Inkscape's printed output, logged complaints, geometry-changed flag), that a rejected action becomes an error, and that malformed arguments may be silently ignored. It does not flag that this is an unrestricted mutation path that can alter or delete document content, which is a residual safety gap.

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

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

Front-loaded and dense with no filler; the inline example conveys the run syntax compactly. The telegraphic style ('returning what Inkscape printed, any complaint it logged') is efficient but occasionally terse enough to require re-reading.

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 open-ended tool with an output schema, this covers invocation, prerequisites, error semantics, and return shape adequately. The main missing piece is guidance on the expected_revision parameter and on the tool's destructive potential.

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 must compensate; it does for two of three parameters, explaining the run value's nested string-vs-[name, args] form with a concrete example and defining search as a substring over names and descriptions. The expected_revision parameter is never mentioned, leaving one parameter fully 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 and resource ('Run any of Inkscape's ~1,070 actions, or search them') and explicitly splits the tool into two modes, run and search, so an agent knows the tool's scope immediately. It also names a sibling, export, as the tool for file writing.

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

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

Gives real prerequisites ('Most act on the current selection; use selection(set_ids=…) first') and a clear alternative ('To write files, prefer export'). It does not, however, explain when to prefer this generic tool over the many overlapping siblings (align, distribute, style, attributes), which is a meaningful omission for an escape-hatch 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?

With no annotations, the description carries the full burden. It does disclose two genuinely useful behaviors beyond the schema: how coordinates are interpreted with/without x_mm/y_mm, and that colliding ids are silently renamed. It omits whether the operation is additive, what 'show' does, and nothing about undo/reversibility or required document state.

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

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

Three tight sentences, front-loaded with the purpose, then the placement rules with a concrete numeric example, then the id-collision caveat. The example earns its place by making the coordinate contract unambiguous; there is no filler.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the drawing and coordinate model well but leaves show, index, expected_revision, and the parent target's semantics unexplained. An agent could invoke it for the basic case but would be guessing on ordering and concurrency.

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 8 parameters, so the description must compensate. It does explain x_mm, y_mm, units and markup (via a concrete worked example), but index, show, and expected_revision receive no explanation at all, leaving the concurrency and ordering 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?

States a specific verb and resource: drawing arbitrary content by writing SVG markup, with an enumeration of what can be drawn (shapes, lines, arrows, text, groups, gradients). This is far clearer than the vague sibling names (insert, text, structure), though it never explicitly says how it differs from those alternatives.

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

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

Usage is implied rather than stated: an agent can infer it should reach for this when it needs arbitrary vector drawing, and the coordinate paragraph hints at the two placement modes. There is no explicit when-to-use/when-not guidance and no named alternative among the many siblings (insert, text, structure).

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

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: the `to` target 'stays put', `as_group` 'moves the ids as one block', and `expected_revision` will 'refuse if the document changed since'. It stops short of stating reversibility, permissions, or failure behavior beyond the revision guard, so it is strong but not complete.

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

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

The core action is front-loaded in three words, followed by a terse per-parameter walk-through with no filler sentences. The dense clause-per-parameter style is efficient, though it reads as a reference blob rather than clearly separated 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?

For a 7-parameter mutation tool with no annotations and no output schema, the description covers most of what an agent needs to invoke it correctly, including target semantics and a concurrency guard. It still omits the required `ids` parameter's meaning and the purpose of `show`, and never hints at the return shape.

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 schema declares no enums, so the description does real work: it supplies the full `edges` value set (left/hcenter/right/top/vcenter/bottom and 'one of each'), the `to` targets, and the meaning of `to_mm`, `as_group`, and `expected_revision`. It leaves `ids` (required) and `show` undocumented, which prevents a 5.

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 opening 'Align objects exactly' gives a specific verb and resource, and the parameter walk-through confirms the tool repositions objects relative to other objects or the page. It never names the sibling `distribute` (the nearest alternative), so an agent must infer the boundary between the two, which keeps it below 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 is implied by the enumeration of alignment targets ('first | last | biggest | smallest | page | drawing | selection') and the `to_mm` page-coordinate mode, which sketch out when each mode applies. There is no explicit when-to-use, when-not, or named alternative versus `distribute`/`move`, so guidance stays at the implied level.

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

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

With no annotations, the description carries the full burden, and it does disclose one non-obvious behavior: passing null removes the attribute. It does not explain overwrite behavior for existing values, what happens on a revision mismatch (relevant given expected_revision), or whether this mutates multiple elements at once.

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 wastes nothing, with the core action leading and the removal semantics immediately after. The trailing ellipsis in the example list is slightly loose but signals that the list is illustrative.

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 mutation tool with no annotations and 0% parameter description coverage, the definition leaves too much unstated: the meaning of ids and expected_revision, overwrite/conflict behavior, and multi-element semantics. An output schema exists, so return values need not be described, but the input side is materially under-documented.

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 must compensate, and it only partially does: the null-equals-remove semantics for 'attrs' values and example attribute keys are genuinely helpful. But 'ids' (which identifiers? element ids? comma-separated?) and 'expected_revision' (presumably an optimistic-concurrency token) are entirely unexplained in both schema and description.

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 ('Set ... XML attributes') with concrete attribute-name examples (inkscape:label, width, rx, xlink:href, id), which makes it distinguishable from siblings like style, text, and structure. It does not explicitly contrast itself with those siblings, 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 parenthetical '(or with null, remove)' tells the agent how to perform a deletion, which is real usage guidance. However, it never says when to use attributes versus style (CSS properties) or structure, nor does it mention any prerequisites, so usage is only 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?

With no annotations, the description carries the full burden and does well: it discloses the side effect that the current revision becomes the new baseline, that the shallow path is exact and cheap, and that deep=True is slow and re-reads the document. It omits auth/permission needs and output format, but the output schema covers returns.

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 behavior and what is reported, then the deep variant and its cost. Minor awkwardness in 'since you last looked or edited (or since since_revision)' but no wasted sentences.

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

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

For a 2-optional-param tool with an output schema, the description covers the baseline semantics, the destructive-ish baseline reset side effect, and the performance tradeoff of deep mode. Nothing an agent needs to call it correctly or interpret it safely is missing.

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

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

Schema description coverage is 0%, so the description must explain both parameters, and it does: deep=True re-reads the document to report text and style edits (noting the poster slowness), and since_revision sets the baseline revision. Both optional params gain meaning beyond the bare types in the schema.

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

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

The description names a specific operation on the document: reporting objects added, removed, moved or resized, and with deep=True text and style edits too. It clearly conveys what is returned and relative to which baseline, so an agent can distinguish it from sibling tools like 'history' or 'status'. It stops short of explicitly naming an alternative sibling, so it is clear rather than maximally differentiating.

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

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

It states the default baseline (since you last looked or edited) and how to override it via since_revision, plus when to reach for deep=True and its cost (slow on posters). That is clear contextual guidance for choosing modes. It gives no explicit when-not-to-use or named alternative 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?

No annotations are supplied, so the description carries the full burden. It explains the distribution math but not that this mutates documents, what expected_revision guards against, whether 'show' is a dry-run/preview flag, or whether the operation is undoable — critical for a 7-param mutation 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 tight sentences, front-loaded with the core action and then branching cleanly on the gap_mm condition. No filler, though the parenthetical enum list makes the second sentence dense.

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

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

For a 7-parameter mutating tool with no annotations and no output schema, the description omits return shape, error/precondition behavior, and the role of expected_revision and show. An agent could invoke it but would be guessing about safety and results.

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

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

Schema coverage is 0%, and the description compensates well for the core params: axis, mode (with its enum values gap|centers|left|right|top|bottom), gap_mm, and start_mm are all given meaning. But ids, show, and expected_revision — including the preview/safety semantics of the latter two — go entirely 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?

Clear verb+resource: 'Space objects along x or y', with the two operating regimes (equal distribution vs. fixed-gap stacking) spelled out. It never names the sibling 'align', so an agent must infer the split from context.

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 modes are clearly delineated by the presence or absence of gap_mm and start_mm, which is genuinely useful routing information. However, there is no guidance on when to pick this tool over the sibling 'align' (neither tool is referenced), nor prerequisites like revision concurrency.

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

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

With no annotations, the description carries full behavioral burden and does disclose useful traits: the document is exported with unsaved changes, the file is read back and reports page size/pixel size/embedded fonts, and text_to_path exists for printers that cannot take fonts. It omits whether an existing file at path is overwritten, permission requirements, 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?

Dense but front-loaded and organized with a clear "What to export:" label; nearly every clause conveys distinct parameter information and little is filler. The semicolon-chained style is slightly hard to scan but appropriate given nine undocumented parameters.

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 nine-parameter tool with no annotations and 0% schema coverage, the description covers nearly all calling details, and the output schema means return values need not be explained (the read-back note is a bonus). Remaining gaps are overwrite behavior and error/permission conditions.

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 carry all parameter meaning, and it does: format source (suffix vs format=), area values, ids/only overlap semantics, region_mm restricted to PNG, dpi for PNG resolution and PDF/EPS/PS filters, text_to_path behavior, and background default (transparent). Only the required path parameter itself is not spelled out, a minor gap against eight well-documented parameters.

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 precise verb and resource ("Export the live document") and enumerates the output formats (PDF, SVG, EPS, PS, PNG). The parenthetical "(unsaved changes included)" implies a scope distinction, but no sibling such as save_copy or render is named, so sibling differentiation is left to inference.

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 description thoroughly explains what can be exported (area, ids, region_mm) but never says when to reach for export versus save_copy or render. Because export is largely self-evident in name and format list, the implied guidance is adequate but not explicit.

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

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

No annotations exist, so the description carries the full burden; it usefully discloses case-insensitivity, mm units, the within-vs-overlaps distinction, and top_level_only nesting behavior. However, it never states that this is a read-only operation, how results are ordered, or whether max_results truncates silently, leaving meaningful behavioral 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?

Front-loaded with 'Find objects by...' followed by a compact enumeration of filters, then a short second sentence for top_level_only. It is dense but every clause earns its place; only the trailing sentence is slightly terse.

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 parameters are nearly all explained despite 0% schema coverage. The remaining gap is the absence of any read-only/permission context for a 9-parameter query tool, but overall it is complete enough to invoke correctly.

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

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

With 0% schema description coverage and 9 parameters, the description compensates by explaining 8 of them with real semantics (text is a case-insensitive substring, tag examples, style syntax example, region format with within/overlaps meaning, top_level_only effect). Only max_results is left unmentioned, but its schema default (60) covers it, so this is strong compensation.

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 ('Find') and resource ('objects') and enumerates the searchable dimensions, so an agent can distinguish it from siblings like selection, inspect, or structure. It does not explicitly name a competing sibling or scope boundary, 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?

The phrase 'by any combination of' implies the filters are combinable, and the within/overlaps and top_level_only notes hint at context, but there is no explicit when-to-use, when-not-to-use, or alternative tool named. Usage is inferred rather than stated.

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

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

With no annotations, the description carries the full burden and delivers the single most important non-obvious trait: this operates on the shared user-visible undo stack, so an undo can clobber concurrent user edits. The expected_revision guidance is genuine safety context beyond the schema. It still omits what happens on a revision mismatch (error vs. silent no-op) and any permission requirements, 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?

Two sentences, no filler, and the core behavior is front-loaded before the safety caveat. 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 described. For a mutation tool with no annotations, the description covers the shared-stack risk and optimistic concurrency. It leaves out mismatch behavior and permission prerequisites, a modest but real 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% across 3 params, so the description must compensate. It does explain expected_revision's purpose and implies n is a step count, but 'op' (undo vs. redo, and its default) is never mentioned and n's default of 1 is undocumented in 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?

Specific verbs (undo/redo) plus the resource and scope ('n steps in the live document'), anchored to a concrete mental model ('the same stack as the user's Cmd+Z'). No sibling tool touches history, and an agent can distinguish this from 'changes' or 'save_copy' immediately.

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

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

Clearly establishes when to reach for it (reverting or reapplying edits in the live document) and gives a concrete condition for passing expected_revision. It stops short of naming when-not or an alternative path, but the sibling list offers no real substitute.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: SVG is inlined as editable vector with namespaced ids, raster images are embedded or linked via embed=False, and the aspect ratio is preserved when scaling. It omits any mutation-safety context (what happens on overwrite, effect of expected_revision, permission needs), so it is only partly transparent for a write operation.

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, front-loaded with the core placement action before the format-specific details. Every clause conveys information, though the second sentence packs three distinct behaviors into one long statement.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, the description is incomplete: it never explains id, label, parent, show, or the revision-guard parameter, nor what the tool returns or whether an existing element is replaced. A caller could place a file correctly but could not safely use the identity or concurrency parameters.

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 11 parameters, so the description must compensate. It clarifies x_mm/y_mm (top-left origin), width_mm/height_mm (mutually alternative, aspect-preserving), and embed, but leaves id, show, label, parent, and the concurrency-critical expected_revision 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?

The name 'insert' is generic on its own, but the description immediately names the specific action and resource: placing a figure file into the document, with format-dependent handling of .svg vs .png/.jpg. It differentiates somewhat from format-oriented siblings, though it never explicitly addresses the closely related 'add_svg' tool, leaving a small ambiguity.

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

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

There is no explicit when-to-use guidance, no exclusions, and no named alternative among the many siblings (add_svg, render, export). The 'embed=False links the file instead' clause describes a flag, not a situation that should steer the agent to this tool over another.

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

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

With no annotations, the description carries the full burden. It usefully discloses that embedded images are summarised and that xml=True output is truncated to max_chars, which is genuine behavioral context. It says nothing about permissions, cost, or whether the operation is read-only, though 'inspect' strongly implies a safe read.

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

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

Two tight sentences; the content list is front-loaded and each enumerated item carries information. Slightly dense as a run-on enumeration, but there is no filler.

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

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

An output schema exists, so return values need no full explanation, and xml/max_chars behavior is covered. However, with heavy sibling overlap (attributes, text, style, structure, find) and zero schema documentation, the missing routing guidance and undefined ids semantics leave real 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 coverage is 0%, so the description must compensate. It explains xml's effect and the max_chars truncation interaction well, but the required ids parameter is never defined — the description says 'specific objects' without stating that ids is a required array of identifiers or its expected format.

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 makes clear this is the comprehensive per-object inspector, enumerating exactly what is retrieved (tag, label, tree position, bounding box, attributes, style, text, children). That scope implicitly separates it from narrower siblings like attributes, text, style, and structure, but it never names them, so differentiation is inferred rather than stated.

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, when-not-to-use, or alternative routing. 'Everything about specific objects' hints at the comprehensive role versus narrower siblings, but an agent must guess whether to call inspect or find/attributes/text for a given need.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the useful trait that starting is conditional ('if needed'), implying no duplicate launch. But it says nothing about blocking vs. returning immediately, what happens on an invalid or missing path, or whether a window is focused. The presence of an output schema relieves it of explaining return values, which keeps this at a 3 rather than lower.

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, with the format detail correctly relegated to parentheses. No filler. Slightly dense with nested parentheticals, which costs the fifth point.

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 launcher with an output schema and one optional parameter, the description covers the core action and file formats. It leaves open the null-path behavior and the blocking/return behavior, which an agent needs to sequence follow-up calls (e.g., to `status` or `render`). Adequate but with clear 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%, so the description must compensate for the single `path` parameter. It does add format semantics (.svg primary; .pdf/.ai/.eps also accepted), which the schema lacks entirely. But `path` is nullable with default null, and the description never explains what omitting it does — a meaningful gap for the only parameter.

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

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

The description gives a specific verb+resource pair – 'Start Inkscape ... and open `path` in it' – and even enumerates the file formats accepted (.svg/.pdf/.ai/.eps). The bare name 'launch' would be ambiguous without it, but the description resolves that. It stops short of distinguishing itself from siblings like `status` or `window`, so a 4 rather than 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?

'if needed' implies the tool is safe to call idempotently when Inkscape may already be running, which is useful guidance. However, it never states when to prefer this over `status` (presumably to check whether it is already running) or `window`, and it doesn't address what happens when `path` is omitted. Guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It does disclose real behavior: the joint-box semantics of the ids, the selectable anchor points, and that each=True operates per object rather than on the combined box. It says nothing about whether this is a mutating/undoable operation, what expected_revision does, or what show returns, leaving notable behavioral 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 dense sentences that front-load the operation and follow with the each=True modifier. The parenthetical anchor list and ellipsis are slightly noisy but efficient overall; no filler sentences.

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

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

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the geometric essentials but omits the concurrency parameter (expected_revision), the show flag, and any statement about reversibility or permissions. Adequate for the core operation, incomplete for full correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all 9 parameters. It explains dx_mm, dy_mm, x_mm, y_mm, anchor, and each reasonably well and ties ids to the 'joint box'. However, show and expected_revision are entirely unexplained, so it does not fully close 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 (move/place) and resource (the object ids), and goes further by defining two distinct modes: relative translation via (dx_mm, dy_mm) and absolute placement via (x_mm, y_mm) with an anchor point. An agent can tell this apart from a generic 'transform' tool. It never explicitly contrasts itself with reverse siblings like align or distribute, 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?

The 'and/or' phrasing implies dx/dy and x/y can be combined, which is useful usage context, and 'each=True places every object separately' hints at a per-object vs joint-box distinction. But there is no explicit when-to-use-this-vs-align/distribute guidance, no statement of prerequisites, and no exclusions.

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

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

With no annotations, the description still discloses real behavioral traits: deeper content is collapsed into counts, and refresh forces a re-read because caching is normally automatic. It omits any statement of read-only safety, permissions, or response size limits, but it goes well beyond restating the schema.

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

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

Front-loads the return content, then annotates each parameter compactly in a second block. No filler sentences, though the '(mm)' units and 'live bounding boxes' phrasing are terse to the point of jargon.

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 three of four parameters are explained. The undocumented max_lines parameter is exactly the kind of truncation control an agent needs to know about, leaving the definition short of complete for a 4-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%, so the description carries the full burden — and it documents root (default: whole page), depth (levels to expand), and refresh semantics with useful context. max_lines is left completely unexplained, which is the one real 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 opening sentence names the resource precisely — the object tree with ids, labels, text snippets and bounding boxes — so an agent knows it retrieves a document outline. However, it uses a noun phrase rather than a verb and never distinguishes itself from close siblings like structure, inspect, or find.

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 each parameter does but gives no guidance on when to reach for outline versus the many adjacent tools (structure, inspect, find, selection). Nothing states preconditions or the situations this tool is meant for.

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

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

With no annotations, the description carries the whole burden and does so well: it declares the operation is one undoable step (mutation semantics), that readonly=True skips the document reload, and that a timeout yields UNCERTAIN COMPLETION with the code possibly still applying. It also tells the agent how results are captured (print() and `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?

Front-loaded with the core purpose, then dense but purposeful clauses on scope, return capture, readonly, and timeout. The long list of available names is information-dense rather than padding, though the run-on structure makes it slightly harder to scan.

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 detailed, and the description still usefully notes that print() and `result =` come back. Combined with mutation, readonly, and timeout behavior it is nearly complete for a 4-param tool — only expected_revision is left 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 coverage is 0%, so the description must compensate, and it explains readonly (fast inspection, no reload) and timeout_s (give-up point with uncertain outcome) plus the code namespace available (svg, by_id, frames, to_px, qname, etc.). It never mentions expected_revision, the fourth parameter, leaving the concurrency-control argument entirely 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 (run Python/inkex against the live document) and immediately scopes it as the escape hatch — 'anything the other tools cannot express'. That single clause separates it from every sibling (move, style, text, align, etc.) without the agent opening another schema.

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

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

Gives clear selection context: use it when the specialized tools cannot express the operation, and use readonly=True for fast inspection. It does not name specific alternatives to prefer or state hard exclusions, so it falls short of a full when/when-not/alternatives rubric.

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

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

With no annotations at all, the description carries the full burden. It usefully discloses that rendering is a non-mutating visual operation ('to an image you can see'), that only=True hides content, and that annotate only draws on the image — but it says nothing about resolution limits, whether the live document can be modified in any way, or rendering cost.

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

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

Purpose is front-loaded in the first sentence and the rest is dense, parameter-relevant guidance with no filler. The middle section is a run-on that mixes area selection with annotation semantics, 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?

For a 7-parameter tool with no annotations and no output schema, the description covers the return medium (an image), the scoping options, and the two tricky parameters. It is adequate to call the tool correctly, with only width_px/background and any behavioral limits 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%, and the description compensates well: it gives the region_mm coordinate order [x0, y0, x1, y1], the around/margin relationship, the only flag's effect, and non-obvious annotate string forms ('children:<id>', 'top'). Only width_px and background are left entirely undocumented, which is a minor remaining 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: 'Render the LIVE document to an image you can see,' which tells an agent exactly what it gets back. It does not, however, distinguish itself from sibling tools like export, outline, or inspect that also produce views of the document.

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 clear workflow guidance for one option ('annotate ... the fastest way to learn which id is which') and explains the region-selection choice between region_mm and around. It never states when to use render versus export/inspect/save_copy, so tool selection against siblings 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?

With no annotations, the description carries the full behavioral burden. It adds useful non-obvious behavior: the anchor corner stays fixed, and keep_aspect=False with both dimensions triggers stretching through a slower extension. However, it omits mutation impacts, expected_revision semantics, each/show effects, permissions, undoability, and return 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 description is two sentences, front-loaded with purpose and tightly scoped to useful behavior. The second sentence covers a meaningful edge case without 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?

This is a high-complexity tool with 9 parameters, no annotations, and no output schema. The description covers core geometry behavior and one conditional path, but does not provide enough context for safe invocation across all parameters.

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 compensate. It clarifies width_mm, height_mm, scale, keep_aspect, and the anchor concept, but leaves ids, each, show, and expected_revision completely 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 action, 'Resize', with clearly named outcomes: exact visual width or height, scale factor, and fixed anchor corner. It does not explicitly distinguish the tool from sibling operations such as move, align, or distribute, 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?

There is no explicit guidance on when to use this tool versus alternatives. The only conditional guidance is that keep_aspect=False with both width_mm and height_mm stretches the object via a slower extension, which is behavioral detail rather than usage routing.

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

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

With no annotations, the description carries the burden and usefully discloses that unsaved changes are included and that the active editing file is not changed. However, it does not state whether an existing file at `path` is overwritten, what happens on write failure, or any permission requirements.

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

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

Two tightly written sentences front-load the action and immediately add the key non-obvious behavior. Every sentence earns its place by clarifying purpose and scope.

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

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

For a simple one-parameter write tool with no annotations but an output schema, the description covers the essential purpose and two important behavioral traits. It could be more complete on overwrite/error semantics, but return-value explanation is correctly omitted because an output schema exists.

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 the sole `path` parameter. It clarifies that `path` is the destination for an Inkscape SVG write, but does not specify path format, extension expectations, or relative/absolute path behavior.

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

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

The description states a specific verb and resource: write the live document, including unsaved changes, to `path` as Inkscape SVG. It also distinguishes the operation from saving the real file, so the agent can understand what this tool does without opening the schema.

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

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

It gives clear context for use: save a copy of the live document without changing the file the window is editing. It also states the contrasting user action, Cmd+S for the real save, but does not explicitly compare itself to MCP siblings such as `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 no annotations, the description carries the full burden. It does disclose the important dual behavior: read by default, replace when set_ids is supplied. However, it doesn't state permission/context requirements or confirm that replacing is non-destructive, so behavioral disclosure is only partial.

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 clauses, front-loaded with the read behavior, then the set_ids mode and its rationale in a single parenthetical. No wasted words.

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?

Low-complexity tool with one optional parameter and an output schema (so return values needn't be described). The description covers both modes and the parameter's intent, leaving only minor gaps like id format and any UI/permission preconditions.

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 must explain the sole parameter, and it does: set_ids replaces the selection and is tied to a concrete purpose (showing the user which objects you mean). It does not spell out the id format, but the meaning of the parameter is clear.

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

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

States a specific verb (read) and resource (the current selection), and also names the second mode (replace via set_ids). It is distinguishable from siblings like inspect or find, though it doesn't explicitly contrast with 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?

Gives a clear condition for the mutating mode: use set_ids to show the user which objects you mean. The read-only default is implied by the absence of set_ids. No explicit when-not or named alternative tools, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and the interrogative phrasing does imply a passive, read-only state check with no side effects. It enumerates the four categories of information returned, which is useful behavioral context, but it never explicitly states read-only safety, cost, or failure behavior when Inkscape is not running.

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 front-loads the primary question ('Is Inkscape running') and lists the remaining state queries without filler. Every clause adds a distinct piece of information.

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

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

For a zero-parameter read-only status tool with an output schema describing the return shape, the description is sufficient: the agent knows what it will learn. The one gap is the lack of differentiation from overlapping siblings like 'selection' and 'window'.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; the 100% schema coverage baseline of 4 applies. Nothing in the description misleads about inputs.

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 name plus the interrogative list makes it clear this reports runtime state: whether Inkscape is running, open documents, frontmost window, and current selection. It is a specific resource (application status), but it does not distinguish itself from siblings such as 'selection', 'window', or 'inspect', which plausibly cover overlapping state.

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 alternatives like 'selection' or 'window', nor any prerequisite or timing guidance. Usage is only inferable from the fact that it answers state questions.

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

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

With no annotations, the description carries the full burden. It discloses useful semantics for pop_out, z-order operations, reparent keeping visual position, and group optional fields, but omits the destructive nature of delete, reversibility, permissions, and expected_revision concurrency 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 purpose is front-loaded in one short sentence, followed by a dense pipe-delimited op list. It is efficient with little waste, though the packed notation is slightly hard to scan.

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. But with no annotations, seven parameters, 0% schema descriptions, and no mention of required target ids, expected_revision, or mutation safety, the description is not complete enough for all supported operations.

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 adds substantial meaning for the critical op parameter plus op-specific parameters like parent, index, new_id, and label. However, it leaves the required ids parameter and expected_revision unexplained, so compensation is incomplete.

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 operation family, 'Rearrange objects,' and enumerates concrete ops such as group, ungroup, reparent, and z-order changes. It does not explicitly contrast with siblings like move, align, or distribute, so sibling differentiation is not fully addressed.

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 no when-to-use guidance, prerequisites, or alternatives; it only lists operation names. An agent must infer that grouping, z-ordering, and reparenting belong here rather than in move or align.

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

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

With no annotations, the description carries the full burden. It does add real behavioral context: null removes a property, and group application with child inheritance/override semantics. However, it says nothing about the mutation's concurrency/versioning behavior (expected_revision) or whether changes are undoable.

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

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

Three tight sentences, front-loaded with the core purpose and an example, with no filler. The parenthetical aside about inheritance is the only place where information is compressed at the cost of immediate 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?

For a mutation tool with no annotations, no output schema, and a nested props object, this is reasonably but not fully complete. The core props semantics are covered, yet two of four parameters and the concurrency contract 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 coverage is 0% across 4 parameters, so the description must compensate. It explains the semantics of 'props' (CSS property names, null meaning removal) well, but leaves 'ids', 'show', and 'expected_revision' entirely undocumented in both description and 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?

States a specific verb+resource: 'Set CSS style properties on objects,' with an inline example showing the props shape. It is clear what the tool does, but it does not distinguish itself from close siblings like 'attributes' or 'text', which an agent may reasonably confuse with it.

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 named alternatives, despite several plausible overlapping siblings (attributes, text, inspect). The only conditional advice is diagnostic ('inspect them if a colour does not take'), which is troubleshooting, not selection 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?

With no annotations, the description carries the full burden, and it does disclose one important trait: all edits happen in a single undoable batch, and replace preserves mixed formatting rather than flattening it. That is real behavioral value. It does not disclose failure modes, what happens when an id is missing, how expected_revision conflicts are handled, or whether the caller needs any permission.

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 batch/undo framing is front-loaded in the first clause and the two payload shapes follow immediately with compact inline examples. Every sentence carries information; the only mild cost is the dense bracket-notation that takes a moment 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?

For a four-parameter mutation tool with no annotations and no output schema, the description covers the core edit semantics well but leaves two parameters (show, expected_revision) and the return value completely unaddressed. An agent could construct a basic call from it but would be guessing on concurrency and preview behavior.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for two of the four parameters: the exact shape of edits ({id, text} with \n for newlines) and replace ({old, new, ids}) is spelled out with examples, including that ids scopes the swap. The show and expected_revision parameters get no mention at all, leaving the optimistic-concurrency contract unexplained despite being named in the schema.

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

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

The description does state a concrete action ("change text in one undoable batch") and distinguishes two operating modes, edits vs replace, with inline payload examples. But the resource is only "text" with no indication of what object type or document the text belongs to, and the tool name itself ("text") conveys nothing on its own. An agent gets the mechanism but not the target domain.

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 distinguishes the two internal modes (whole-value replacement via edits vs substring swap via replace) and notes replace preserves mixed formatting, which is genuinely useful selection logic. However, there is no guidance on when to use this tool rather than siblings such as style, attributes, insert, or structure, and no prerequisites or exclusions 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?

No annotations are provided, so the description must carry the burden. It implicitly characterizes this as a safe observational read of the UI and clarifies exactly what pixels are captured versus the document rendering. It does not state the return format (image vs. file path), leaving one gap.

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

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

Two compact sentences, front-loading what is captured before the when-to-use clause. Every phrase adds information with no filler.

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

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

For a zero-parameter, no-output-schema tool, the description covers what is seen and when to invoke it. The only missing element an agent might want is the response shape (inline image vs. saved file), which is a minor 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?

The tool takes zero parameters, so there is nothing to disambiguate; baseline is 4. The description correctly adds no irrelevant parameter detail.

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

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

States a specific resource and verb: a screenshot of the Inkscape window itself, and enumerates the content captured (zoom, selection handles, open dialogs). This clearly distinguishes it from siblings like render (drawing output) and selection (state listing).

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

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

Explicitly gives usage conditions: when something seems stuck or to see what the user is looking at. It lacks an explicit 'do not use when...' or a named alternative for visual verification of the drawing, but the context is clear.

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