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

With no annotations, the description carries the full behavioral burden and only partially meets it. It does disclose useful behavior (aspect-ratio preservation when w or h is omitted) but says nothing about whether the image is embedded or linked, what happens with an out-of-range index or unreachable URL, whether existing content is affected, or 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?

Front-loaded one-line summary followed by a compact Args block; every line adds meaning. The docstring formatting is slightly verbose for a tool description, but nothing is padded or 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 6-parameter mutation tool with zero annotations and no output schema, the argument semantics are complete but the operational context is not. An agent still cannot tell what the tool returns, whether the slide must pre-exist, or how errors surface.

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 fully compensates: index is zero-based, source is a path or http(s) URL, x/y/w/h are in inches, x/y are left/top, and w/h are optional with aspect-ratio coupling. Units and the mutual-exclusion rule are exactly the semantics the schema lacks.

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 first line gives a specific verb and resource ('Insert an image') plus the two accepted source types (local path or http(s) URL), which is enough to distinguish it from add_text_box and add_slide. It stops short of naming a sibling alternative or stating which presentation/slide context it operates on.

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

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

There is no when-to-use or when-not-to-use guidance: nothing says the slide must already exist, how 'index' relates to list_slides, or whether open_presentation must be called first. The agent must infer the whole call sequence from the sibling list.

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 present, the description carries the full burden, and it does disclose two useful behaviors: the layout fallback chain ('Title and Content' then 'Blank') and the append-when-index-omitted default. It says nothing about what happens on an out-of-range index, whether the operation is persisted immediately, or what the call returns, which are meaningful gaps for a mutation tool.

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

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

The purpose sentence is front-loaded and the Args block is compact and scannable. Every line earns its place; only the raw docstring formatting slightly detracts from readability.

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

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

For a simple two-parameter tool with no output schema and no annotations, the definition covers both inputs and their default behavior adequately. The remaining gap is the implicit requirement of an active presentation and the absence of any return-value or error context.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: both parameters are explained with their defaults and the semantics of omission. It does not say what values layout_name accepts beyond the two defaults, which leaves an agent guessing at valid layout names.

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 opens with a specific verb and resource: 'Add a new slide to the current presentation.' That distinguishes it from delete_slide, move_slide, and set_slide_text. It does not explicitly differentiate itself from duplicate_slide, which is the closest sibling an agent could confuse it with, so it falls short of a 5.

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

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

Usage is only implied by the tool's purpose; there is no explicit statement of when to choose this over duplicate_slide for copying an existing slide, nor any prerequisite (e.g., that a presentation must already be open). An agent can infer the use case, but the definition provides no 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?

With no annotations provided, the description carries the full behavioral burden. It doesn't disclose whether the presentation must first be opened, whether the change is persisted automatically or requires save_presentation, what happens on an invalid slide index, or what the tool returns. For a mutation tool, 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?

One sentence of summary front-loads the units and action, followed by a compact argument list where every line adds information. There is no redundancy or 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 six-parameter mutation tool with no annotations and no output schema, the parameter documentation is solid but the surrounding context is thin. An agent still lacks knowledge of prerequisites (open presentation), persistence semantics, and error behavior, though the core invocation is fully 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 description coverage is 0%, so the description must compensate, and it does well: it documents all six parameters with units ('in inches'), the zero-based indexing convention, and the newline convention for paragraphs. It lacks valid-range or default guidance, but the core meaning of every parameter is supplied.

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 opens with a specific verb and resource: 'Add a text box to a slide.' An agent can easily distinguish this from sibling tools like add_image or set_slide_text. It stops short of explicitly naming how it relates to those siblings, but the core action 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?

The description implies usage context (adding a text box to a specific slide) but never states when to use this versus set_slide_text or replace_text. There are no prerequisites mentioned, such as needing an open presentation, and no exclusions or alternative routing.

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

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

With no annotations, the description carries the full burden. It does disclose useful behavior: the path is where the deck will be saved 'later' (so nothing is written on create) and the default is a blank 16:9 deck. It says nothing about overwrite behavior if a file already exists at path, permission or template-validation failures, or what happens to a previously current presentation.

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

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

