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

The description discloses one lock, one backup, atomic save, stale-anchor refusal, and result.changed mapping. These behavioral details go well beyond the readOnlyHint: false annotation and give the agent an accurate model of what happens during execution.

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 dense but every sentence contributes: core behavior, DSL format, op list, safety constraints, and routing to standalone tools. It is front-loaded with the most important information and contains 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?

Given the complexity of a batch editor with pack-specific ops and 0% schema coverage, the description is remarkably complete. It covers the operation model, failure behavior, backup behavior, required atomicity, and single-edit alternatives. The presence of an output schema covers return-value details.

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 schema description coverage at 0%, the description carries the full burden and does so admirably. It explains the edit structure, anchor addressing, valid op names, atomic/backup semantics, and result.changed, adding substantial meaning beyond the bare 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 opens with 'Batch editor' and immediately conveys the tool's function: applying many edits atomically to a presentation. It lists the supported ops and explicitly distinguishes itself from creation tools, making its scope unmistakable.

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

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

It explicitly states when to use this tool ('needs two or more edits') and when to prefer standalone tools, naming each alternative. It also warns that atomic must stay True and that no partial-apply mode exists, giving clear operational 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?

The description discloses overwrite refusal, the backup rotation behavior into .ks4p-backups, undoability via manage_backups, and the guarantee that the source file is never modified. These details go far beyond the readOnlyHint=false annotation and describe important side effects.

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

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

Three sentences deliver the core purpose, the key alternative, and all critical behavioral caveats without fluff. The primary action is front-loaded, and every sentence adds necessary 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?

The description covers purpose, routing, overwrite semantics, backup/undo behavior, and source safety. With an output schema present, no return-value detail is needed; an agent has enough context to invoke this tool 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 description coverage is 0%, so the description must compensate. It explains dest_path and overwrite behavior explicitly, and file_path is inferable as the source deck. This adds meaning beyond the bare 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 states it copies a deck byte-for-byte and immediately contrasts with create_snapshot, which names a DTG-stamped copy. This makes the tool's purpose and distinction from its sibling obvious.

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 an explicit use case ('before heavy edits') and names the alternative tool (create_snapshot) with the criterion for choosing this one: an explicit dest_path rather than an auto-generated stamp. This is clear 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?

Annotations only state readOnlyHint=false, so the description carries the burden of behavioral detail. It discloses non-obvious behaviors: DTG replacement instead of stacking, numeric suffixes on collisions, no auto-pruning, manage_backups never touching snapshots, and the source file not being modified. These go well beyond the annotations and add significant safety-relevant context.

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

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

The description is front-loaded with the primary purpose and then packs multiple distinct rules into a compact block. Every sentence carries information, though the density makes it slightly harder to parse. It is appropriately sized for the tool's complexity.

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

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

The main behavior and safety properties are well covered, and since an output schema exists, return values need not be described. However, the dest_dir parameter's meaning and default behavior are absent, which is a noticeable gap. An agent could still call the tool correctly, but not with full confidence about where snapshots land.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the file_path role and the optional short label, but it never mentions the dest_dir parameter at all. One of three parameters remains semantically unexplained, so the description only partially compensates for the empty 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 opens with a specific verb and resource: 'Save a DTG-stamped permanent copy' and an exact naming format. It also distinguishes itself from siblings by explaining that snapshots are permanent keepers that 'manage_backups never touches,' so an agent can tell it apart from rotation/backup tools without opening schemas.

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

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

The description explicitly advises 'Take one before any large or risky editing pass,' giving a clear when-to-use condition. It also contrasts snapshots with automatic prev/anchor slots and manage_backups, which routes an agent away from alternatives. It does not enumerate every sibling exclusion, but the context is strong.

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 goes far beyond the single readOnlyHint:false annotation by disclosing garbage-collection behavior, neutered jump links, atomic saving with two-slot backup, and the unsafe 'UNSAVED until live_save' live-editing caveat. This is exactly the behavioral risk context an agent needs for a destructive 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?

Three dense sentences cover the core action, side effects, alternatives, backup semantics, and live-editing behavior without fluff. The most critical destructive effects are front-loaded, and every clause adds operational value.

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

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

