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

With no annotations, the description must carry behavioral weight. It usefully discloses the output filename pattern and that a list of paths is returned, but omits whether existing files are overwritten, whether out_dir must already exist, and how failures are reported — real concerns 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?

Two short sentences with no filler; the naming convention and the directory scope are front-loaded, and the return value follows. Every sentence earns its place.

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

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

For a one-parameter export tool with no annotations and no output schema, the description covers the essentials (naming, destination, return type) but leaves gaps around overwrite behavior, directory prerequisites, and output format/size that an agent might need before invoking it.

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 single parameter out_dir has 0% schema description coverage, so the description must compensate. It does add meaning by stating that files are written into that directory with the slide_NN.png naming scheme, but leaves open whether the directory must exist or is created.

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 every slide as slide_NN.png in the given directory' — which is clearly distinguishable from the single-target app.export_png sibling in scope ('every slide'). It does not explicitly name or contrast with that sibling, so it falls just 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 word 'every slide' implies bulk export versus the sibling app.export_png for a single slide, but the description never names the alternative or states when to prefer each. Usage must be inferred from the scope wording rather than read directly.

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. 'Lossless internal model' is useful context, but it does not disclose whether existing files are overwritten, whether the document must be open, or what errors can occur when writing the path.

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 single sentence is front-loaded and waste-free. It is perhaps too terse for a file-export operation, but it avoids unnecessary repetition.

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

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

With no annotations, no output schema, and an undocumented parameter, the description is incomplete for a tool that writes to disk. It does not cover file overwrite semantics, return behavior, or error conditions that an agent would need.

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 ('path') with 0% schema description coverage. The description only implies that 'path' is the destination JSON file, adding little beyond the parameter name and type.

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: 'Dump the document to a JSON file.' The parenthetical '(lossless internal model)' distinguishes this from lossy exports like app.export_png. However, it does not explicitly differentiate from app.save_document or app.save_document_as.

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 format (' file') and the 'lossless' qualifier, but there is no explicit when-to-use guidance, no named alternative, and no prerequisite context for choosing this over save_document.

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 useful implementation behavior (headless render via QGraphicsScene on a fresh QImage, no GUI widget shown). It omits mutation-relevant behavior: whether an existing file at `path` is overwritten, whether directories are created, and what is returned on success or failure.

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

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

Two tightly written sentences with the primary action front-loaded and no padding. The second sentence is arguably implementation trivia, but it is short and informative rather than wasteful.

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 write-side export tool with no annotations, no output schema, and 0% parameter documentation, the description should state return value (e.g., written file path), overwrite behavior, and index semantics. Those gaps leave the agent unsure how to invoke it safely even though the core action is 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?

Schema coverage is 0% with two parameters, so the description must compensate and it largely does not: `path` format expectations and `slide_index` indexing base or default slide are unexplained. Worse, it advertises a 'default 2x = 1920x1080' scaling notion but no scale parameter exists in the schema, which can mislead the agent about available controls.

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

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

Specific verb and resource: 'Render a single slide to a PNG file' with resolution scope stated. It implicitly contrasts with export_all_png via the word 'single', but never names that sibling explicitly, so differentiation is inferential 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?

No explicit when-to-use guidance or named alternatives, though 'single slide' hints at the boundary versus app.export_all_png and the PNG format hints at export_json. The agent must infer the selection criteria on its own.

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 usefully discloses that the operation resets the document to blank and clears the clipboard, but it does not explicitly warn about unsaved changes being discarded or describe reversibility/undo 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 short sentences with no wasted language. The primary action is front-loaded, and the secondary side effect follows immediately.

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

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

For a document-reset tool with no annotations, no output schema, and an undocumented optional parameter, the description is only minimally complete. It covers the core action and one side effect but leaves important details about title defaults, data loss, and return behavior unspecified.

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 single optional title parameter has 0% schema description coverage, so the description must compensate. It only says 'with the given title' and does not explain whether the title is optional, what happens if it is omitted, or any formatting constraints.

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

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

The description states a specific verb and resource: reset the document to a blank one with a given title. This clearly distinguishes the tool from opening an existing document, though it does not explicitly name app.open_document as the alternative.

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 the tool does but gives no explicit guidance on when to choose it over app.open_document or other document-creation paths. The blank-document use case is implied, but no exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden and does disclose two non-obvious behaviors: it destroys the current document, and it clears the clipboard as a side effect (relevant given the sibling clipboard.peek/clear tools). It still omits whether unsaved changes are prompted for or silently discarded, and how an invalid or missing path is handled.

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

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

Two short sentences, zero padding, with the primary effect front-loaded and the side effect trailing. Every clause carries information.

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

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

For a one-parameter tool with no annotations and no output schema, the description covers the important state effects but leaves the parameter and failure modes undocumented. An agent knows what it does to the session but not how to call it correctly on the first try.

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 single required parameter 'path' is never mentioned in the description. Nothing tells the agent whether the path must be absolute, whether the .pptx extension is required, or whether the file must already exist — the description must compensate here and does not.

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 ('Open a .pptx file') plus the effect on existing state ('replace the current document'), which implicitly separates it from app.new_document and the document.* editing tools. It does not explicitly name a sibling to contrast with, 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?

Usage is only implied: the agent can infer this is how you load an existing .pptx rather than create one. There is no statement of when not to use it, no mention of what happens to unsaved work in the current document, and no pointer to app.new_document as the alternative for starting fresh.

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 headless no-op behavior, which an agent could not otherwise infer. But it does not say whether unsaved work is discarded, whether the process actually terminates, or whether a confirmation is raised — significant omissions for a quit 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?

A single short sentence with the headless caveat attached inline; no filler and nothing buried.

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, no-annotation tool the description is nearly sufficient, but a quit action's most consequential detail — what happens to unsaved documents — is absent, and there is no return value 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?

The tool takes zero parameters and the schema has no properties, so there is nothing for the description to explain. Baseline of 4 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 ('quit') and target ('the GUI'), so the agent knows this terminates the GUI application rather than a document or session. No sibling tool overlaps, so differentiation is moot. The only slight ambiguity is whether quitting is immediate or request-based, but the action is unmistakable.

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 '(no-op in headless mode)' effectively tells the agent when NOT to bother calling it, which is real conditional guidance. However, there is no guidance on prerequisites (e.g. save documents first) or on what state the app must be in.

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 failure mode when no current path exists. It says nothing about overwrite behavior, permissions, or what happens on success (silent vs. returns a path), which matters 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?

