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

Annotations already declare destructiveHint=true, so the description isn't carrying the safety burden alone. It still adds real value by disclosing reversibility via ggb_undo, which the annotation does not express. It omits whether view/zoom state is also reset and gives no auth or rate-limit context.

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

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

A single sentence with zero waste; the destructive scope is front-loaded and the recovery note is parenthetically appended rather than padding.

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

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

For a zero-parameter, no-output-schema tool with a destructive annotation, the description supplies everything needed to invoke it safely: what is removed, the scope, and how to reverse it. It could be slightly more complete by noting whether viewport settings survive the clear.

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 the baseline is 4 per the rubric. The description correctly implies no filtering or scope arguments are accepted, and there is nothing further for it to document.

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 (remove) and an unambiguous resource scope (every object) with the intent (start a new figure). The 'every object' scope implicitly distinguishes it from the object-level ggb_delete, but it never names that sibling, so 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?

Gives a clear condition for use ('to start a new figure') and names the recovery path (ggb_undo), which is genuinely actionable routing information. It stops short of an explicit when-not clause or naming ggb_delete as the narrower alternative.

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

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

Annotations only declare destructiveHint=true; the description goes further by disclosing the cascade — everything depending on the deleted objects is deleted too — and points at usedBy in ggb_get_state as the way to preview the blast radius. It stops short of stating reversibility (ggb_undo exists as a sibling) or what a partial/failed delete reports.

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 short sentences, front-loaded with the action and the destructive caveat before the alternative. Every sentence carries distinct information: action, cascade consequence, and the correct path for modification. 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 single-parameter destructive tool with no output schema, the description supplies the essentials: what is destroyed beyond the named objects and what to use instead. Gaps are the accept/reject behavior for unknown names and whether the operation can be reversed via ggb_undo.

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

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

There is one required parameter, 'names', with 0% schema description coverage and no enum guidance. The description never explains that names are object labels matching those returned by ggb_get_state/ggb_screenshot — it only alludes to 'objects' and usedBy, which is too indirect to compensate for the complete absence of schema documentation.

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 ('Delete objects') and immediately scopes the action by noting that dependents are removed as well. It also names the sibling it is not (ggb_run_commands for redefinition), so an agent can separate it from ggb_run_commands and ggb_clear without opening any schema.

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

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

Gives an explicit alternative with a condition: to *change* an object, use ggb_run_commands instead of deleting and recreating. It also routes the agent to ggb_get_state's usedBy data before deleting. It does not address how this differs from a bulk wipe like ggb_clear, so the routing is clear but not exhaustive.

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

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

Annotations only declare readOnlyHint=true; the description adds the meaningful behavioral fact that evaluation leaves the figure unchanged, which is stronger than the annotation alone. It omits what happens on invalid expressions or how results are returned, but the critical side-effect question is answered.

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 clause and the examples follow as supporting detail. The example list is slightly long but each sample demonstrates a distinct expression class (measurement, equality check, predicate, object property).

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

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

With no output schema, the description should indicate what evaluation yields (numeric values, booleans, per-expression results) and how failures are surfaced; it says nothing about return shape or error behavior. The functional purpose and expression syntax are well covered, so the gap is limited to results handling.

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% for the single 'expressions' array, so the description must carry the load, and its six concrete expression examples do substantially clarify the expected GeoGebra syntax and boolean-comparison forms. It does not explain batch semantics (one result per item, evaluation order) or the 1-50 item bounds.

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 (Evaluate) plus resource (GeoGebra expressions against the current figure) and explicitly scopes it as not adding objects, which is exactly what separates it from the sibling ggb_run_commands. An agent can pick between the two without opening either schema.

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

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

The phrase 'WITHOUT adding objects, to verify the construction' gives a clear use context (checking/validating an existing figure rather than mutating it), implying the alternative ggb_run_commands for object creation. It never names that sibling or states when-not to use this tool, so it stops short of explicit 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond format meaning. It does not say whether an existing file is overwritten, whether the directory must exist, what happens on failure, or what the call returns — all material for a tool that writes to disk.

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

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

