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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/non-destructive profile is covered. The description adds that the operation is a thin wrapper over add_text_box, which usefully signals identical placement behavior, but it omits practical consequences: default placement may overlap existing elements, the call returns presumably a new element ID needed for later update_text/format_text, and nothing is overwritten.

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 waste, and the core action is front-loaded ahead of the sibling relationship. Nothing is repeated from the schema or title.

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

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

For a 10-parameter creation tool with no output schema, the description leaves the agent guessing about the returned element ID and whether sizing defaults collide with existing slide content. With annotations and 90% schema coverage doing much of the work, it is adequate but not sufficient for confident composition on a real slide.

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 90% with defaults documented for fontSize, topInches, leftInches, widthInches and heightInches, so the schema already carries parameter meaning. The description adds nothing beyond the schema, and fontFamily remains undocumented in both places — baseline 3 applies.

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

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

States a specific verb and resource (add a bullet list text box to a slide) and names the sibling generalization it wraps (add_text_box), so an agent can tell it apart from the generic text box tool. It stops short of stating the bullet-specific scope conditions (e.g., one level only, no nesting).

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

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

The phrase 'Convenience wrapper around add_text_box' implies when to choose it — when the content is a list of items rather than free text — but the agent has to infer that selection rule. There is no explicit when-not guidance (e.g., use add_text_box for headings or multi-paragraph body text).

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's marginal job is context. It adds the public-URL requirement and units, but doesn't disclose what the call returns (e.g., an element ID needed for later delete_element), layering/z-order behavior, or handling of invalid/non-image URLs.

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

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

A single front-loaded sentence with no filler; the operational essentials (source type, target, units) all earn their 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 7-param mutation with no output schema and sub-50% schema coverage, the description covers the core operation and units but omits return value, default placement semantics, and URL validity constraints 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 43%, with the four geometry params (topInches, leftInches, widthInches, heightInches) undocumented in the schema. The description partly compensates by stating position/size are in inches, but doesn't explain defaults, coordinate origin, or aspect ratio behavior.

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

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

Specific verb (insert) and resource (image) plus the source (publicly accessible URL) and target (a slide). It's clearly distinct from add_text_box/add_shape siblings by resource, though it doesn't explicitly name an alternative or boundary.

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

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

The constraint that the URL must be publicly accessible is stated, which is the key usage prerequisite, but there is no when-to-use vs. alternatives guidance (e.g., vs add_shape or replacing an existing element) and no note about failure behavior for private URLs.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is an additive, non-destructive write. The description adds that fill, outline, and text are optional, but says nothing about what is returned (e.g. the new element ID needed later by delete_element or update_text) or that defaults apply to position and size.

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

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

A single front-loaded sentence with no filler. The parenthetical shape list plus 'etc.' is mildly noisy but conveys the accepted value domain efficiently.

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 12-parameter creation tool with no output schema, the description covers the essential purpose and optional styling dimensions, while the schema carries per-parameter details at 92% coverage. Only the return value is unstated, a minor gap given the schema's completeness.

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 92%, so nearly every parameter is already documented in the schema; the baseline is 3. The description only enumerates a few shape types, which slightly supplements the schema's single example but adds little on sizing, colors, or text behavior.

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

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

States a specific verb (Add) and resource (shape) and enumerates concrete ShapeType values, so the agent knows exactly what will be created. It does not distinguish itself from siblings like add_text_box or add_image, which also place visual elements on a slide.

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: an agent can infer this is the tool for adding geometric shapes to a slide, but there is no explicit guidance on when to prefer it over add_text_box, add_image, or add_table, nor any stated prerequisites such as needing a valid slideId from list_slides.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's job is to add context, and it does add that layout/theme/notes are applied at creation time. It omits where the slide lands by default (append vs. insertionIndex) and says nothing about the result — no output schema exists, so the agent cannot tell whether a slide ID is returned for follow-up formatting calls.

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, and the core action leads. It is arguably too terse for an 8-parameter mutation tool, but there is no wasted phrasing to trim.

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 non-destructive mutation with full schema coverage and annotations, the description covers the main capability but leaves two agent-relevant gaps: default insertion position and what the call returns. With no output schema to fall back on, the return value gap matters for chaining into format_text or set_speaker_notes.

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

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

Schema coverage is 100%, so all 8 parameters including the layout and theme enums are documented in the schema itself. The description restates title/body/bullets/theme/notes at a high level and adds nothing about insertionIndex, presentationId format, or the bullets-overrides-body precedence beyond what the schema already says; baseline 3 applies.

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

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