A single front-loaded sentence with the failure condition and the fallback tool, no filler. 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?

For a one-parameter write tool with no annotations and no output schema, the description covers the key decision (fail vs. use save_document_as) but omits overwrite/return behavior an agent would want before committing a save.

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

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

Schema coverage is 100% and the single path parameter is documented as an optional override, so the baseline is 3. The description only addresses the no-path failure case and never explains that supplying path redirects the save, leaving the override semantics to the schema.

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

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

States a specific verb and target ('Save to the current path'), making the operation immediately identifiable. It also names the sibling it is not (save_document_as), so an agent can choose between the two without inspecting schemas.

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

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

Gives an explicit when-not condition ('if no path set, fails') and routes the agent to the alternative tool (save_document_as). It stops short of a full when-to-use statement, but the decision-relevant condition is present.

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

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

No annotations are provided, so the description carries the full burden, yet it never says whether an existing file at that path is overwritten, whether the format is inferred from the extension, or whether the current document state is modified. Only the bare fact that saving targets a path 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?

Five words, front-loaded and waste-free, but the brevity reflects under-specification rather than tightness; there is room to add essential detail without bloat.

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 write/mutation tool with no annotations, no output schema, and a single undocumented parameter, the description omits nearly everything an agent needs: overwrite behavior, format selection, return value, and eligibility relative to app.save_document.

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 'path' parameter. The phrase 'specific path' gives almost nothing beyond the schema — no indication of whether it is a file path vs directory, which extensions/formats are supported, or whether relative paths are accepted.

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 the verb 'Save' and that a path is involved, which hints at a save-as (write to a new location) operation. However it does not distinguish this from the sibling app.save_document, so an agent cannot tell which to pick without guessing at hidden semantics.

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, no mention of app.save_document or app.open_document as alternatives, and no prerequisites (e.g., must a document be open first?). Usage can only be inferred from the name.

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

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

No annotations exist, so the description carries the full burden. It does disclose the important scope constraint — only the in-process clipboard is affected, not the system clipboard — but says nothing about irreversibility, whether an undo exists, or whether the cleared contents are returned or discarded.

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 four-word sentence with the action and the target front-loaded and zero filler. Nothing is wasted or buried.

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 no-argument, no-output utility this covers the essentials, but with no annotations and no output schema the description is the only place a caller could learn about irreversibility or return behavior, and it omits both.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. The empty schema with additionalProperties: false is consistent with the description's no-argument framing.

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

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

Specific verb ('Empty') plus a precise resource ('the in-process clipboard'), so the agent knows exactly what is removed. The 'in-process' qualifier implicitly separates it from OS-level clipboard operations and from the sibling clipboard.peek, though it doesn't name that sibling.

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

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

Usage is implied by the verb — call it when you want the clipboard emptied — but there is no statement of when this is preferable to alternatives or what a caller should do first. For a zero-parameter utility tool that is largely self-evident, an implied-usage score is appropriate.

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 adds a genuinely useful scoping fact, "in-process" (as opposed to an OS-level clipboard), and enumerates the reported fields, but says nothing about behavior when the clipboard is empty or errors, and only implies non-mutation via "inspect".

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 the purpose front-loaded and a compact parenthetical listing the returned fields. Nothing is redundant or padded.

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 parameters and no output schema, the description usefully enumerates the return payload (size, is_cut, source slide, shape payloads), which substitutes for the missing output schema. Only the empty-clipboard / error behavior is left unspecified.

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; there is no parameter semantics to explain and the description does not need to compensate for a schema 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 ("Inspect") and resource ("the in-process clipboard") plus the fields it surfaces (size, is_cut, source slide, shape payloads). It is clearly distinguishable from the sibling clipboard.clear, though it never names that sibling explicitly.

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

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

No statement of when to call this tool versus alternatives (e.g., before document.paste or document.paste_slide to verify clipboard contents), and no exclusions or prerequisites. The intended use is only inferable from the word "inspect".

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 that it returns the new shape id and that extra props 'ride through onto the shape verbatim' – a genuine behavioral trait – but says nothing about error behavior for invalid slide_index/kind combinations, coordinate units, or undo interaction.

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 and return are front-loaded, followed by a dense but earned per-kind enumeration. Some repetition ('kinds:' twice with inconsistent spacing) is minor overhead for covering nine enum values plus a nested props object.

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?

Given no annotations, no output schema, and a nested free-form props object, the description explains the variant-specific contract well but omits positional-parameter semantics, slide_index defaulting, and failure modes an agent would need to call it correctly.

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

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

Schema coverage is only 42%, but the description compensates well: it groups the nine kinds, explains props.prst/path_ops/rows/cols/cells and the freeform op format (M/L/C/Q/Z). Gaps remain for x/y/w/h units and slide_index defaults, which are undocumented in both places.

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

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

Opens with a specific verb+resource ('Add a shape to a slide') and states the return value. The per-kind breakdown makes the scope concrete, though it never contrasts with siblings like move_shape/resize_shape to complete the 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?

Per-kind instructions ('pass props.prst', 'path_ops is required') imply how to use each variant, but there is no explicit when-to-use guidance, no prerequisites (slide_index default, whether the slide must exist), and no routing against sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It only says that a new slide is appended and that the new index is returned; it omits whether the slide is blank, whether the title is applied, whether changes are persisted, and any permission or error conditions.

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 short sentences with the core action front-loaded and a useful return-value note. It is concise, though brevity here contributes to under-specification rather than clarity.

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 incomplete parameter documentation, this description is too thin. It should clarify insertion semantics and the effect of the title parameter to be sufficient.

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 only 50%, and the description adds no parameter meaning. It does not explain that index values other than -1 may control insertion position, and it says nothing about the title parameter, which has no schema description either.

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: "Append a new slide." This distinguishes it from siblings like document.duplicate_slide or document.add_shape, but the word "append" understates the schema's index parameter, which implies insertion at a specific position is also possible.

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 guidance on when to use this tool versus alternatives such as document.duplicate_slide, document.copy_slide, or document.paste_slide. It also does not mention prerequisites like having an open document.

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 it does disclose the one genuinely non-obvious behavior: alignment is computed against the bounding box of the selection. It omits what happens with a single shape, whether the operation is undoable, and what the response is.

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

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