Front-loaded with the action and the state change, followed by a compact Args block. Every sentence carries information; 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 create tool with zero annotations and no output schema, the essentials (what is created, its default form, and both optional inputs) are covered. Missing state-transition details — what happens to the prior current presentation and the returned identity of the new one — leave a real gap for a plugin-style tool where subsequent calls depend on the current deck.

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 supply all meaning, and it does explain both parameters reasonably: path as the eventual save location and template_path as a .pptx/.potx base. It still omits constraints an agent needs, such as whether the path's directory must exist or whether an existing file is overwritten.

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 PowerPoint presentation') plus a meaningful side effect ('make it the current one'). It implicitly distinguishes itself from open_presentation by being about new decks, but never names the sibling, so an agent must infer the 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?

There is no explicit when-to-use guidance and no mention of alternatives such as open_presentation for existing files. The 'current one' phrasing hints this tool changes session state, but the agent is left to infer that starting a new deck is the selection criterion.

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 supplied, the description carries the full behavioral burden. It implies a destructive mutation but never states that the deletion is permanent/irreversible, that indices of subsequent slides shift down, whether a save is required, or what happens on 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?

Two short lines with the purpose front-loaded and the parameter note immediately after; nothing is wasted. The 'Args:' docstring formatting is slightly mechanical but harmless.

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 destructive tool with no annotations and no output schema, the definition covers the core call correctly but omits irreversibility, index-shift side effects, and post-delete save requirements. Those are the details an agent most needs before invoking a delete.

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% — the schema only gives 'type: integer, title: Index' with no description. The description compensates by explaining that the value is a zero-based index of the slide to delete, which is exactly the disambiguation an agent needs (off-by-one errors are the main risk here).

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 precise verb+resource ('Delete a slide') and names the scope ('from the current presentation'), which lets an agent distinguish it from add_slide, duplicate_slide, and move_slide. It stops short of explicitly contrasting with those siblings, so it lands just under 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?

There is no when-to-use or when-not-to-use guidance, no mention of alternatives, and no prerequisites such as needing an open presentation or saving afterward. The only context is the implied one that a slide exists at the given index.

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 what content is copied and that omission of new_index appends the copy, but it does not say whether the source slide is unmodified, whether inserting mid-deck shifts subsequent slides, or what identifies the new slide afterward.

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

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

The purpose sentence is front-loaded and free of filler, and the per-argument notes are terse. The docstring-style Args formatting is slightly formal for a tool description but costs nothing in readability.

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

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

For a two-parameter mutation with no annotations and no output schema, the definition covers the mechanics of the call adequately, but an agent still lacks the post-condition (where the duplicate lands, what happens to the source) needed to chain calls confidently.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: both parameters are defined in prose (zero-based index, optional zero-based target position, append default). It omits bounds behavior for out-of-range or negative indices, which is the main remaining gap.

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

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

Names a specific verb and resource ("Duplicate a slide") and enumerates what is carried over (shapes, background, images), which distinguishes it from add_slide (blank creation) and move_slide (reordering). It stops short of explicitly naming those siblings, so the 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?

The args block implies usage via new_index omission (append to end), giving a hint about the default workflow, but there is no explicit when-to-use-this-vs-add_slide guidance and no stated preconditions such as an open presentation or valid index 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?

No annotations exist, so the description carries the full burden, and it does substantial work by enumerating exactly what is returned: shape id, name, type, placeholder status, position and size in inches, plus text and image metadata. It stops short of stating that the call is non-mutating and says nothing about out-of-range index 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 return payload is stated up front, followed by a tight Args block, with no filler. The shape-attribute sentence is dense but every element listed is genuinely informative for an inspect tool.

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 and no annotations, the description compensates well by describing the return contents in detail for a one-parameter read tool. The remaining gap is operational: no mention of error behavior for invalid indices or the link to list_slides for discovering indices.

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 schema only labels the field 'Index', so the description carries the meaning itself with 'Zero-based index of the slide' and an explicit Args block. That fully specifies the single parameter's semantics, though it omits valid range and how indices are discovered.

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 ('Return detailed information about one slide') and the 'one slide' scope implicitly distinguishes it from list_slides. It is clear what the tool does, but it never names a sibling tool or explicitly contrasts itself with list_slides.

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

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