For a destructive tool with complex side effects, the description is complete: it covers what gets removed, how to avoid permanent deletion, backup behavior, locked-file behavior, and the live-saving implication. With an output schema present, the lack of return-value detail is not a gap.

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

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

Schema description coverage is 0%, so the description must compensate. It defines the slide parameter's accepted forms ('0-based index or {"slide_id": N}'), explains backup=False behavior, and clarifies live mode values. This turns potentially ambiguous schema properties into actionable semantics.

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

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

The description opens with the specific action 'Delete a slide' and names the resource, then elaborates the destructive scope: notes, charts, embeddings, comments, custom-show references, section membership, and jump links. This clearly distinguishes it from sibling slide operations like insert_slide, duplicate_slide, and reorder_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?

It explicitly says to prefer set_slide_hidden when the slide might come back, giving a concrete alternative for a common scenario. The live parameter values 'auto', 'force', and 'off' also explain when each mode applies, including the locked-file case.

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 already marks it read-only, and the description reinforces this with 'WITHOUT mutating anything.' It also adds valuable behavioral context: output is PASTE-SAFE by default, verbose=True exposes paths, and it is the only place the update-check runs.

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 dense but every sentence contributes: what it checks, optional file behavior, output safety, when to run it, and the boundary with validate. The key purpose is front-loaded in the first sentence.

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 output schema exists, the description need not enumerate return fields. It covers the diagnostic scope, safety profile, parameter effects, invocation timing, and the sibling tool boundary, making it complete for an agent deciding whether and how to call diagnose.

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 0% schema description coverage, the description carries full responsibility for explaining parameters. It clearly explains file_path enables file-level checks, and verbose=True adds sandbox roots, engine locations, and the full file path, which goes beyond the schema's bare types.

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 ('Self-check') and resource ('this environment and, optionally, one file'), and enumerates exactly what it reports. It also differentiates itself from the validate tool, so an agent can distinguish diagnose from a real PPT opens-clean check.

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 explicitly says 'Run it first when any tool refuses unexpectedly or an export engine seems missing,' and tells the agent that validate is the tool for the actual opens-clean check in PowerPoint. This gives clear when-to-use and when-not-to-use guidance.

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

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

The annotation only provides readOnlyHint=false, leaving the description to carry behavioral context. It excellently discloses idempotency ('already-disabled packs are reported, not errors'), the lack of file changes ('Nothing about the presentation files changes'), session-scoped impact, and output behavior ('Reports the approx token cost removed and the remaining active surface'). No contradiction with annotations.

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 five compact sentences, each adding unique value: the action, parameter semantics, idempotency, side-effect clarification, and output. It is front-loaded with the core purpose and contains no filler.

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

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

For a one-parameter tool with an output schema present, the description fully covers the operation, parameter domain, important side-effect constraints, and expected report output. Nothing an agent needs to call it correctly 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?

Since the schema has 0% description coverage, the description must compensate. It does so by defining the parameter as pack names shared with enable_tools and allowing the special value 'everything'. It does not enumerate the actual pack names, but the pointer to enable_tools is sufficient.

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: 'Switch pack tools back off to shrink the tool surface'. It clearly identifies the tool's scope, mentions the lite core always staying on, and references enable_tools as the counterpart, so an agent can distinguish it from siblings without ambiguity.

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 explicitly ties itself to enable_tools ('Takes the same pack names as enable_tools, or "everything"'), making the alternative obvious, and the context of shrinking the tool surface implies when to use it. However, it does not give an explicit 'use this when...' or when-not rule, so it stops short of a 5.

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

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

Beyond the single readOnlyHint=false annotation, the description discloses deeply relevant behavior: cloned vs shared content, GUID regeneration to avoid corruption, atomic saving with two-slot backup, and backup=False skipping rotation. This is exactly the kind of operational context an agent needs.

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 dense but purposeful: copy semantics come first, then parameter details, then the pack prerequisite and save behavior. No filler is present; the design-pack sentence is slightly tangential but still relevant to the tool's capability.

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 complex mutation tool with an empty slide schema and minimal annotations, the description covers all non-obvious aspects: deep-copy behavior, parameter formats, destructive-corruption warning, backup behavior, and a capability prerequisite. Given the existing output schema, nothing essential 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?