Two sentences, zero waste, with the action and its valid values front-loaded and the non-obvious mechanic (bounding-box target) immediately after.

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 tool with no annotations and no output schema, the description covers what it does and the alignment reference point. The remaining gap is the optional-parameter default behavior and the return value, which is minor but real.

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 partially does by implying shape_ids takes 2+ shapes and that the target is the selection's bounding box. However, it never explains that shape_ids is optional or what happens when it is omitted (presumably the current selection) - the most consequential ambiguity in this 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 ('Align') and resource ('2+ shapes on the current slide') plus the exact set of alignment edges, which is enough to tell it apart from move_shape/resize_shape/reorder_shapes in practice. It never explicitly names those siblings as alternatives, keeping it just 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 '2+ shapes on the current slide' constraint and the bounding-box target imply the operating context, but the description never says when to prefer this over move_shape or resize_shape, nor does it state prerequisites such as an active selection.

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. 'Return whether undo/redo are possible' implies a read-only availability check, but it does not clarify whether the result is one combined boolean or separate undo/redo flags, nor does it explicitly state that there are no side effects.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose.

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 query tool, invocation is trivial, but the absence of an output schema makes the return-shape description important. The description conveys the high-level result but leaves ambiguity about whether undo and redo availability are returned as distinct values or combined.

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 an empty input schema, so there are no parameter semantics to document. Baseline 4 is appropriate because the description does not need to compensate for any schema gaps.

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 query: returning whether undo/redo are possible. It distinguishes the check from the actual undo/redo actions, but it does not explicitly contrast itself with sibling tools such as document.undo or document.get_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?

Usage is implied: an agent would call this before undo/redo to decide whether those actions are available. However, the description gives no explicit when-to-use guidance, prerequisites, or alternatives.

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 clipboard is in-process and shared with the GUI (Edit → Copy / Cmd-C), which is real behavioral context. But it doesn't say that copying overwrites existing clipboard contents, nor mention interactions with clipboard.peek/clear.

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 core action, then default behavior, then the clipboard-sharing note. Every sentence adds distinct information with no waste.

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

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

For a single-optional-parameter tool with no annotations and no output schema, the description covers action, default behavior, and clipboard scope. It could be more complete by noting that existing clipboard contents are replaced, but nothing critical for correct invocation 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 coverage is 0%, so the description must compensate, and it does: it defines the shape_ids parameter's type-meaning and, importantly, the omit semantics (defaults to all shapes on the current slide). That goes meaningfully beyond the bare array 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 verb and resource ('Copy the given shape ids') and the destination ('in-process clipboard'), so an agent knows exactly what the operation does. It does not explicitly contrast with siblings like document.copy_slide or document.duplicate, but the clipboard destination implicitly separates it from those.

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 behavior when shape_ids is omitted (all shapes on the current slide), which is useful usage context. However, it gives no guidance on when to choose this over document.cut or document.duplicate, nor any prerequisites or 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?

No annotations exist, so the description carries the full behavioral burden and does disclose two non-obvious traits: the clipboard persists across calls, and indices default to the current slide. It leaves open whether a copy replaces prior clipboard contents and how invalid indices are handled.

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

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

Three tight sentences, zero filler, with the core action front-loaded and the caveat/alternative last where an agent will still read it.

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-param, no-output-schema tool with no annotations, it covers purpose, default, persistence, and the unsupported cut case. The remaining gap is clipboard-displacement semantics versus the separate shape clipboard, which an agent might want to know.

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% with a single optional parameter, so the description must compensate; it does by supplying the default (`[current]`), which the schema does not. It adds no further detail on ordering or empty-array behavior, keeping it below 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?

States a specific verb and resource ('Copy whole slides') and pins the destination as the 'slide-level clipboard', which implicitly separates it from the generic document.copy/paste shape-level siblings. The reader knows exactly what lands where 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?

Explicitly rules out cut and names the alternative two-step path (duplicate_slide + delete_slides), which is strong routing. It doesn't state the inverse case (when to prefer duplicate_slide over copy+paste), so it stops short of full when/when-not coverage.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses clipboard copying, destructive removal from the slide, and the undo granularity of separate commands per removal. It does not cover edge cases such as invalid ids, empty input, or whether existing clipboard contents are replaced, but the core mutation and undo behavior are clearly stated.

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

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

Two short sentences are front-loaded with the primary action and then add the undo-granularity detail. Every sentence earns its place and 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 a simple one-parameter tool with no output schema, the description covers the core semantics and undo behavior adequately. However, it leaves the parameter under-specified, especially given that shape_ids is not marked required in the schema and the description does not clarify what happens with omitted or empty input.

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 only parameter is shape_ids, and schema description coverage is 0%, so the description must compensate. It only repeats 'given shape ids' without explaining ID source, requiredness, empty-array behavior, or ordering, adding essentially no meaning beyond the schema's array-of-strings definition.

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

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

The description states a precise compound action on a specific resource: copy the given shape ids to the clipboard and remove them from the current slide. This dual behavior inherently distinguishes document.cut from siblings like document.copy and document.remove_shape, which perform only one half of the 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?

The cut semantics imply when to use it: when shapes should be moved via the clipboard rather than merely copied or deleted. However, the description never explicitly names alternatives such as document.copy or document.remove_shape, nor does it state exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden. It usefully discloses one real behavioral trait, the refusal to empty the deck, but omits whether the deletion is undoable, whether the operation is atomic when some indices are invalid, and how the indices are based.

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

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

Two short sentences with the core action first and the constraint second. Nothing is wasted and every sentence earns its place.

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

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