There is no explicit when-to-use guidance, no stated alternatives, and no prerequisites. An agent must infer that this is the read/inspect counterpart to list_slides, and nothing tells it how to obtain a valid index or what to do when inspection of many slides is needed.

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 usefully discloses the return payload (index, layout name, title, shape count, text preview), which signals a non-destructive read, but it never explicitly states read-only behavior, whether very large decks are paginated or truncated, or how the text preview is shortened.

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 action and followed by the exact fields returned. Nothing is redundant and every phrase adds information an agent would use.

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, no annotations, and no output schema, the description does the necessary work of enumerating the returned fields, which substitutes for an output schema. The remaining gap is behavior on large presentations (truncation, preview length limits), which an agent may care about but is minor for a simple lister.

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 no parameter meaning to convey and the baseline of 4 applies. The description correctly does not invent arguments.

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 ('List all slides') scoped to the current presentation, and names the metadata returned for each slide. An agent can immediately distinguish this bulk-listing tool from the single-slide sibling inspect_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: the word 'List' plus 'all slides' suggests a survey/overview step, and the per-slide summary fields hint at a cheap pre-scan before calling inspect_slide. However, there is no explicit when-to-use or when-not-to-use guidance, and no instruction such as 'use inspect_slide for full details of 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?

No annotations are supplied, so the description carries the full behavioral burden and largely drops it. It does not say whether the move is persisted to disk or only in memory, whether it requires an open presentation, what happens on out-of-range indices, or whether indices shift after removal.

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 text is short and front-loaded, with the purpose stated before the Args block. The Args listing is functional rather than wasteful, though the docstring-style formatting is slightly verbose for a two-parameter tool.

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 mutation tool with no annotations and no output schema, the definition covers the minimum: what it does and what the parameters mean. It is missing the behavioral context an agent needs to call it safely, notably persistence, error behavior on invalid indices, and index-shift semantics.

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% (only bare titles 'From Index'/'To Index'), so the description must compensate, and it does add the key fact that both indices are zero-based and which one is the source versus destination. However, it omits the critical ambiguity for a move operation: whether to_index is interpreted before or after the slide is removed from its original position.

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 opens with a specific verb+resource: 'Move a slide to a new position.' That is unambiguous and distinguishable from siblings like add_slide, duplicate_slide, and delete_slide. It stops short of naming how it differs from neighboring reordering operations, but the purpose is 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?

There is no when-to-use guidance, no prerequisites (e.g., that a presentation must be open), and no mention of alternatives such as duplicate_slide followed by delete_slide. Usage is only implied by the verb 'Move'.

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 discloses the state change ('make it the current presentation') but says nothing about what happens to the previously open presentation and any unsaved changes, nor about error behavior for invalid paths or non-.pptx files.

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

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

Two short, front-loaded sentences; the primary purpose comes first and the Args block is minimal. Nothing is padded, though the Args block adds nearly no 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 this is close to adequate, and there is no output schema to explain. However, the absence of annotations means the description should cover state side effects and failure modes, which it largely omits.

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, but its 'path' text merely restates the parameter name. It gives no guidance on absolute vs. relative paths, expected extension, or behavior on a wrong-format path.

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 an existing .pptx file') and adds the state effect ('make it the current presentation'). The word 'existing' implicitly separates it from create_presentation, though no sibling is named.

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: open a file that already exists rather than creating one. There is no explicit when-to-use, no mention of what to do if the file is missing or already open, and no routing to create_presentation for new decks.

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 for a mutating tool, and it omits key traits: whether all occurrences or only the first are replaced, whether replacement is case-sensitive, whether it is reversible, and whether a count of replacements is returned. The scope wording is also ambiguous about what the default None actually means (all slides vs. current slide), leaving an agent guessing at the most consequential side effect.

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

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

Front-loaded with the one-line purpose, followed by a compact Args block that is easy to scan. The formatting is Clean, though the 'Args:' docstring style duplicates what the schema already names.

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

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