States a specific verb+resource (add a slide) and enumerates what can be filled in on that slide. It distinguishes itself implicitly from element-level siblings like add_text_box or add_image, but never names a sibling or explicitly contrasts with create_deck_from_outline or duplicate_slide.

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 use this versus the ~20 alternatives, notably create_deck_from_outline (build a whole deck) or duplicate_slide (copy existing content). The reader must infer that this appends one new slide to an existing presentation, and nothing warns that content is placeholders rather than arbitrary 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety framing is covered. The description usefully adds that filling is optional and row-major, but omits key behavioral facts: whether data dimensions must match rows/columns, whether extra data is truncated or padded, and whether an element ID is returned for later 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?

A single front-loaded sentence with no waste; the optional-fill detail is placed immediately after the core action.

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

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

For a 9-parameter mutation with no output schema, the description is minimally adequate. The biggest gap is the rows/columns vs. data consistency contract, which an agent must know to call this correctly without a failed or malformed table.

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%, so the description must carry weight; it does explain the data parameter as a row-major 2D array of cell strings, which matches the schema's example. However, it never relates rows/columns to data (must they agree?) and says nothing about the four inch-based positioning parameters beyond their self-explanatory names and defaults.

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 ("Add a table to a slide") plus the optional data-fill behavior, which distinguishes it from the sibling element-creation tools (add_text_box, add_image, add_shape) by resource noun. It does not explicitly name those alternatives, so it stops short of the top mark.

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 add_shape/add_text_box, no prerequisites (e.g., needing a slideId from list_slides, which only appears in the schema), and no note on when to supply data versus leaving the table blank. Usage is only inferable from the sentence 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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is already covered. The description adds genuinely useful context that coordinates are in inches, but says nothing about placement origin, overflow/auto-fit behavior, or whether the box is appended alongside existing elements.

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

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

Three short sentences, front-loaded with the action and free of padding. The unit sentence is mildly redundant with the schema's 'Top, inches' descriptions, which costs it a point.

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

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

For a 15-parameter mutation tool with no output schema and minimal annotations, the description is thin: it omits defaults behavior, coordinate origin, and what happens to overlapping/existing elements. It is adequate to call the tool but leaves real gaps for an agent reasoning about layout.

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 80% and the schema already documents units, defaults, and the bulleted flag, so the baseline of 3 applies. The description's 'Coordinates are in inches' and 'bulleted=true' merely restate schema text rather than clarifying the 15 parameters (styling defaults, alignment semantics) further.

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 styled text box to a slide'), which is clearly separable from siblings like add_shape, add_image, and add_bullets. It does not explicitly contrast itself with add_bullets or add_shape, which is the only thing keeping it from a 5.

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

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

The only usage cue is the conditional 'Set bulleted=true to render the lines as a bullet list,' which is really a parameter behavior note rather than tool selection guidance. It never says when to prefer add_text_box over add_bullets/add_shape, nor whether the slide must be empty or already exist.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds that this is an escape hatch for raw API requests, but does not explain validation, atomicity, partial failure behavior, or authentication 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?

The description is three short, front-loaded sentences with no wasted text. The escape-hatch purpose and usage condition are stated 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 raw API escape hatch with fully covered parameters and existing destructive annotations, the description gives enough context to select and invoke the tool. A brief note on response or error behavior could improve completeness, but the API reference pointer covers much of the missing detail.

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

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

Schema coverage is 100%, so both parameters are already documented in the input schema. The description points users to the Slides API request reference and clarifies that requests are raw API payloads, but it does not add parameter-level meaning beyond the schema.

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

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

The description clearly identifies the tool as a raw Google Slides API batchUpdate escape hatch. It specifies the resource and operation, and explicitly distinguishes it from the other specialized tools when edits are not covered.

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

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

It gives clear usage guidance: use this for advanced edits not covered by the other tools. The alternative is the set of specialized sibling tools, though no specific siblings are named and no additional exclusions are provided.

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

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive, open-world write, and the description adds the bulk/atomic 'one call' framing. However, the layout defaults it cites are already stated verbatim in the schema's layout field, and it says nothing about repeat-invocation behavior (duplicate decks), permission requirements, or partial-failure semantics — notable for a batch 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?