For a destructive tool with no annotations and no output schema, the guardrail note is valuable but the definition stops short. It never states what the tool returns on success or failure and never defines the index semantics that determine correctness.

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 restates 'the given indices' without specifying 0-based indexing, accepted ordering, duplicate handling, or out-of-range behavior, leaving the sole parameter effectively 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: deletes slides at given indices. The plural 'indices' implies a batch operation, which differentiates it in spirit from the singular document.remove_slide, but the description never names that sibling or makes the distinction explicit.

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 by the plural indices and the emptiness guardrail. With both document.remove_slide and document.delete_slides in the sibling list, an agent gets no explicit guidance on which to pick when deleting one slide.

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 discloses two useful behaviors: duplication happens in place with a slight offset, and no clipboard state is touched. It omits mutation details such as whether new shape IDs are created, how slide_index affects placement, required permissions, and what is returned.

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 action and followed by the key differentiator. No filler or redundant restatement of the tool name.

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

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

For a mutation tool with no annotations and no output schema, the description covers the core action and clipboard side-effect but not the full contract. It leaves slide_index semantics, requiredness of shape_ids, and post-duplication state insufficiently specified.

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%: x_offset/y_offset already document defaults, and the description only hints at a 'slight offset' without adding range or format. It does clarify that shape_ids are the IDs to duplicate, but slide_index remains undocumented in both schema and description, so compensation for the coverage gap is only partial.

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 (Duplicate) and resource (given shape ids), plus scope (in place with slight offset). It also explicitly distinguishes itself from copy+paste by noting the absence of a clipboard side-effect.

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 positions this tool against copy+paste for the no-clipboard-side-effect case, giving a clear condition for choosing it. It stops short of naming when to prefer duplicate_slide or other alternatives, so it is not a full when/when-not matrix.

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 deliver one genuinely non-obvious behavioral fact: processing runs highest-index first so earlier insertions don't shift later targets. However, it omits where duplicates land relative to originals, whether the operation is undoable, and whether it mutates the document irreversibly.

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

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

Two sentences, zero waste, and the core action is front-loaded ahead of the secondary ordering detail. Nothing could be cut without losing 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 single-parameter tool with no annotations and no output schema, the description covers the main behavior but leaves the agent guessing about placement of new slides, index base, and return value. It is adequate rather than 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% for the single 'indices' array, so the description must compensate. Saying 'at the given indices' plus the ordering note implies indices refer to original positions, which is useful, but it never states zero- vs one-based indexing or whether order of the supplied list matters.

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 specific verb (Duplicate) plus resource (slides) with a noted batch scope ("at the given indices"), which separates it from the single-slide document.copy_slide/document.paste_slide pair. It never explicitly names those siblings, so differentiation is inferable 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?

No guidance on when to choose this over document.copy_slide + document.paste_slide or document.duplicate. The agent must infer that this tool is for batch duplication, and there is no mention of prerequisites (open document, valid index range) or 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?

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about not-found behavior, whether the id is required (it is, per the schema), or what the returned shape object contains. The only real disclosure is the cross-slide search scope, which is genuinely useful but insufficient for a no-annotation 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?

One short sentence, zero filler, with the scope qualifier placed where it matters. Nothing to trim and nothing redundant.

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

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

For a simple single-parameter read there is no output schema and no annotations, so the description should have covered the return value and the missing-id case; it covers only lookup scope. Adequate to invoke, incomplete for interpreting 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?

The description's "by id" maps onto the single shape_id parameter but adds no format, source, or constraints beyond the name. "Across all slides" does usefully state that no slide identifier is needed, partially compensating for 0% schema description 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?

Names a specific verb+resource ("look up a shape by id") and adds scope ("across all slides"), which separates it from document.list_shapes and slide-scoped lookups. It does not explicitly name a sibling alternative, but the read-only lookup intent is unambiguous.

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

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

Usage is only implied: the phrase "across all slides" tells the agent it does not need to supply slide context, which hints at when this beats list_shapes. There is no explicit when-to-use, when-not-to-use, or pointer to how a shape_id is obtained.

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. 'Get' implies a read operation and the default-current behavior is useful, but the description does not disclose return shape, error behavior for out-of-range indexes, or whether an active document is required.

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

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

The description is a single front-loaded sentence with no wasted words. The core operation and default behavior are communicated immediately.

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

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

For a simple single-parameter getter with no output schema, the description covers the basic invocation and default. It still leaves gaps around return values and index semantics, which are especially important given the absence of annotations and 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 has 0% description coverage for the single index parameter, so the description must compensate. It does explain that index selects a slide and that omitting it defaults to the current slide, but it does not clarify zero-based indexing or valid range despite the schema's minimum of 0.

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 ('Get a single slide') and adds scope ('by index'), making the operation clear. It does not explicitly distinguish itself from siblings like document.list_slides or document.get_state, but the purpose is still readily identifiable.

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?

'default: current' gives useful guidance for when the index is omitted, implying the tool is used to fetch either a specified slide or the active one. However, it offers no explicit when-to-use guidance versus alternatives such as document.list_slides or document.get_state.

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. 'Return' implies a non-mutating read, and it usefully discloses the payload includes undo/redo flags and a clipboard summary, but it says nothing about payload size, latency, or whether the snapshot is expensive to produce.

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 verb and resource, then the payload contents. No filler and no repetition of the tool name.

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

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

With no output schema, the description must convey return content, and it does so at a reasonable level of detail (slides, shapes, props, undo/redo flags, clipboard summary). Minor gap: no sense of nesting/shape of the returned structure or how large it may be.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema is trivially complete.

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

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

Specific verb ('Return') plus resource ('full document state') with the contents enumerated: slides, shapes, props, undo/redo flags, clipboard summary. This clearly separates it from partial-read siblings like document.list_slides or document.get_slide, though those siblings are never named explicitly.

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

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

The description only enumerates what comes back; it gives no when-to-use guidance, no indication of when a cheaper targeted read (document.get_slide, document.list_shapes, document.can_undo) would suffice, and no cost/size caveat for a whole-document snapshot.

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 disclosure burden. It usefully reveals non-obvious cascade behavior (existing groups expand to include the whole group) and the return value (new group_id), but says nothing about what happens with invalid/nonexistent shape ids, which slide is used when slide_index is omitted, or whether the operation is 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 short sentences, front-loaded with the core action, each adding real information (cascade rule, return value). No filler or restated 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?