With 0% schema description coverage, the description carries the full burden and succeeds. It explains slide's index/object form, position's 0-based meaning and default, and backup's rotation-skip effect. file_path is not explicitly described, but it is the most self-explanatory parameter.

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

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

The description opens with 'Deep-copy a slide', a specific verb and resource, then clarifies the exact scope: notes, charts with embedded workbooks, and embeddings are cloned, while layout/media stay shared and GUIDs are regenerated. This clearly distinguishes the tool from insert_slide, delete_slide, and reorder_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?

It gives concrete invocation guidance: slide can be a 0-based index or an object, position defaults to right after the original, and the design pack prerequisite for move/hide is stated. It does not explicitly name sibling alternatives or say when not to use this tool, so it stops short of full 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?

The description goes well beyond the minimal readOnlyHint annotation by disclosing side effects: the tool list grows, the client is notified to re-fetch, the operation is idempotent, it reports approximate token cost added and the active surface, and it can be reversed with disable_tools. This is rich behavioral context that annotations do not provide.

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 long, but the length is justified because it must enumerate seven distinct pack names and their contents plus legacy aliases. It is front-loaded with the core action and effect, then systematically lists each pack. Some internal parentheses are dense, but the structure is understandable and every sentence contributes useful 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?

Despite having only one simple parameter, the description provides a complete picture: what packs are available, what each contains, legacy name resolution, idempotency, side effects on the client, cost reporting, and how to reverse the operation. Nothing essential is missing for an agent to decide whether and how to call this tool.

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

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

Schema coverage is 0% and there are no enums, so the description carries the full burden of explaining the 'packs' parameter. It does this thoroughly by listing every valid pack name, including aliases for legacy names, and describing what each pack includes. This gives the agent concrete, actionable parameter values.

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

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

Description uses a specific verb ('Switch on') and resource ('optional tool packs'), and clearly distinguishes itself from disable_tools by naming the inverse. It enumerates exactly which packs exist and what each contains, so an agent can understand the tool's purpose without any ambiguity.

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 states this is for enabling optional tool packs mid-session, provides the full list of valid packs, and explicitly says disable_tools reverses the operation. It gives clear context for when to use the tool, though it doesn't elaborate on scenarios where it should not be used or contrast with other tools beyond disable_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 only provide readOnlyHint=true, and the description adds substantial behavior beyond that: regex is guarded against catastrophic backtracking, matching is against displayed text rather than raw XML, count is always the true total, pagination exposes an omitted count and next offset, and compact changes the shape. No contradictions with annotations.

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 dense but free of filler; every clause adds operational information, and the first sentence front-loads the core purpose. Subsequent details are grouped by related behavior (regex safety, XML escaping, pagination, compact output, tool routing).

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 an output schema present, return-value details are covered structurally. The description covers matching semantics, address format, pagination, and routing to sibling tools. Minor gap: scope and include_notes parameters are not described, but the overall behavior is sufficiently complete for an agent to call the tool correctly for common cases.

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

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

Schema description coverage is 0%, and the description compensates well by explaining regex=True, compact=True, limit/offset pagination via the 'page' block, and the meaning of budget. However, scope and include_notes are left unexplained, and file_path/query rely on context rather than explicit semantics, so it is not complete.

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

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

Opens with a specific verb+resource: 'Search the deck's text.' It then defines the exact return shape (slide index, shape id, paragraph index, and character offsets) and ties it to sibling tools by naming the addresses format_text and apply_edits consume. This clearly distinguishes find_text from get_text, which reads text in order.

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 usage: 'Use this to locate text; to read it in order, use get_text.' It also directs formatting-aware replacement to the graphics pack via enable_tools(packs=['graphics']), and notes apply_edits consumes its output, so an agent knows how this tool fits into a workflow.

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?

Discloses much more than readOnlyHint=false: the result is an ESTIMATE lacking font metrics, a shape that cannot fit at min_size reports still_overflowing, and saves are atomic with a two-slot backup where backup=False skips rotation. These traits (estimation caveat, failure reporting, atomic save semantics) materially affect how an agent trusts and invokes the tool, and none contradict the annotation.

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

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