Three short sentences, front-loaded with the action and scope, followed by default behavior and routing advice. No filler or 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 bulk creation tool with no output schema and 22 siblings, the description omits what the call returns (deck/presentation identifier or URL) — information an agent needs to actually 'refine with other tools'. Themes, fonts, and slide structure are adequately implied, but the handoff context is missing.

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

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

Schema description coverage is 100%, including the theme enum, layout enum, and nested slide fields, so the schema carries parameter meaning on its own. The description adds only the outline shape at a high level and repeats the layout default, so baseline 3 applies.

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

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

The description states a specific verb (create), a concrete resource (a themed Google Slides deck), and the input form (a structured outline), plus 'in one call' which separates it from the single-slide/single-element siblings like add_slide or create_presentation. An agent can tell exactly what this produces 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?

'Use this for most new decks, then refine with other tools' gives an explicit default recommendation and signals the follow-up pattern (bulk create, then granular edits). It stops short of naming which sibling to use for refinement or when to prefer create_presentation instead.

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

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

Annotations already declare readOnly=false, idempotent=false, destructive=false, so the mutation profile is covered. The description adds genuine value by disclosing the return payload (ID and URL), which matters because there is no output schema. It could still say that repeated calls create duplicate decks, but the non-idempotent hint covers that.

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

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

A single tightly written sentence with the create action and the return value both front-loaded. Every clause earns its place and nothing is 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 one-parameter creation tool with full annotations and no output schema, the description covers the action, the empty-deck semantics, and the return values. The only meaningful gap is routing guidance against the closest sibling, create_deck_from_outline.

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?

Only one parameter with 100% schema description coverage ('Presentation title', minLength 1), so the schema already carries the semantics. The description adds nothing about the title, which is acceptable at this coverage level but is the baseline, not a strength.

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 ('Create a new, empty Google Slides presentation') and adds the important qualifier 'empty', so the agent knows no slides are generated. It does not explicitly distinguish itself from the sibling create_deck_from_outline, which produces a populated deck.

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 use this versus alternatives such as create_deck_from_outline, nor any prerequisites (auth scope, drive location) or exclusions. The agent must infer the choice between an empty deck and an outline-generated deck from tool names alone.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is known. The description adds the scope of deletable element types and clarifies it does not delete slides, but does not discuss permissions, permanence beyond the destructive hint, or side effects. With annotations covering the safety signal, a 3 is appropriate.

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 operation and object types, followed by a sibling pointer. No redundant or filler text.

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

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

For a two-parameter destructive delete tool, annotations cover safety, the schema documents both required inputs, and the description identifies the object scope and the slide-deletion alternative. No output schema is needed; an agent has enough 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 100%; objectId is described as a page element object ID from get_slide, and presentationId as the ID from the Google Slides URL. The description's list of element types lightly contextualizes objectId but adds no format, source, or validation details beyond the schema. Baseline 3 fits.

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, 'Delete', and specific resources, 'shape, image, table or other page element', and explicitly distinguishes from delete_slide for whole slides. An agent can select it 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 routes whole-slide removal to delete_slide, which clearly implies this tool is for individual page elements. The condition for choosing the alternative is stated, not left to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered elsewhere. The description adds no behavioral context of its own: no irreversibility warning, no permission requirements, no effect on remaining slide indices or on the deck's minimum slide count.

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 waste; the '(page)' parenthetical earns its place as terminology disambiguation. There is little else to structure.

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 destructive tool with full schema coverage and clear annotations, the essentials are present. Still missing are the consequences an agent should know before deleting, such as whether deletion is reversible and any constraint on deleting the only remaining slide.

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

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