A mutation tool with no annotations, no output schema, and low schema coverage needs more than this. It covers behavior and the return value but omits slide_index semantics and error conditions, leaving the agent to guess on two of three 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 only 33% (only 'name' is documented), so the description needs to compensate and does not. Neither shape_ids nor slide_index is explained — notably it never clarifies whether slide_index is optional or defaults to the active slide, which materially affects invocation.

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

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

States a specific verb ('wrap') and resource ('shape ids in a new logical Group on a slide'), which is unambiguous and clearly the inverse of sibling document.ungroup. It stops short of naming an alternative sibling explicitly.

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

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

Usage is implied by the verb and by the rule explaining that pre-grouped shapes pull in their whole group. There is no explicit statement of when to prefer this over alternatives (e.g., document.align_shapes or script.run) or any preconditions like an open document.

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 of behavioral disclosure. "List" implies a read-only, non-destructive operation, but the description does not explicitly state that, nor does it cover permissions, side effects, error behavior, or return characteristics.

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 extremely short, front-loaded, and free of filler. Every word contributes to identifying the operation and its default 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 list tool, the description is adequate to attempt a call, especially with the default noted. However, because there are no annotations and no output schema, the missing return-shape and parameter-indexing details leave 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% for the single optional index parameter. The description partially compensates by saying the shapes are on a slide and that the default is the current slide, which implies index selects a slide, but it does not clarify indexing base, valid range, or exact semantics.

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

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

The description gives a specific verb and resource: "List shapes on a slide," and adds the useful scope detail "default: current." It is clearly distinguishable from get_shape by plurality and from list_slides by resource, though it does not explicitly name 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?

The intended use is implied: enumerate shapes on a slide, with the current slide as the default target. There is no explicit guidance on when to prefer this over get_shape or other shape-related siblings, so usage is only minimally conveyed.

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 context. It discloses the returned fields (id, title, shape count), which is useful, but does not state that the operation is read-only, what permissions are needed, or whether it covers the current document only.

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 wasted wording. The parenthetical return fields are compact and useful.

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 listing tool with no annotations or output schema, the description is nearly complete: it states the scope and the key fields returned. A minor gap is that it does not explicitly say it applies to the current document.

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, so the baseline is 4. There is no parameter semantics to clarify, and the description does not introduce confusing parameter-like details.

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 ('List') and resource ('all slides in the document'), making the operation clear. It does not explicitly distinguish itself from siblings like document.get_slide or document.list_shapes, 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?

Usage is implied: call this when you need an inventory of slides. The description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance versus document.get_slide or document.list_shapes.

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 implies a mutation but never says whether the move is undoable, whether it requires selection/edit mode, what happens if the shape is off-canvas, or what is returned.

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 short, front-loaded sentence with no filler. Brevity is appropriate, though the space saved could have carried unit or return-value detail.

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 unannotated mutation tool with no output schema and zero per-parameter documentation, the definition is too thin. Key facts an agent needs — units, undo behavior, mutation effects, failure modes — are absent.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It explains dx/dy only as a coordinate delta without units (EMU? points? inches?) or sign conventions, and says nothing about what shape_id refers to or how to obtain one.

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 (translate) and resource (a shape), and clarifies that the motion is a delta in slide coordinates, which distinguishes it from resize_shape and set_property. It does not explicitly name a sibling, so no credit for sibling differentiation.

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

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

No guidance on when to use this versus resize_shape, set_property, or align_shapes, and no prerequisites or exclusions. The agent must infer selection from the tool name alone.

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

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

With no annotations, the description carries the behavioral burden and does so for key traits: every pasted shape receives a new id and is displaced by (offset, offset) pt so repeated pastes cascade. It omits edge behavior such as what happens when the clipboard is empty or holds non-shape data, and gives no indication of what the call 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 compact sentences, front-loaded with the action and followed by the non-obvious cascade behavior. Nothing is redundant or padded.

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 two-parameter mutation with no annotations and no output schema, the description covers action, target selection, and placement behavior. The main residual gap is return information (e.g., ids of newly pasted shapes) and error conditions, which no other field supplies.

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 50% (slide_index has no description), but the description compensates: it explains that offset is applied on both axes relative to the original and that the target slide can be the current one or an explicitly specified one. That is meaningful semantics beyond the bare schema fields.

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 ('Paste shapes from the clipboard') plus the target ('current or specified slide'). The explicit 'shapes' resource distinguishes it from the sibling document.paste_slide, which handles slides rather than shapes.

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 'from the clipboard' — an agent can infer it should follow document.copy/document.cut and that clipboard.peek can verify contents — but no alternative or when-not condition is stated explicitly (e.g., versus document.duplicate or paste_slide).

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 useful behavior — default placement at the last slide and one command per pasted slide so undo removes them cleanly — but omits what happens when the clipboard is empty, whether existing slides shift, and whether the paste is undoable as a group or individually.

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

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

Two sentences, front-loaded with the core action and its default, followed by a relevant undo note. No wasted wording.

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, no-output-schema tool, the description covers placement default and undo granularity adequately. Only the failure mode for an empty/incompatible clipboard 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 coverage is 0% for the single parameter, so the description must compensate. It does add the default ('last slide') and the positional meaning of 'after', but leaves index base (0- vs 1-based) and valid range unspecified.

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

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

Specific verb+resource: 'Paste slides from the slide-level clipboard', which distinguishes it from document.paste (generic clipboard paste) among the siblings. It does not explicitly name the alternative tool or contrast conditions, but the scope is unambiguous.

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

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

Usage is only implied: the mention of a 'slide-level clipboard' suggests document.copy_slide must have populated it first, and 'after after_index' implies inserting into an existing deck. No explicit when-to-use/when-not or prerequisites (e.g., empty-clipboard behavior) 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 supplied, so the description carries the full burden. It correctly discloses the key behavioral trait that only the most recent undone command is re-applied (not arbitrary history), but says nothing about what happens when the undo stack is empty, whether redo can be repeated, or whether history is per-document.

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; every word contributes to identifying the operation. Nothing is buried or repeated.

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 core action is covered, but the practically important edge case (calling it with nothing in the undo stack, and how to guard with document.can_undo) is absent. That is the one piece of information an agent actually needs beyond the name.

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 for the description to clarify; the baseline for a parameterless tool applies. The schema is trivially complete.

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 ('Redo') and a precise target ('the most recently undone command'), which is more specific than the bare name and clearly distinguishes it from the general-purpose mutation tools in the sibling list. It does not explicitly contrast itself with document.undo, relying on the well-known undo/redo pairing instead.

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 agent must infer that this follows a document.undo call. There is no explicit 'use after undo' instruction and no mention of document.can_undo as the way to check whether a redo is possible, even though that sibling exists right next to it.

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

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

