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

With no annotations, the description carries the behavioral burden. It usefully discloses that relative paths resolve against the process cwd and that no write occurs without a path, but it does not mention overwrite behavior, return values, or error conditions 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?

The description is three short, front-loaded sentences with no filler. Each sentence adds relevant information: the core write action, path resolution behavior, and the no-write guard.

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

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

For a one-parameter export tool, the description covers the destination, format, and path resolution. It is missing explicit overwrite semantics and return behavior, which would be useful for a write operation with no annotations and no output schema.

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

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

The schema already documents the single path parameter with 100% coverage, including an example. The description adds minor context about cwd-relative resolution, but the schema carries most of the parameter meaning, so the baseline score of 3 applies.

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

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

The description clearly states the action (write), the resource (current diagram), and the output format (.drawio) to an explicit filesystem path. It is distinct from the sibling tools by nature, but it does not explicitly name a sibling or state what it is not, so it falls short of full differentiation.

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

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

The intended use is implied: export the current diagram to a file. However, there is no explicit guidance about when to prefer this over diagram_snapshot, diagram_restore, or other siblings, and no when-not-to-use conditions are provided.

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 available, the description carries the behavioral burden. It does well by revealing a non-obvious behavior: 'Do not supply x/y; draw.io layout places new cells' and 'Coordinates belong to the editor, not the model.' It does not disclose broader mutation consequences like idempotence or validation behavior, which keeps it from being 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?

The description is short, front-loaded, and wastes little space: it opens with purpose and immediately gives the actionable coordinate warning. The final sentence, 'Coordinates belong to the editor, not the model,' is conceptually useful but somewhat redundant with the preceding sentence, preventing a full 5.

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 description is reasonably complete for a small patch tool: it names the supported edit types and warns against a common invalid input class. Missing context includes how the 'layout' parameter behaves, how references between operations are resolved, and what kind of response or effect to expect for a nuanced nested operations array.

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

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

The schema description coverage is 0%, so the description must compensate. It partially compensates by enumerating the operation types and explaining that coordinates should not be user-supplied. However, it never mentions the 'layout' parameter, which is one of only two parameters, omitting meaningful guidance about what layouts do or when to choose them.

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 and resource: 'Apply a few structured edits (add_node, add_edge, set_label)'. It clearly identifies what the tool does at a glance. It does not explicitly contrast itself with sibling tools like diagram_replace, so it falls short of a perfect 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 'Apply a few structured edits' implies this tool is for incremental changes rather than wholesale replacement, giving some contextual usage signal. However, it does not explicitly state when to prefer diagram_patch over diagram_replace or any other sibling tool, and it provides no exclusions or alternative 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 behavioral transparency burden. It discloses the default summary format, the XML option, the live/saved canvas fallback, and the explicit side-effect note that it does not create directories. It could additionally state that it never modifies the diagram, but 'Read' already implies that.

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

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

Three efficient sentences, front-loaded with the core purpose, then parameter behavior, then source selection and side-effect note. No filler, no repetition of schema fields.

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

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

The tool has only one optional parameter, and the description covers the parameter, source fallback, and non-mutating behavior. Since there is no output schema, a bit more detail on what the compact summary actually contains would make it fully 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 coverage is 0%, but the description fully explains the only parameter: 'summary' maps to 'compact cell summary for the agent' and 'xml' maps to 'full draw.io XML'. This adds substantial meaning beyond the raw enum values.

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?

Begins with a specific verb and resource: 'Read the current diagram'. It clearly states the two output modes and source selection, but it does not explicitly differentiate itself from the diagram_export sibling, which could also be a read-like operation.

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 guidance on when to use each format ('Default is a compact cell summary', 'Pass format=xml for the full draw.io XML') and on the live vs. saved canvas fallback. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to choose appropriately.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose a destructive side effect ('Replace the whole diagram'), a live-canvas load, and layout application. It does not mention reversibility, whether existing unsaved edits are destroyed, or whether the operation can be undone — for a destructive whole-replacement tool this is a notable 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 sentences with zero waste: the primary action is front-loaded, then a behavioral note, then a usage preference. Every sentence contributes distinct 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?