A single front-loaded sentence with zero filler; the action comes first and the format details follow as needed.

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 two-parameter, no-output-schema export tool this is minimally adequate — format semantics are covered — but overwrite/error behavior and confirmation of success are left unspecified, which matters for a file-writing operation with no annotations to lean 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 50%: 'path' is documented in the schema but 'format' is a bare enum. The description fills exactly that gap by explaining what 'ggb' and 'png' mean and that a .ggb file can be reopened in GeoGebra, which is genuinely useful beyond the structured data.

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 (save/export) and resource (the figure) plus the two supported output formats. It is clear what the tool does, though it never names or distinguishes itself from the sibling ggb_screenshot, which also produces an image.

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 'Save the figure to a local file' implies when to reach for it (persisting output to disk), and the parentheticals hint at format selection. However, there is no explicit when-not guidance or comparison to ggb_screenshot, so the agent must infer the boundary itself.

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 the fit normalizes to a 1:1 axis ratio and that it can also mutate axes/grid visibility, which is a side effect beyond the name. It does not state whether the view change is undoable, whether omitted flags leave existing state untouched, or whether hidden objects are excluded from the fit.

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 core effect, then the invariant in a compact parenthetical, then the optional flags. No filler and no repetition of the title.

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, side-effect-light view tool with no output schema this is roughly adequate: the visual outcome and the two toggles are covered. It still leaves the omission semantics of show_axes/show_grid and the treatment of off-screen or hidden objects unspecified, which an agent would need before calling it confidently.

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

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

Schema coverage is only 33%: 'padding' is documented in the schema, while show_axes/show_grid have no schema descriptions. The description partially compensates by explaining that those two flags show/hide axes and grid, but it never clarifies the default behavior when they are omitted or how padding interacts with the fit.

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 pair (zoom/pan), the trigger condition (so every visible point and circle fits in the drawing area), and an invariant (1:1 axis ratio). It is clearly distinct from siblings like ggb_screenshot or ggb_set_style, though it does not explicitly contrast itself with any of them.

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

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

Usage is implied by the effect described ('so every visible point and circle fits'), letting an agent infer it is a remediation call after objects fall outside the viewport. There is no explicit when-to-use, when-not-to-use, or named alternative, so it stays at the minimum-viable 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 only readOnlyHint=true provided, the description usefully adds the return contract (the exact fields listed) and defines the semantics of dependsOn/usedBy, including the destructive implication of usedBy ('objects that would change or be deleted with it'). It does not mention pagination, cost, or size limits on a potentially large figure.

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 output inventory, followed by the actionable directive to call it before fixing. No filler or restatement of the title.

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 output schema exists, and the description compensates by enumerating every returned field and explaining dependsOn/usedBy. Safety is covered by the readOnly annotation, and the usage trigger is stated, leaving nothing critical missing.

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

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

Schema description coverage is 100%, so both parameters (names, include_hidden) are already documented in the schema. The description adds no additional constraint or format guidance for them, so the baseline 3 applies.

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

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

States a specific verb+resource ('List the objects currently in the figure') and then enumerates exactly what each entry contains (name, type, definition, value, coordinates, visibility, dependsOn, usedBy). This distinguishes it from screenshot/evaluate siblings without needing to name them.

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

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