No annotations are supplied, so the description carries the entire behavioral burden, yet it only says 'delete'. It does not disclose that removal is destructive, whether the operation is undoable via document.undo, what happens to a shape's text or group membership, or how it behaves when the id is unknown — all critical for an irreversible mutation.

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; every word earns its place. Brevity is not the problem here — the sentence is arguably too terse rather than bloated.

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 tool the description covers the call mechanics, but with no annotations and no output schema it should at minimum say whether deletion is reversible and what a failure response looks like. Adequate to invoke, thin on consequences.

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%, but with only one required string parameter the surface is small. The phrase 'by id' does establish that shape_id is an identifier rather than a name or index, but it omits format and where to obtain a valid id (document.list_shapes / document.get_shape).

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?

"Delete a shape by id" names a specific verb (delete) and resource (shape) plus the selection key, which distinguishes it from slide-level deletion siblings like document.remove_slide and document.delete_slides and from document.add_shape. It stops short of explicitly naming those alternatives, so it is clear but not fully differentiated.

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

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

The description gives no guidance on when to use this versus alternatives such as document.delete_slides for multiple deletions, document.ungroup for grouped shapes, or document.undo for reverting. No prerequisites, no exclusions, no conditions 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?

With no annotations, the description carries the full burden, and it does disclose one meaningful behavior: the operation is refused if the deck would become empty. It does not say what error/signal is returned on refusal, whether deletion is reversible (undo exists as a sibling), or how index interacts with ordering from document.list_slides.

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

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

Two tight sentences with the operation front-loaded and the guard clause second; nothing is wasted or buried.

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?