No annotations, no output schema, and no mention of return values, failure modes, or the destructive consequence of wiping the existing diagram before a snapshot is taken. For a whole-diagram replacement tool, important operational context is missing — an agent could destroy work without being warned to snapshot first.

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 67%, and the schema already describes layout and content; format is defined via enum. The description adds context that format maps to Mermaid vs draw.io XML and that layout is applied by draw.io, but does not meaningfully enrich individual parameter understanding beyond the schema.

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

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

States a specific verb ('Replace'), resource ('whole diagram'), and accepted formats ('Mermaid or draw.io XML'). The phrase 'whole diagram' clearly distinguishes it from the sibling diagram_patch, which implies partial edits.

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 explicit guidance to prefer this over many tiny geometry edits, implicitly routing agents away from diagram_patch. However, it does not explicitly name the alternative tool nor state conditions like when to use diagram_patch or when a snapshot/restore workflow is advisable.

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 must carry behavioral disclosure, and it does state that restore copies a snapshot to current and loads it, and that there is no separate checkout/rollback. That covers key semantics, but it does not explicitly warn that existing canvas content is overwritten or whether the operation is destructive/reversible, so the disclosure is 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 sentences, no filler, and the core action is front-loaded before the behavior qualifier. Every sentence 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?

For a one-optional-parameter restore tool, the description covers the main invocation modes and the copy/load semantics. The main gap is no explicit statement about overwriting/destroying current canvas state, which matters for a mutation tool with no annotations or output schema to fall back on.

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%, but the description compensates by explaining that label identifies the snapshot to restore and that omitting it lists snapshots. It defines the parameter's role and optionality, which is sufficient for a single string 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 names a specific action ('Restore') and a specific resource ('labeled snapshot onto the canvas'), making the tool's core function immediately identifiable. It also distinguishes restore from list mode and clarifies the copy/load semantics, which separates it from generic canvas-editing 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?

It offers one useful usage signal: omitting label switches to listing snapshots. However, it does not say when to choose this tool over siblings like diagram_snapshot, diagram_replace, or editor_ensure, nor does it state the conditions under which restore is the appropriate operation (e.g., rollback vs. editing).

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It usefully states that snapshots live under the user data directory and not the agent cwd, but it does not disclose whether reusing the same label overwrites an existing snapshot or creates a duplicate, nor what the tool 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?

A single, tightly worded sentence that front-loads the action and immediately states the critical location constraint. Every element earns its place with no filler.

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

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

For a one-parameter, read-like snapshot operation, the description is largely complete for correct invocation: action, destination, and labeling are covered. The only substantive gap is duplicate-label behavior, which would strengthen the description further but is not essential for a first call.

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

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

The schema fully documents the single parameter 'label' with a helpful example, so the schema covers the semantics. The tool description adds no additional meaning beyond the schema, keeping this at the baseline score for full schema coverage.

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

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

The description clearly identifies the verb ('Copy'), the resource ('current diagram'), and the destination ('a labeled snapshot under the user data directory'). The explicit parenthetical 'not the agent cwd' prevents a common mistake and helps distinguish this from file-exporting siblings like diagram_export.

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 snapshot concept implies a checkpointing use case, but the description does not explicitly say when to prefer this over diagram_restore, diagram_export, or diagram_patch. It provides useful context about where the snapshot is stored, but no explicit when-to-use or 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?

With no annotations to fall back on, the description discloses meaningful behavior: it may open a browser, it blocks/waits for a connection, and it does not create store directories. However, it omits details such as timeout behavior, side effects of launching a browser, or what 'connected' means, so transparency 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?

One sentence with an active verb, immediately states the action and wait condition, plus a useful explicit non-effect. No filler or redundancy.

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

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

For a zero-parameter setup tool, the description covers what the tool does, the environment it affects, and an explicit non-effect. It lacks timeout/failure details, but the schema and parameter surface are minimal, so this is reasonably 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?

The tool has zero parameters and schema coverage is complete, so the baseline of 4 applies. The description does not need to explain 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?

The description clearly states a specific action ('Open the local draw.io canvas') and an outcome ('wait until it is connected'), which is distinct from all sibling diagram_* tools that perform modifications or reads on diagrams. The negative claim 'does not create store directories' also helps disambiguate scope.

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?

While 'if needed' implies this is a setup or prerequisite step, the description provides no explicit guidance about when to call this tool versus alternatives, nor any conditions under which it should be skipped.

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