Gives an explicit when-to-use rule: 'Always call this before fixing a figure: the user may have edited it by hand.' That's a clear context trigger. It does not name alternative tools or when-not-to-use, 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 burden and does fairly well: it discloses the redefinition semantics ('Assigning to an existing name REDEFINES that object and its dependents update'), execution ordering, and the failure surface (warnings for undefined objects and names not created, plus cause hints). It does not state prerequisites such as whether a figure/session must already be open or whether destructive removal via Delete(P) is reversible.

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 action, then semantics, then return shape; every element earns its place. The inline example list is long but justified for a free-form command string parameter, though it makes the middle of the description 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 tool with no output schema, the description does the heavy lifting by explaining the per-command return fields (ok, created/removed objects, warnings, failure hints). Remaining gaps are prerequisites (active figure, permissions) rather than return-value omissions.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description reinforces ordering semantics for 'commands' and the dependency rationale behind stopping early, but adds no syntax or constraint detail beyond the schema (the maxItems=300 limit, for instance, appears only 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?

States a specific verb and resource ('Run GeoGebra commands on the live figure, in order') and backs it with concrete command examples ('A = (-1, 6)', 'Midpoint(B, C)', 'SetVisibleInView(h, 1, false)'). The command-batch framing is clearly distinguishable from siblings like ggb_evaluate, ggb_set_style, and ggb_delete, which operate on a single object or expression.

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

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

Usage is only implied: the examples and the phrase 'in order' suggest this is for scripted multi-step figure construction or edits. There is no explicit when-to-use guidance and no mention of when a sibling (ggb_evaluate, ggb_set_style, ggb_delete) would be the better choice.

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

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

readOnlyHint=true already tells the agent this is a safe read; the description usefully adds that the result is a PNG of the drawing area and that full_window pulls in the algebra panel. It does not mention image size, resolution, or whether the capture reflects current zoom/state, so remaining behavioral gaps are minor but real.

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 return type and immediately followed by the parameter explanation. No filler or restated boilerplate.

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

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

For a single-boolean, read-only capture tool with no output schema, the description covers what is returned and what the flag does. Only the absence of any note about image dimensions or capture fidelity keeps it from being 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 description coverage is 0%, so the description carries the load, and it does explain the one parameter clearly: full_window captures the whole GeoGebra window including the algebra panel, versus the default drawing-area-only view. This is meaningful semantics beyond the bare boolean and default 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?

States a specific verb and resource: 'Return a PNG image of the drawing area.' The parenthetical use cases (overlapping labels, off-screen figure, wrong shape) sharpen it further. It does not distinguish itself from close siblings like ggb_snapshot or ggb_export, which prevents 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?

Gives clear context for when to reach for it: visual verification of the figure. However, it offers no guidance on when to prefer ggb_snapshot or ggb_export instead, and no exclusions, so it sits below the explicit-alternatives tier.

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 and does not meet it. It says nothing about whether the change is reversible/undoable, what happens with invalid or missing object names, whether it requires the objects to exist, or how errors surface. Only the surface effect ('look') is conveyed.

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 leads with the core action and then lists options; no filler. The dense comma list is slightly hard to parse but earns its length.

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?

A 10-parameter mutation tool with no annotations, no output schema, and 40% schema coverage needs more than a property list. The required 'names' parameter, mutation semantics, error behavior, and return value are all unaddressed, leaving the agent under-informed.

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 40%, so the description must compensate. It does list most updatable fields (color, visibility, label, caption, thickness, line style, point size, fill, fixed) and clarifies caption as 'text shown instead of the name', which is helpful. However it omits the required 'names' parameter entirely and adds no format/syntax detail 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 and resource ('Change how objects look') and enumerates the style properties affected, so the agent knows this mutates visual attributes rather than geometry. It does not explicitly differentiate itself from siblings like ggb_run_commands, which could plausibly also set style.

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

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

There is no when-to-use guidance, no mention of prerequisites (the target objects must already exist), and no reference to an alternative tool. The usage context is only weakly implied by the verb 'Change'.

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: snapshots are in-memory and vanish when the server stops. However, it does not state that 'restore' overwrites the current figure (a destructive outcome), what happens on restore of an unknown name, or whether saved snapshots can be re-saved.

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

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

Two short, front-loaded sentences with no wasted words; the action list comes first and the lifetime caveat second. Slightly terse given the gaps it leaves, but structurally sound.

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-parameter mutation-capable tool with no annotations, no output schema, and 0% schema coverage, the description leaves the per-action parameter contract and restore semantics unstated. The lifetime note is helpful but the definition is only minimally adequate.

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; it only partially does. It links 'name' to the save action, but never says that name is required for save/restore and irrelevant for list, nor does it define any naming constraints or collision 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 uses specific verbs (save, restore, list) against a clear resource (the current figure / saved snapshots), so an agent immediately knows this is the snapshot-management tool. It does not explicitly name or rule out any sibling (e.g. ggb_clear or ggb_undo), so it stops 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 three actions imply the situations in which the tool is used, but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives such as ggb_undo or ggb_clear for reverting state. Usage is inferable from the action enum alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses the scope of what undo covers (changes made through this server, and which operation types), which is real context. However it does not state whether the undo is itself reversible, how deep the history is, or what happens when the limit is hit — significant gaps for a mutation tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler; the parenthetical enumeration is compact and earns its place by defining undo 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 mutation tool with no annotations and no output schema, the description covers purpose and undo scope but omits the behavioral details an agent needs: irreversibility, history depth, and the semantics of the undocumented 'steps' parameter.

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 never mentions the single 'steps' parameter. The phrase 'last change(s)' weakly hints that multiple changes can be reverted, but the default of 1, the minimum of 1, and the maximum of 50 are left entirely to the schema with no explanation.

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

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

It states a specific verb (revert) and scopes the resource precisely to changes made through this server, then enumerates exactly which sibling operations are undoable (run_commands, set_style, delete, clear, snapshot restore). An agent can distinguish this from the mutation siblings without opening any schema.

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

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

Usage is implied — call it to reverse a prior change — and the enumerated undoable operations clarify the context. But there is no explicit when-to-use vs. an alternative, no exclusions, and no mention of what to do if the undo history is empty or exhausted.

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