Schema description coverage is 100%, documenting both slideId (sourced from get_presentation or list_slides) and presentationId (from the Slides URL), so baseline 3 applies. The description adds nothing beyond that.

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') and clarifies the terminology with '(page)', which helps an agent map Slides API vocabulary. It does not, however, distinguish itself from the sibling delete_element, which could plausibly delete the same object.

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 use this versus delete_element, no prerequisites (e.g., what happens to the last slide in a deck), and no mention of how to obtain IDs beyond what the schema already says.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining that this creates a new slide alongside the original. It doesn't say whether the copy lands adjacent by default, whether notes/formatting/elements are copied, or what a caller gets back. Almost nothing beyond the name is disclosed.

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, front-loaded with the action and resource. Nothing is wasted, though the brevity is partly under-specification rather than discipline.

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 three-parameter mutation with no output schema, the description should at minimum state default placement and what is returned (presumably the new slide's ID, which the agent needs for follow-up calls). It covers the core action but leaves those operationally important details unstated.

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

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

Schema coverage is 100%, so the schema already defines all three parameters including the URL-based ID lookup and index bounds. The phrase 'moving the copy to an index' adds slight semantic nuance about what insertionIndex controls, but stops short of describing default placement behavior.

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

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

States a specific verb (duplicate) and resource (slide), which cleanly separates it from add_slide, move_slide, and reorder_slides. It doesn't explicitly name those siblings, but the verb alone tells an agent what the tool does.

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 duplicate versus adding a new slide or reordering existing ones, no prerequisites, and no mention of what happens when insertionIndex is omitted. The 'optionally' hints at a default placement but never states 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?

The description explicitly says it will 'write it to the local filesystem', which is an environment-modifying side effect, yet annotations declare readOnlyHint=true and destructiveHint=false. That is a direct conflict about whether the tool mutates anything, and the description also gives no detail on overwrite behavior if outputPath exists or on Drive authorization 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?

One sentence, no filler, with the output formats and the destination front-loaded. Nothing to trim.

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 tool with no output schema, the description covers what the tool produces (a PDF/PPTX file on disk) and where it comes from (Google Drive). What is missing is the return value (does it return the written path?) and overwrite behavior, which matters given the filesystem write.

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

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

Schema coverage is 67%: outputPath and presentationId are already documented in the schema, and format is constrained by an enum. The description's 'PDF or PPTX' merely restates that enum, so it adds no semantics beyond what structured fields already provide; baseline 3 applies.

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

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

States a specific verb (export), resource (the presentation), supported formats (PDF/PPTX), and the distinguishing side effect (writes to the local filesystem). That side effect clearly separates it from read-only siblings like get_presentation and from all the slide-mutation tools.

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

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

Usage is only implied: exporting is what you call when you need a file artifact. No when-to-use/when-not-to-use guidance, no mention of prerequisites such as Drive access or that the presentation must already exist, and no named alternative.

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

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

Annotations already declare a non-read-only but non-destructive mutation, so the safety profile is covered. The description adds real behavioral context by specifying zero-based UTF-16 offsets, which prevents an off-by-one/encoding error. It does not disclose whether properties not passed are left untouched or reset, or whether this requires the target to already contain text.

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, zero filler, with the operation and target front-loaded before the index convention and the prerequisite. Nothing needs trimming.

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 13-parameter mutation tool with no output schema and only partial annotation coverage needs more than this. Target type and index semantics are covered, but the agent is left unsure about merge-vs-replace behavior for omitted style properties and about what the response confirms.

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

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

With 13 parameters at 69% schema coverage, the description compensates where it matters most by defining the index semantics (zero-based UTF-16 offsets) that the schema only labels "Start index"/"End index". The remaining style flags (bold, italic, color, fontFamily) are self-explanatory and partly documented in the schema.

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

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

States a specific verb+resource: styling a character range inside a shape or text box. The scope (character range within an existing text-bearing element) is precise enough to act on. It does not name the adjacent siblings it differs from (update_text, replace_all_text), so an agent must infer that this is formatting-only rather than content replacement.

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

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

"Use get_slide to find text first" gives a concrete prerequisite and implied workflow, which is genuinely useful. However, it never says when to choose format_text instead of update_text or replace_all_text, nor whether format_text is the only way to change styling versus recreating text.

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

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

readOnlyHint=true already establishes the safety profile, and the description goes beyond it by disclosing the exact return shape — including speaker notes and element IDs — plus the existence of a raw passthrough mode. It stops short of noting error behavior for a missing or inaccessible presentation, which keeps it off a 5.

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

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

Two sentences, zero filler, with the returned payload front-loaded and the raw option as a trailing qualifier. 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?

With no output schema, the field enumeration is essential and present, and the raw toggle covers the escape hatch for callers needing full fidelity. Gaps remain around whether the summary is truncated (slide/text limits) and what an invalid ID returns.

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 both parameters are self-documenting, including where presentationId comes from in the URL. The description only restates the raw flag's effect already conveyed by the schema, adding no new syntax or default guidance, so baseline 3 applies.

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

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

States a specific verb and resource ('Get a compact summary of a presentation') and enumerates the payload (title, size, slides, object IDs, element IDs, text, speaker notes), which distinguishes it from the narrower get_slide. It never names the sibling it is not, so differentiation relies on the agent inferring from the field list.

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 only usage steer is 'Set raw=true for the full Google API response,' which is really a parameter hint rather than a when-to-use rule. Nothing says when to prefer this over list_slides or get_slide, or under what circumstances the compact form is insufficient.

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

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

readOnlyHint=true already declares the safety profile, so the description's job is to add return-side context — and it does, listing the exact element attributes and speaker notes the caller will receive despite there being no output schema. Nothing about failure behavior for a missing slide ID is covered, which keeps it from a 5.

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

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

Two sentences, zero filler, with the payload contents front-loaded before the workflow hint. 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 two-param read tool with fully documented schema and readOnlyHint, the description covers what is returned and when to call it. Only the error case (nonexistent slideId) and cross-presentation scoping are left unstated, which are minor 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 100% and both parameters (slideId, presentationId) are documented with sourcing hints (URL, get_presentation/list_slides). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get one slide') and enumerates exactly what comes back: element IDs, types, text, positions, sizes and speaker notes. It is clearly distinguishable from get_presentation and list_slides by the singular scope and element-level payload, though it never names those siblings explicitly.

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

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

'Use this before editing elements' gives a concrete workflow precondition that tells the agent when to reach for this tool. There is no when-not guidance or named alternative (e.g., list_slides for a skim), but the context is unambiguous.

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

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

readOnlyHint=true already establishes the safety profile, so the description's added value is the return shape – index, object ID, title and layout ID – which is genuinely useful because no output schema exists. It stops short of noting ordering guarantees, pagination, or behavior on an invalid presentationId.

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

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

A single front-loaded sentence that identifies the resource and then the returned fields in a compact clause. Nothing is wasted and nothing important is 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 simple one-parameter read tool with annotations covering safety and with no output schema, the description supplies the return-field list that would otherwise be missing. Only minor gaps remain – pagination, error behavior, and any ordering caveat.

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?

Only one parameter and schema description coverage is 100%, with the schema already explaining that presentationId comes from the Slides URL. The description adds nothing further about the parameter, which is acceptable given the schema does the work.

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 ('List') and resource ('every slide in a deck') and enumerates the fields returned (index, object ID, title, layout ID), so the agent knows exactly what it gets. It does not explicitly name a sibling such as get_slide for single-slide retrieval, but 'every slide' implicitly contrasts with it.

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

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

Usage is only implied: it is the tool for enumerating all slides, versus get_slide/get_presentation which are presumably narrower. There is no explicit statement of when to prefer this over get_presentation or get_slide, and no prerequisite or failure-condition guidance.

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

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

Annotations already declare a non-destructive write, so the safety profile is covered. The description adds nothing beyond that: it does not say whether other slides shift, what happens with an out-of-range index, or whether the presentation must be owned/editable.

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, though its brevity borders on under-specification given the ambiguity with reorder_slides.

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-required-parameter mutation tool with no output schema, the description omits index-boundary behavior and the relationship to the sibling reorder tool. The schema carries the parameter burden, but the behavioral context is incomplete.

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

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

Schema description coverage is 100%, and all three parameters are documented there, including the 'Target zero-based index' wording. The description's mention of 'zero-based index' merely repeats the schema, so baseline 3 applies.

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

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

"Move a slide to a new zero-based index" gives a specific verb and resource and covers the operation's effect. It does not distinguish itself from the sibling reorder_slides, which sounds like the same outcome, so an agent cannot tell them apart from the description 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?

There is no statement of when to use this tool versus reorder_slides, no prerequisites, and no exclusions. The agent is left to infer the choice between two plausibly overlapping slide-ordering tools.

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

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

Annotations already declare write-but-not-destructive semantics, so the description's job is to add the nuance that matters: this is a full replacement requiring every slide ID exactly once. That duplicate-omission constraint is real behavioral value beyond the annotations. It stops short of saying what happens if an ID is missing or duplicated (error vs. silent drop).

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

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

Two sentences, no waste, with the whole-deck replacement constraint front-loaded before the ordering instruction. Nothing could be removed without losing meaning.

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

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

A two-parameter mutation tool with no output schema and clear annotations, so most of the burden is covered elsewhere. However, failure behavior (what happens on missing or duplicate IDs), and whether the prior order is recoverable, are left unstated for a full-replace 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 100%, and the schema already describes orderedSlideIds as 'All slide object IDs in the new order'. The description only adds the uniqueness constraint ('exactly once'), which is a modest gain over an otherwise complete schema; baseline 3 applies.

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

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

States a specific verb and resource (set slide order) plus the scope ('complete slide order'), which implicitly separates it from move_slide's incremental single-slide move. It never names that sibling explicitly, so the differentiation is inferred rather than stated.

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

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

'Set the complete slide order' implies this is the whole-deck reorder path, but there is no explicit when-to-use versus move_slide guidance and no statement of consequences for choosing the wrong one. Usage is implied rather than directed.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description's disclosure that the change spans the entire deck is genuinely useful scope information. However, it says nothing about whether speaker notes or non-text elements are affected, whether a count of replacements is returned, or whether the operation is easily 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 short sentence that front-loads the action and scope with zero filler. Nothing is redundant.

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

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

For a four-parameter mutation tool with a fully described schema and no output schema, the description covers the essential scope (whole deck) and intent. The remaining gap is what happens on success (replacement count, partial matches), which is minor but would help an agent verify the call.

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

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

Schema coverage is 100%, so findText, replaceText, matchCase, and presentationId are already documented in the schema with defaults and format hints. The description adds no meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('find and replace') and resource ('text across the whole deck'), and the phrase 'across the whole deck' implicitly separates it from the element-level update_text sibling. It stops short of explicitly naming that alternative, 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 'like Find & Replace in Slides' analogy and 'across the whole deck' imply this is the bulk-replace path, but there is no explicit when-to-use vs update_text or when-not guidance (e.g., single-element edits should use update_text instead).

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

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

Annotations already declare this is a write (readOnlyHint=false) but not destructive, and the description is consistent with that. It adds one useful scope signal — only solid colors, not gradients or images — but says nothing about whether an existing background is overwritten, whether layout/master backgrounds are affected, 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?

A single front-loaded sentence with zero redundancy. The action and the resource appear immediately, and every word 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 low-complexity, 3-parameter mutation with full schema coverage and non-destructive annotations, the definition is adequate but bare: it omits overwrite behavior and return shape. Nothing needed to call it correctly is missing, but the agent gets no runtime expectations.

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

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

Schema description coverage is 100%, so all three parameters (presentationId, slideId, color with a hex example) are already documented in the schema. The description's only contribution is the word "solid," which mildly reinforces the color format; baseline 3 applies.

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

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

The description pairs a specific verb ("Set") with a specific resource ("a slide's background") and constrains the value type ("solid color"). It is unambiguous, though it never names a sibling or notes that no other tool touches backgrounds, so differentiation is only implicit.

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 use this versus the other slide-mutation tools (move_slide, delete_slide, batch_update), and no mention that background is a presentation-wide-affecting, per-slide property. The agent must infer usage entirely from the name.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is known. The word "Replace" is consistent with that and implies prior notes are overwritten, but the description does not say whether existing notes are lost irreversibly, whether it works on slides with no notes yet, or whether the presentation must be writable.

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

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

A single front-loaded sentence with zero waste. It is arguably under-specified rather than bloated, which the other dimensions already capture.

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 three-parameter mutation with no output schema, the definition is only minimally sufficient: annotations cover the safety signal and the schema covers inputs, but the description says nothing about the replace semantics (full overwrite vs. merge) or 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 description coverage is 100% and each parameter is documented (including where to find presentationId and slideId). The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ("Replace a slide's speaker notes"), which is unambiguous about what the tool does. There are no sibling tools that touch speaker notes, so no differentiation is needed, but it also gives no scope detail (per-slide only, whole-notes replacement vs. append).

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 use this versus alternatives, nor any prerequisites such as needing an existing slide ID. The agent must infer everything from the schema's parameter descriptions.

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

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

The annotations already declare this as a non-read-only, destructive operation. The description adds important scope by specifying that ALL text inside the shape or text box is replaced, which helps an agent understand the destructive extent.

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

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

Two short sentences, front-loaded with the core action and followed by the key prerequisite. 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?

Given the simple operation, full schema coverage, and destructive annotation, the description is nearly complete for correct invocation. Minor gaps remain around formatting preservation and sibling-tool selection, but not enough to block correct use.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only reiterates that objectId comes from get_slide and adds no new meaning beyond the schema for presentationId or text.

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

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

The description clearly states a specific action and scope: replacing all text inside a shape or text box. It is distinguishable from formatting or slide-level tools, but it does not explicitly distinguish itself from sibling replace_all_text.

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 provides a useful prerequisite by saying to get the object ID from get_slide. However, it gives no guidance on when to use this versus replace_all_text, format_text, add_text_box, or other sibling tools.

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