Given a mutation tool with no annotations and no output schema, the description covers the key safety constraint but omits success behavior, error signaling, and index-ordering semantics. It is minimally adequate rather than complete for an unannotated destructive operation.

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 single 'index' property has no description, so the description's 'by index' is doing real work by naming the selector. However, it doesn't clarify zero-based indexing or the valid range (the schema's minimum: 0 only implies the lower bound), leaving a gap an agent could hit.

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 a slide') plus the selector ('by index'), which is unambiguous. It does not distinguish itself from the sibling document.delete_slides (plural/bulk), so an agent must infer the singular-vs-batch split from the names alone.

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 singular 'slide' suggests a single-target operation versus delete_slides, but no explicit when-to-use or when-not-to-use guidance is given. The empty-deck refusal hints at a precondition but is framed as behavior, not as routing 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?

No annotations exist, so the description carries the full burden. It usefully discloses that forward/backward move each shape only one step (vs. front/back which jump to an extreme), but is silent on what happens when shape_ids is omitted (all shapes vs. current selection), whether the operation is undoable, and any auth/state 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?

Three short sentences, front-loaded with the core action and z-order clarification, then the value semantics. 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 no-annotation mutation tool with an undocumented scope of effect, the description is thin: the default behavior when `shape_ids`/`slide_index` are absent, whether the move is undoable, and the result of the operation are all unaddressed. No output schema exists to offload return-value explanation either.

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 document all three parameters. It gives good semantic detail for the required `to` enum (the one-step behavior of forward/backward), but `shape_ids` and `slide_index` are completely undocumented in both schema and description, leaving two of three parameters unexplained.

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

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

States a specific verb and resource ("Reorder shapes on a slide") and disambiguates with "(z-order)", which separates it from move_shape and reorder_slide. It does not explicitly name those siblings, but the parenthetical does most of the differentiation work.

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?

Explains the semantics of the `to` values, which implies when each option applies, but never says when to use this tool versus move_shape, align_shapes, or reorder_slide. No prerequisites or when-not conditions are given.

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

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

With no annotations at all, the description carries the full behavioral burden. It does disclose the important 0-based convention, but omits that this is a mutation with side effects, whether it is undoable, and what happens on out-of-range indices or when src == dst.

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

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

A single dense sentence with the operation and the index convention front-loaded, no filler. It borders on under-specification rather than verbosity, but every word present 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?

A 2-parameter mutation tool with no annotations and no output schema needs to explain side effects, index bounds and dst semantics. The description covers only the index base, leaving an agent likely to guess wrong about the resulting position.

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% (bare integers), so the description must compensate; it does add the 0-based convention and the src->dst direction. However it leaves the critical ambiguity unresolved: whether dst is the final index after removal or the insertion point before removal, which changes results when src < dst.

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 ('Move slide') with the two indices involved, which is enough to separate it from list_slides, add_slide, remove_slide and reorder_shapes. It does not explicitly name which sibling handles the adjacent operation (e.g. copy/duplicate), but the purpose is unambiguous.

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

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

No guidance on when to use this versus alternatives such as document.list_slides + document.add_slide/remove_slide, nor any prerequisite (e.g. slide must exist, index bounds). The verb 'move' only weakly implies the reordering context.

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 states the coordinate system but does not disclose whether x/y/w/h are optional, how missing values are handled, permission requirements, bounds/units, error behavior, or whether the operation 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?

A single front-loaded sentence with no wasted words. It efficiently communicates the core operation and coordinate context.

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 five parameters where only shape_id is required, the description is too sparse. It leaves important gaps around optional parameters, coordinate origin, units, and expected effects.

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 identifies the four geometry parameters as forming a box in slide coordinates, which adds meaning beyond the bare schema, but it does not explain shape_id, units, constraints, or the fact that only shape_id is required.

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: "Set a shape's box (x, y, w, h) in slide coordinates." It is clear what operation is performed and which geometry fields are involved, though it does not explicitly distinguish itself from siblings like document.move_shape or document.align_shapes.

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 guidance on when to use this tool instead of alternatives such as document.move_shape, document.align_shapes, or document.set_property. Usage is only implied by the operation 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about error behavior for unsupported keys, whether value types are validated, whether the change is undoable, or whether it applies immediately. For a mutation tool with zero annotation coverage this is a substantial 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?

One sentence, front-loaded with the verb and resource, with examples packed parenthetically. Nothing is wasted and nothing needs reordering.

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?

Three required parameters, no annotations, no output schema, and a polymorphic value field — this tool needs more than a single line. Missing are the accepted key vocabulary beyond five examples, the expected value type per key, failure behavior, and whether the call is transactional or undoable.

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 only partially: it exemplifies valid `key` values, but `shape_id` is unexplained and `value` is an untyped free-form field whose required type per key (string vs number vs boolean vs color object) is never clarified. That typing question is exactly what determines a correct call.

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 (set) and resource (a single property on a shape) and enumerates example keys (fill, stroke, font_size, bold, color), which makes the operation concrete. It does not distinguish itself from overlapping siblings like document.set_text or document.set_rotation, leaving the agent to infer whether text styling belongs here or there.

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 example keys imply what the tool is for, but there is no explicit guidance on when to prefer this over document.set_text or document.set_slide_background, nor on any preconditions (e.g. shape must exist, key must be supported). Usage is inferable 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 provided, the description carries the full burden and does meaningful work: it states storage on props.rotation, renderer behavior via a Qt transform around the shape center, and OOXML persistence. It does not cover error handling, clamping, or return behavior, but it is substantially more transparent than a bare mutation description.

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 front-loaded with the operation and range, followed by implementation and persistence details. It is compact and every sentence adds some behavioral context, though the OOXML/Qt details are somewhat implementation-heavy.

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 two-parameter mutation with no output schema and no annotations, the description covers operation, units, range, internal storage, rendering, and persistence. It lacks edge-case behavior such as out-of-range normalization or errors, but is otherwise sufficient.

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 gives useful meaning for degrees: clockwise and 0..360. shape_id is not described, but it is self-evident from the name and required string type.

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 and resource: set a shape's rotation in degrees. It clearly distinguishes rotation from move/resize siblings by naming the exact operation and units. It stops short of explicitly differentiating from set_property, which could also set rotation.

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 operation name and the 0..360 clockwise range. However, it does not say when to use this instead of set_property or what happens for values outside the stated range.

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 says almost nothing: not whether the background replaces or layers over an existing one, not whether a theme/master background is overridden, and not whether the operation is undoable. Only the fact that a mutation happens 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 with no waste. It is efficient, but that efficiency comes at the cost of omitted detail rather than through disciplined editing.

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 unannotated, output-schema-less mutation tool with an undocumented required target concept, the description is too thin. An agent cannot tell from it whether 'index' is required in practice to identify the slide or what happens when it is omitted.

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%: 'color' already has an example in the schema, so 'hex color' adds little, and the 'index' parameter is unexplained in both the schema and the description. The description does not resolve the key ambiguity of how the target slide is selected.

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 ('Set') and resource ('a slide's background') plus the value type (hex color). It is distinguishable from siblings like set_slide_title or set_slide_transition, though it doesn't clarify which slide is targeted.

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 indication of when to use this versus other slide-styling setters, no prerequisites, and no statement about whether the change is per-slide or deck-wide. Usage is only inferable from the name.

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

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

No annotations, so the description carries the full burden. It does disclose two non-obvious behaviors: the empty-string clearing convention and that changes round-trip through the <p:notesSlides> node on save. It does not state what happens if the slide has no notes slide yet, whether the operation is idempotent, or any error behavior for an out-of-range index.

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, no filler. Minor noise: double space after the parenthetical and RST-style double-backtick markup around the XML node name, which is a bit technical for a tool description.

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

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

For a simple 2-parameter mutation with no annotations and no output schema, this covers the core action, the clearing case, and persistence behavior. It falls short on the 'index' parameter's exact semantics and on what the tool does when the target slide has no notes slide, which are the two gaps an agent would actually trip over.

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 only annotates one parameter partially: 'notes' accepts an empty string to clear. The 'index' parameter is never explained beyond the ambiguous '(default: current)', so an agent cannot tell whether it is a zero-based slide index, a slide ID, or something else.

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

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

States a specific verb and resource: 'Set or clear the speaker notes on a slide', which clearly distinguishes it from set_text, set_slide_title, and other content-mutating siblings. The parenthetical '(default: current)' is slightly vague about which slide is targeted when index is omitted, but the core purpose is unmistakable.

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

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

Explicitly says how to clear notes ('Pass an empty string to clear'), which is real usage guidance for one branch. However, it gives no guidance on when to use this versus set_text or other text-mutating siblings, no 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation but does not disclose permission requirements, reversibility, whether the title placeholder must exist, or what happens to existing title formatting.

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

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

The description is a single front-loaded sentence with no filler. It is very terse, but under-specification is better assessed under completeness rather than conciseness.

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 0% schema description coverage, the description is too incomplete. It leaves both parameters partially or wholly undocumented and says nothing about the effects or return behavior of renaming.

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

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

Schema description coverage is 0% for two parameters. The description only clarifies that omitting index defaults to the current slide; it does not explain the title parameter beyond the implied rename action, nor whether index is zero-based or one-based.

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 says "Rename a slide," which is a specific verb and resource and distinguishes this tool from broad siblings like document.set_text or document.set_property. It does not explicitly name the required title parameter, but the operation is still clear.

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 "(default: current)" gives one targeting rule for the optional index, but there is no guidance on when to use this tool versus siblings such as document.set_text or document.set_property. No alternatives or exclusions are mentioned.

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 and does disclose real behavior: the operation is a mutation that 'round-trips through the <p:transition> node on save' (i.e. persistence semantics), an empty string clears the transition, and duration is in seconds defaulting to 0. It stops short of error behavior for invalid kinds or out-of-range indexes.

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?

Four short, front-loaded sentences with backticked parameter names and no filler. The one redundancy is the duration sentence duplicating the schema's 'Seconds. Default 0.' almost verbatim, which costs a little.

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 3-parameter mutation with no annotations and no output schema, the description covers what the tool does, how to clear, units, scope, and save-time persistence — enough to call it correctly. The remaining gap is the ambiguous index handling and unstated failure modes.

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% (only duration is documented in-schema), so the description must compensate. It explains 'kind' thoroughly with concrete PowerPoint names and the empty-string clearing convention, and '(default: current)' partially explains 'index', though it never states indexing base (0- vs 1-based) or explicit default.

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

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

States a specific verb pair (set/clear) and a specific resource (slide transition), and immediately clarifies the default scope (current slide). No sibling tool touches transitions, so it is trivially distinguishable from set_slide_background / set_slide_notes / set_slide_title.

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: '(default: current)' hints at targeting the current slide unless an index is given, and '"" to clear' tells you how to remove a transition. There is no explicit when-to-use/when-not framing or mention of preconditions (e.g. whether the slide must exist or be selected).

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 disclosure burden. "Replace" implies mutation but the description doesn't state that existing text is overwritten, whether it requires selection/permissions, or what the response looks like.

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. It is efficient but borders on under-specification given the tool's complexity.

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 mutation tool with no annotations, no output schema, and 0% parameter coverage leaves significant gaps an agent would need to guess at, such as overwrite semantics and error 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?

Two parameters with 0% schema description coverage. The phrase "text on a text/auto-shape" hints that shape_id locates the shape and text is the payload, but neither parameter is documented, so the description barely compensates for the coverage gap.

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

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

States a specific verb ("Replace") and resource ("text on a text/auto-shape"), distinguishing it from document.set_property and document.add_shape. It is clear about what the tool does, though it doesn't explicitly name a sibling alternative.

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 indication of when to use this versus document.set_property or document.add_shape, no prerequisites, and no exclusions. Usage must be inferred entirely from the name.

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

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

No annotations exist, so the description carries the full burden, and it discloses almost nothing: it does not say the operation mutates the document, what happens when the undo stack is empty (error vs no-op), how deep the undo history goes, or whether undo can itself be undone via redo. 'Most recent' is the one real behavioral detail, implying a single step rather than a multi-step revert.

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 short, front-loaded sentence with no filler. It is appropriately sized for a no-argument history operation.

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 call mechanics are trivial (no params, no output schema), so the description is nearly sufficient to invoke. What is missing is the surrounding context an agent needs to use it safely: failure behavior on an empty stack and the relationship to document.can_undo and document.redo.

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 for the description to disambiguate. Baseline 4 applies for a no-arg tool.

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

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

A specific verb (undo) plus the exact scope (the most recent command), so the agent knows this is a single-step history rollback rather than a bulk revert. It does not, however, distinguish itself from the very close siblings document.redo and document.can_undo, whose purposes sit right next to 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?

There is no guidance on when to call this versus document.redo, document.can_undo, or manual re-application of changes, and no mention of checking undoability first. Usage is only inferable from the verb 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the group removal is reversible (e.g., via undo), what happens to the child shapes, what error occurs if the shape is not in a group, or whether the operation modifies the document state. For a mutation tool with zero annotations, this is a significant 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 short sentences with zero waste. The core action is front-loaded, and the parameter guidance follows immediately. Every sentence earns its place.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema coverage, the description is minimally adequate. It explains the action and parameter alternatives but omits critical behavioral context such as what happens to child shapes, reversibility, and error 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 compensate. It does so well by explaining that group_id and shape_id are alternatives and that shape_id can be any shape from the group. It does not clarify whether exactly one parameter is required or what happens if both or neither are provided, leaving some ambiguity despite the 0% coverage baseline.

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: 'Remove a Group wrapper.' It clearly identifies the operation as the inverse of grouping, distinguishing it from siblings like document.group_shapes. However, it doesn't explicitly name sibling tools or clarify whether the wrapper removal preserves child shapes.

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 'Pass either group_id or shape_id' and the statement that shape_id can be any shape from the group. There is no explicit when-to-use vs. when-not-to-use guidance, no mention of prerequisites (e.g., the shape must currently belong to a group), and no named alternatives.

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 valuable work disclosing the sandbox (imports, eval/exec and dunder access blocked) and the bound environment (document, slides, undo_stack, rt helpers). It does not say that execution mutates the live document, whether changes are undoable, how errors surface, or what is returned.

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 action, then the environment, then the restrictions. No filler and nothing repeated from the schema.

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

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

For a single-parameter execute tool with no output schema and no annotations, the description covers the environment but omits return values, mutation/undo semantics, and error behavior. Those gaps are material for an agent deciding whether to invoke an arbitrary-code-execution 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 coverage is 0% for the single `code` parameter, so the description must compensate, and it largely does: it names the in-scope bindings and the blocked constructs, which is exactly the information needed to write valid code. It stops short of stating that `code` is Python source text or how results are surfaced.

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

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

Specific verb and resource: 'Execute a Python string against the live Document' tells the agent exactly what happens. It is clearly distinct from the granular siblings (document.add_slide, document.set_text, etc.), but it never explicitly says it is the escape hatch for operations those tools don't cover.

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

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

No guidance on when to use this instead of the dozens of dedicated document.* tools, nor when to prefer script.sample. An agent must infer that this is the general-purpose scripting path; no exclusions, prerequisites or alternatives are named.

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 disclosure burden. It doesn't say whether the tool is read-only, whether it inserts content into the editor or merely returns text, or what the sample demonstrates (scripting API? syntax template?). "Return" hints at a read, but nothing is stated.

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. It is tersely efficient, though the brevity edges into under-specification rather than pure economy.

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?

Complexity is low (no parameters, no nested objects), which keeps the bar modest. But with no annotations and no output schema, the description should at least characterize the returned script — its language, what it demonstrates, or whether it is a template to copy — and it does not.

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 for the description to disambiguate; the baseline for a no-arg tool applies. The schema is trivially complete and closed (additionalProperties: false).

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 ("Return") and resource ("a sample script") plus its intended consumer (the script editor), so the agent knows this fetches an example script rather than executing one. It does not explicitly contrast with the sibling script.run, so the reader must infer the distinction.

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

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

There is no guidance on when to call this rather than script.run, nor on any prerequisites or follow-up steps. The phrase "for the script editor" implies a usage context but never states it as a rule.

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