This is an unannotated mutation tool with no output schema and zero schema coverage, so the description should explain result behavior and matching semantics; it does neither. An agent cannot tell whether the operation is idempotent, whether it reports how many replacements were made, or how it interacts with formatting runs in the slide text.

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 has to carry all parameter meaning, and it does define all three fields reasonably ('find' must be non-empty, 'replace' is the replacement, 'scope' takes None/"all"/an index). It falls short on the type-mixing and default null semantics of scope, and gives no hint about literal vs. regex matching for find.

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 ('Replace exact text in the current presentation'), which is enough to distinguish this from create/open/save siblings. It does not, however, distinguish it from near-neighbors like set_slide_text or add_text_box, which also write text into slides.

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

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

There is no when-to-use guidance and no named alternative; an agent must infer on its own whether to call replace_text or set_slide_text for an edit. The only contextual hint is the 'current presentation' scoping phrase, which implicitly rules out cross-file operation.

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 of behavioral disclosure. It does not say what happens if the destination path already exists (overwrite? error?), whether the presentation becomes bound to the new path afterward, or what permissions are needed for the write.

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 prose. The 'Args:' block restates the parameter that the schema already names, which is mildly redundant but not harmful given the schema lacks any 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 one-parameter tool this covers the basic action and the parameter's meaning. It falls short on the write-safety details (overwrite behavior, post-save state) that matter most for an agent choosing and invoking a file-mutating tool with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'path' parameter. It does add meaning by specifying this is the destination path for the .pptx file, but omits whether the extension is required or auto-appended, whether directories must exist, and relative vs absolute path handling.

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 ('Save the current presentation to a new path'), which separates it conceptually from the sibling save_presentation. It does not explicitly name save_presentation as the in-place alternative, so sibling differentiation is only implied by the word 'new'.

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

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

There is no explicit when-to-use guidance and no exclusions. The critical choice between save_presentation (in-place save) and save_as (save to a new path) is left for the agent to infer from the word 'new', and no prerequisites 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?

No annotations are supplied, so the description carries the full behavioral burden, and it only establishes that this is a write that targets the existing path. It does not disclose what happens for an untitled/never-saved presentation, whether prior file contents are overwritten or backed up, whether an open document is required, or what the call reports 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?

A single front-loaded sentence with the verb first and zero filler. Nothing is repeated from the title and no sentence fails to earn 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 zero-parameter, no-output-schema mutation tool, the description is adequate for identification but thin on operational context. The important edge case in this sibling set — an unsaved presentation with no current path — is left entirely unaddressed, and there is no hint of failure 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?

The tool takes zero parameters, so the schema leaves nothing to clarify and the baseline applies. The description adds no parameter meaning because there is none to add; it also does not explain that the save target is derived from implicit session state rather than any argument.

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 ('Save the current presentation') plus a scope qualifier ('to its current path'), which implicitly separates it from the sibling save_as. It stops short of naming save_as directly, so the distinction relies on the agent inferring that 'current path' means no new destination.

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

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

Usage is implied rather than stated: the phrase 'to its current path' suggests an in-place save rather than a save-as-new-file, which is the relevant fork against the save_as sibling. It never explicitly says when to prefer save_as, nor does it state the prerequisite that a presentation must already be open and have a path.

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 real behavior — that a bare string writes to the slide title, and that an object maps named targets to values — but it never states that existing text is overwritten, whether formatting survives, or how out-of-range indexes or unknown target names fail.

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

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

Purpose is front-loaded in one sentence, followed by a compact Args block that carries all the real information. No filler sentences; the only minor cost is the docstring formatting, which is functional rather than wasted.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the parameter story is complete but the behavioral story is thin — nothing about overwrite semantics, side effects on formatting, or what the call returns. An agent could call it correctly but not predict its 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%, yet the description compensates well: 'index' is stated as zero-based, and 'content' is explained as either a title string or a target map with an enumerated list of valid targets ('title', 'subtitle', 'body', 'content', placeholder index as string, or shape name) and value forms (strings or lists of paragraphs). Only the distinction between 'body' and 'content' targets and the failure mode for invalid targets remains unstated.

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

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

The opening line names a specific verb and resource ('Set the text of a slide'), so an agent immediately knows this mutates slide text content. It does not, however, distinguish itself from the sibling 'replace_text' or 'add_text_box', leaving the agent to infer the boundary from name 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 guidance on when to choose this tool over 'replace_text' or 'add_text_box', no prerequisites (does the presentation need to be open?), and no exclusions. Usage is only implied by the verb 'Set'.

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