Four dense sentences, each earning its place: purpose/mechanism, shape=None scope, estimation caveat with verification, and atomic/backup save behavior. The main purpose is front-loaded and there is no filler, even though the overall density is high.

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 mutating 5-parameter tool with an output schema present, the description covers the heuristic, the failure report (still_overflowing), scope selection, verification guidance, and save behavior. The only minor gaps (shape's type, slide reference convention) appear to be shared conventions across the sibling toolset, so little is left unknown for an agent making 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?

With 0% schema description coverage, the description carries the load and meaningfully clarifies min_size (floor in pt), shape (None means every overflowing shape), and backup (False skips rotation). file_path and slide are left implicit, and shape's type is unspecified, but the otherwise-ambiguous parameters are compensated for.

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 ('Shrink overflowing text to fit') and details the mechanism (largest uniform font scale via an average-glyph-width heuristic, rewriting run sizes, enabling normAutofit). This clearly separates it from sibling text tools like get_text, find_text, and search_and_replace, which read or edit text content rather than fit 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?

Provides clear when-to-use context: apply when text overflows, with shape=None extending the operation to every overflowing shape and min_size acting as the floor. It also advises a concrete verification step with export_slide_images due to the estimate heuristic. It stops short of naming sibling alternatives or stating when not to use it (e.g., when exact font metrics are required).

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=true, and the description reinforces this as a read-only 'facts' call. It adds useful behavioral context beyond annotations: it is a 'cheap first look', it returns deck-level metadata including notes presence, and it explicitly excludes rendering, validation, and PDF export. No contradiction with annotations.

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 compact and front-loaded: it states the tool's purpose first, then lists contents, then provides routing to alternatives. Every sentence earns its place, and the line breaks aid scanning.

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 output schema exists and the operation is read-only, the description covers the essential invocation context: what facts are returned, when to prefer this over siblings, and where related capabilities live. No critical information for selecting or calling this tool 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?

The schema has one parameter, file_path, with no description, and the description does not clarify its expected format, bounds, or access semantics. The parameter name is self-explanatory enough to avoid a score of 1, but with 0% schema description coverage, the description should have compensated and did not.

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

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

The description uses a specific verb and resource: 'Deck-level facts in one call' about a presentation, and enumerates exactly what is returned. It also draws clear lines against sibling tools like get_presentation_view and list_elements, so an agent can distinguish it without opening schemas.

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

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

The description explicitly states when to use this tool: 'The cheap first look before get_presentation_view.' It also names alternatives and exclusions: use list_elements for enumerating one kind of element, and use the assembly-export pack for rendering, validation, and PDF export.

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?

Beyond the readOnlyHint annotation, it discloses the output format ('slide headers with durable anchors', 'pipe tables', 'quoted blocks'), cell address conventions, budgeted rendering behavior, and how to enable graphics editing. This gives an agent a rich, accurate model of what will happen when the tool is called.

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 dense and front-loaded with the core purpose, followed by structured details for output, scope, detail, and pagination. It is slightly run-on, but every clause contributes meaningful behavior, so the length is justified despite some stylistic informality.

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

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

The description covers output shape, anchor semantics, all parameter families, budgeted behavior, and the relationship to editing workflows. An output schema exists for return values, and readOnlyHint handles safety, so nothing critical is left unexplained for an agent to invoke this tool 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?

With 0% schema description coverage, the description takes on full parameter documentation. It explains scope (None, index, slide_id object, or list), detail levels ('outline', 'text', 'full'), and limit/offset pagination semantics. The 1-based table addresses vs 0-based table-tool convention also clarifies offset-related behavior.

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

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

The description clearly identifies the tool as 'anchored markdown projection of a deck' and 'THE cheap way to read it', with a specific verb and resource. It conveys the core purpose of reading a presentation efficiently and distinguishes it from edit-oriented siblings by mentioning stable anchors for apply_edits.

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

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

The description provides strong usage context: scope values, detail modes, budgeted pagination, and how to feed anchors to apply_edits. It does not explicitly name alternative tools or state when not to use this tool, but the 'cheap way to read it' phrasing and detailed invocation options make intended usage clear.

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 states that "live='auto' edits the open PowerPoint copy" while the annotations declare readOnlyHint=true. This directly contradicts the read-only annotation and could mislead an agent into thinking the tool mutates the presentation. Despite other useful behavioral disclosures, the contradiction is severe.

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

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

The description is front-loaded with a clear summary, then adds shape-id relevance, slide addressing, pagination, and live-mode behavior. It is dense but each clause contributes useful information. A bit of restructuring or bullets could improve skimmability, but it is not bloated.

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

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

The description covers return fields, shape IDs, pagination, and sibling routing well, and an output schema is present. However, the live-mode 'edits' contradiction creates a significant completeness problem: an agent cannot safely infer whether this tool has side effects, which undermines the otherwise rich 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 carry parameter meaning. It explains slide input as '0-based index or {"slide_id": N}' and describes live modes in detail. It also gives contextual meaning to limit/offset through the budgeted page-block explanation, though file_path and exact numeric semantics are left implicit.

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 names the tool's purpose: retrieve detailed information about a single slide, listing concrete fields like durable slide_id, layout, hidden flag, notes presence, and shape geometry. It also distinguishes itself from siblings by explicitly pointing to get_presentation_view for all 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?

The description provides explicit routing: 'All slides: get_presentation_view.' It also explains the live parameter modes, locked-file behavior, and pagination via 'page' block with omitted count and next offset, giving the agent actionable guidance on when and how to use the tool.

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 says 'live=auto edits the open PowerPoint copy when the file is locked by it' and mentions UNSAVED changes until live_save, which directly contradicts the annotation readOnlyHint=true. This is a serious inconsistency: a read-only tool should not be editing the target file.

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 dense but purposeful: it front-loads the primary purpose and then systematically covers parameters and special behaviors. The main drawback is heavy jargon such as 'com pack' and 'assembly-export pack' that assumes domain knowledge, but there is no filler or repetition.

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

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

The description covers reading order, scoping, notes, paging, live behavior, and sibling routing, while the output schema handles return shape. It is nearly complete, but unexplained domain-specific terms and the unresolved contradiction with readOnlyHint prevent a perfect score.

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

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

Schema description coverage is 0%, so the description carries the full burden for parameter semantics. It covers scope (None, 0-based index, slide_id dict, list), include_notes, limit/offset paging behavior, and live values ('auto', 'force', 'off'). Only file_path is left implicit, but its meaning is self-evident.

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

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

The description clearly states the tool returns 'Plain text of the deck in reading order' and specifies the ordering rules without ambiguity. It also differentiates itself from siblings by pointing to get_presentation_view for edit anchors and noting that rendered-appearance checks live elsewhere.

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 explicitly describes scope options, include_notes behavior, limit/offset paging, and live mode semantics. It also provides an exclusion: for edit anchors, use get_presentation_view. This gives an agent clear, actionable guidance on when and how to invoke the tool.

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=true, so the description does not need to restate read-only behavior. It adds useful context about the two call modes (index vs full steps) and the content of the recipes. This goes beyond the annotations without contradicting them.

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

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

The description is front-loaded with the core purpose and then lists workflow names, which is necessary information. The list is long but each item is useful for selecting a task. Slightly verbose, but every sentence earns its place.

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

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

With an output schema present and readOnlyHint=true, the description provides everything needed to invoke the tool correctly: purpose, parameter semantics, and when to use it. There are no missing prerequisites or ambiguous behaviors that would prevent 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 0%, so the description must carry the parameter explanation. It does: no task returns the index, a task name returns full steps. It also enumerates many valid task names, effectively compensating for the lack of enums 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?

The description clearly states the tool provides step-by-step recipes for common jobs, each naming required packs and tool order. It lists many workflow names, giving a concrete sense of the resource covered. It is distinct from the sibling operation tools, though it lacks an explicit verb like 'retrieves' or 'returns'.

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

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

The description gives explicit invocation guidance: call with no task for the index, with a task name for full steps. It also advises reading the matching recipe before the first deck edit to prevent wrong-tool detours. However, it does not explicitly name alternative tools or conditions for using them, only implies them.

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 only mark readOnlyHint=false, yet the description discloses atomic saving, two-slot backup rotation, the backup=False opt-out, and the three live= modes with their locked-file behavior and UNSAVED caveat. This is substantial behavioral context well beyond the structured annotation.

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 dense and runs several clauses together, but each clause earns its place and the core action is front-loaded. A bit more separation of parameter definitions would improve readability without adding length.

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

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

Given the tool's complexity—layout selection, positional insertion, backup semantics, and live PowerPoint-lock handling—the description covers all essential behaviors and references the relevant discovery/list commands. With an output schema present, not detailing return values is acceptable.

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

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

Schema coverage is 0%, so the description must add parameter meaning, and it does: layout is disambiguated by name/index and how to list them, position is defined as 0-based final index with end default, backup is tied to rotation behavior, and live receives explicit auto/force/off semantics. Only file_path is left to obvious inference.

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?

Description opens with a specific verb and object ('Add a slide built from a layout') and distinguishes the operation from sibling slide tools like delete_slide, duplicate_slide, and reorder_slides. It also states the key mechanism (placeholder skeleton inheritance) so the agent understands what this insertion accomplishes beyond a generic add.

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 clearly positions this as the tool for adding a slide to an existing deck and points to list_elements kind='layouts' for discovering valid layout identifiers. It names create_presentation as the alternative for whole-deck creation, which is an explicit boundary, though it doesn't spell out exclusions for sibling slide-editing tools because those are implied by their names.

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 goes well beyond the readOnlyHint annotation by explaining exact output behavior: count is always accurate, paging reports held-back items and continuation offsets, compact mode reduces payload size, and scope handling is defined. There is no contradiction with annotations, and the read-only nature is consistent with the enumerator framing.

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 dense but every sentence earns its place: element kinds, return shape, paging/count behavior, compact mode, concrete use cases, and sibling routing. It is front-loaded with the core purpose and does not waste words on restating the name or schema.

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

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

For a six-parameter tool with no schema descriptions, the description covers nearly all invocation-relevant behavior and output semantics, and an output schema exists for the rest. It explains paging, scope, compact mode, and when to choose alternatives, making it complete enough for correct selection and invocation.

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 0% schema description coverage, the description compensates strongly: kind enumerates valid values, scope explains None/selector/list, limit/offset are described as explicit paging, and compact is tied to a smaller response format. Only file_path is left to inference, and the exact selector/list syntax for scope is not specified, so it is not quite perfect.

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 precise verb and resource: it is 'THE multiplex enumerator' that returns flat item lists for many presentation element kinds. It immediately enumerates the supported kinds and contrasts itself with sibling tools, so an agent can tell it apart from get_slide_info and get_presentation_view without opening schemas.

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

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

Usage is explicit: use it to find layout names for insert_slide and shape ids for editing, while get_slide_info and get_presentation_view are named as alternatives for other needs. It also tells the agent that editing tools live in the enable_tools packs, giving clear routing for follow-up actions.

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 goes beyond the readOnlyHint annotation by explaining the exact output contract (addresses accepted by set_hyperlink and remove_hyperlink), broken-target detection behavior, and explicit exclusions. It also states the file is never modified, reinforcing and clarifying the annotation without contradiction.

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 dense and front-loads the core purpose, with each sentence adding useful information such as output compatibility and exclusions. The final 'Read-only; the file is never modified' is slightly redundant with the readOnlyHint annotation but is brief and reinforces the safety guarantee.

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

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

The description covers scope semantics, included hyperlink types, target detection, output compatibility, exclusions, and read-only behavior. Given that an output schema exists, the lack of explicit return-value details is acceptable; the tool is well specified for correct invocation.

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 0% schema description coverage, the description partially compensates by explaining that 'scope' defaults to all slides, but it does not specify the expected format for scope values or clarify file_path beyond what the property name implies. The file_path parameter is self-evident, but the scope parameter remains underspecified for an agent that needs to pass a non-default value.

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

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

The description uses a specific verb ('list') and resource ('hyperlinks') and details exactly what is included: external URLs and jump-to-slide links on shapes and text runs, with broken-target detection. It also distinguishes itself from related concepts by explicitly excluding media playback controls, so an agent can tell it apart from sibling 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?

The description gives clear context for when to use the tool: to enumerate hyperlinks in scope, with a default of all slides, and notes that media playback controls should not be expected here. It also ties the output to set_hyperlink and remove_hyperlink, implying a coupled usage pattern, though it does not explicitly state when to prefer list_elements or get_text over this tool.

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 goes far beyond the single readOnlyHint=false annotation. It discloses that restore overwrites file_path, rotates current content into prev first to make restore undoable, validates the payload before atomic replacement, and that purge deletes only when dry_run=False. These are exactly the behavioral details an agent needs before invoking a destructive 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 description is dense and information-rich with no fluff, and it front-loads the backup-location concept before diving into actions. The single-paragraph semicolon-heavy structure is a little harder to parse than a bulleted breakdown, but 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?

Given the tool's complexity (6 parameters, destructive restore/purge modes), the description covers the critical details: undoability, validation, atomic replacement, dry-run defaults, and scoping. An output schema exists, so return values are not the description's job. It still leaves a few gaps around parameter interactions and edge cases, but it is fundamentally complete for safe invocation.

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 0% schema description coverage, the description carries the full burden and largely succeeds: it explains action values ('list', 'restore', 'purge'), source options ('prev', 'anchor', '.pptx path'), scope values ('orphans', 'slots'), and dry_run's default behavior. Some combinations remain implicit, such as how file_path and directory interact for list, but the essential parameter semantics are covered.

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's domain—managing automatic backups in .ks4p-backups/—and enumerates three concrete actions (list, restore, purge) with their effects. It is specific enough to understand what the tool does, though it never explicitly contrasts itself with the sibling create_snapshot, so it stops short of full differentiation.

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

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

The description gives clear usage context for each action: list for slots/orphans, restore for overwriting from a source, and purge for cleanup with dry-run semantics. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving the selection guidance implied rather than explicit.

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 goes well beyond the readOnlyHint annotation by disclosing important side effects: shape-level and run-level link removal, orphaned rel dropping, preservation of media playback affordances, atomic saves with two-slot backup, and the ability to skip backup rotation. This is rich, actionable behavioral detail.

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 compact and well-structured: purpose first, then target syntax, then side effects, then save behavior. Every clause adds necessary information without repetition or fluff.

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

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

The description provides enough detail to call the tool correctly for most cases: target format, scope, backup behavior, and side effects are all covered. It is slightly incomplete regarding the format of 'slide' and 'file_path', but given the output schema exists and sibling tools share conventions, this is a minor gap.

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 0% schema description coverage, the description must compensate for the empty parameter schema. It does explain 'target' in detail and 'backup' behavior, but it leaves 'file_path' and 'slide' undocumented, relying on convention and sibling tool context.

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

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

The description clearly states the action 'Remove hyperlinks' and specifies the two target forms: a shape id or a text range. It distinguishes itself from sibling tools like set_hyperlink and list_hyperlinks by focusing on removal with precise scope details.

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

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

The description gives clear context on when to use this tool: whenever hyperlinks need to be removed from either a shape or a specific run range. It thoroughly explains the target selection semantics, though it doesn't explicitly mention alternatives or when not to use it relative to siblings.

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 discloses key behaviors beyond the readOnlyHint annotation: atomic save with two-slot backup, backup=False skipping rotation, durable slide_ids surviving reordering while plain indices do not, and validation rejecting partial lists. This gives the agent important expectations about side effects and persistence.

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 compact and front-loaded with the core action. Every sentence adds either parameter semantics, an alternative tool, or behavioral side effects. No filler or repetition exists.

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

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

For a tool with three parameters, mutation semantics, and validation constraints, the description covers all essential aspects: required permutation, index semantics, backup behavior, and when to use a different tool. An output schema exists, so not describing the return value is acceptable.

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 0% schema description coverage, the description carries the full burden. It thoroughly explains the order parameter as a complete permutation of current 0-based indices, and explains backup semantics including the default rotation behavior. file_path is left to its name, but it is self-explanatory in context.

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: 'Rearrange the whole deck in one call.' It clearly communicates the scope (whole deck), the operation (reorder), and differentiates itself from one-slide moves by explicitly pointing to move_slide as the simpler tool for that case.

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

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

It states when to use this tool (reordering the entire deck) and provides an explicit alternative: 'For moving ONE slide, move_slide in the design pack is simpler.' It also specifies that partial lists are refused, so the agent knows a full permutation is required.

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?

Beyond readOnlyHint=false, it discloses atomic saves with two-slot backup, the formatting-preservation guarantee across fragmented runs, regex capture-group refusal in live mode, and skipped slide-number/date fields. These are concrete side-effect and edge-case behaviors an agent cannot infer from annotations.

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 about 60 words yet covers purpose, safety, regex/live modes, backup, and sibling routing. It is front-loaded with the core operation and every clause adds information.

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

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

For a write tool with output schema available, it covers most invocation-relevant behaviors: locking, backup, formatting, and exclusions. The main gap is the scope parameter, whose semantics are not clarified, which keeps it from being fully complete.

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

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

It adds meaningful behavior for regex (capture groups, refused live) and live (auto/force/off), and mentions the backup behavior. However, with 0% schema description coverage, the description still leaves several parameters unexplained, notably scope, and only implies match_case/include_notes from their 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 first clause, 'Deck-wide find and replace', names a specific verb and resource with clear scope, and the rest adds distinguishing traits (fragmented-run safety, SmartArt inclusion, excluded fields). It also points to set_table_cells and apply_edits as different tools, which separates it from nearby siblings.

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

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

The description gives explicit routing: bulk cell rewrites go to set_table_cells, batched edits go to apply_edits. It also defines the live parameter's three modes (auto/force/off) with the exact locked-file behavior, which tells an agent when to select each setting.

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?

Beyond the readOnlyHint=false annotation, the description discloses that the tool replaces existing links, requires exactly one destination, and saves atomically with two-slot backup rotation unless backup=False. This gives the agent a clear picture of the mutation and persistence behavior.

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

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

The description is dense but organized, front-loading the main purpose before parameter details. The phrase about delete_slide knowing how to neuter the structure is awkward, but every clause otherwise 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 7-parameter tool with no schema descriptions, this is nearly complete: target and destination forms are specified, backup semantics are explained, and an output schema exists. A short example or an explicit slide-parameter type would push it to fully complete.

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

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

With 0% schema description coverage, the description compensates well by defining target formats, explaining the url/to_slide destination split and mutual exclusivity, and clarifying tooltip and backup behavior. It does not explicitly define the slide parameter, but the overall parameter guidance is strong.

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 action, setting a hyperlink on a shape or text range, and clearly notes that it replaces any existing link. This distinguishes it from remove_hyperlink and other sibling tools without ambiguity.

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

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

The description gives clear context: when to target shapes versus text ranges, when to use an external URL versus an internal slide destination, and how navigation buttons pair with insert_shape. It does not explicitly name alternatives or say when not to use the tool, but the provided context is sufficient for most decisions.

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

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

With only readOnlyHint=false in annotations, the description carries the disclosure burden and meets it. It reveals atomic two-slot backup behavior and the backup=False opt-out, explains that live='auto' edits the open PowerPoint copy of a locked file, and notes that styling inherits from the layout rather than accepting direct formatting.

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

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

The description is front-loaded with purpose and each clause adds value, but the density and the cryptic 'Free text boxes: graphics pack' aside make it harder to parse than the best examples. It is information-dense rather than ambiguous, but not quite as clean.

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, 0%-coverage tool, this description covers nearly all non-obvious parameters and behaviors, including output-free return assumptions (output schema exists). The main gaps are the undefined 'file-mode' concept and the unspecified semantics of the 'slide' parameter (index vs ID), which an agent would need to infer.

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

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

Schema coverage is 0%, so the description is the only source of parameter meaning. It thoroughly documents placeholder (named strings, raw types, index int with file-mode restriction), text (newline/tab parsing), paragraphs (object shape with level 0..8), backup, and live. Only file_path and slide are left self-evident.

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 verb 'Fill' plus object 'layout placeholder' states exactly what the tool does, and the parenthetical about inherited styling adds precision. The closing 'Batches: apply_edits' creates a clear boundary against the sibling batch tool, so an agent can select it from the sibling 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 description explicitly names alternatives and conditions: 'Batches: apply_edits' tells the agent when to use a different tool, and 'Free text boxes: graphics pack' indicates a separate path for a different placeholder type. It also restricts idx/paragraphs to 'file-mode only', preventing misuse in other modes, though the 'graphics pack' reference is terse and not a listed sibling.

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