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

Annotations already mark destructiveHint=true, and the description substantially extends this with specifics: one lock, one backup, all locations resolved before mutation, stale anchors rejecting the whole batch, atomic-only behavior, and backup rotation semantics. It also clarifies that these ops edit existing content and do not insert new objects.

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 front-loaded with the core concept, and every sentence adds operational value: behavior, failure handling, constraints, and usage routing. There is minimal filler and no tautology.

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 output schema, the description fully covers what an agent needs: how to address edits, which ops are available, failure behavior, atomic and backup constraints, and when to choose standalone tools. Nothing critical is omitted.

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

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

With 0% schema description coverage, the description must compensate, and it does for the key parameters: edits format, anchor addressing, supported ops, atomic semantics, and backup behavior. It does not explicitly describe file_path or formally enumerate all allowed op values beyond the list, so it is strong but not exhaustive.

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: a batch editor for applying multiple edits to existing presentation content with one atomic save. It distinguishes itself from sibling standalone tools and creation tools, and lists the exact operations it supports. The agent can tell what this tool does without opening the schema.

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

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

Explicitly says when to use this tool: when a change needs two or more edits. It also names the standalone alternatives for single edits and notes that creation tools live in the packs. This gives clear guidance and exclusions.

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

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

While annotations indicate readOnlyHint=false (write operation) and destructiveHint=false (not destructive), the description goes far beyond these by detailing the overwrite refusal without overwrite=True, the backup rotation into .ks4p-backups, the undoability via manage_backups restore, and the explicit guarantee that the source file is never modified. These are valuable behavioral traits not captured in the 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 three sentences with no wasted words. It front-loads the core purpose, then provides key behavioral caveats and cross-references. Every sentence adds value, and the structure is logical: purpose → usage context → behavioral details.

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 copy tool with an output schema (not shown but present), the description covers all critical operational aspects: overwrite semantics, backup behavior, undo path, and source safety. It also cross-references manage_backups, which aids an agent in chaining tools. There is no missing information an agent would need to call it correctly.

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

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

The schema provides no descriptions (0% coverage), so the description must carry the burden. It explicitly explains dest_path ('explicit dest_path') and overwrite ('Refuses an existing dest_path unless overwrite=True'), and implicitly refers to file_path as 'source file'. While file_path is not directly named, the meaning is inferable from the context. The description adds significant meaning for two of the three parameters.

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's purpose: 'Copy a deck byte-for-byte'. It names the specific verb (copy) and resource (deck), and immediately differentiates from the sibling tool create_snapshot by explaining that this tool takes an explicit dest_path while create_snapshot names a DTG-stamped copy. This makes the tool's role unambiguous and distinguishes it from its closest alternative.

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

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

The description provides explicit guidance on when to use this tool ('e.g. to a working copy before heavy edits') and explicitly contrasts it with the alternative create_snapshot ('create_snapshot names a DTG-stamped copy for you; this tool takes an explicit dest_path'). It also explains the overwrite behavior and backup mechanism, giving the agent clear conditions for invocation and fallback options.

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 say readOnlyHint=false and destructiveHint=false; the description adds substantial behavior: leading-DTG replacement, collision handling via numeric suffix, no source modification, and no auto-pruning. 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?

Every sentence carries a distinct piece of information: naming, permanence, prune behavior, collision behavior, non-modification, and usage timing. The most important format detail is front-loaded.

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?

Covers naming, collision, retention, source safety, and a concrete usage trigger; an output schema exists so return values need no explanation. The only material omission is the meaning and effect of 'dest_dir', which prevents a perfect completeness 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%, and the description adds useful meaning for 'label' (optional short label) and file_path (the unmodified source), plus the naming convention. However, 'dest_dir' is never explained, leaving one of three parameters under-specified.

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

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

States a specific verb ('Save') and resource (a DTG-stamped permanent copy with a precise naming format), and clearly distinguishes snapshots from automatic prev/anchor slots and manage_backups. This is far more informative than the title 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?

Explicitly says to take a snapshot before any large or risky editing pass and explains that snapshots are permanent keepers whereas automatic slots rotate. It mentions manage_backups does not touch snapshots, but does not fully spell out when to choose snapshots over that sibling 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 state destructiveHint=true, but the description goes beyond that by detailing the exact side effects: garbage collection of notes, charts, embeddings, comments, custom-show references, section membership, and neutering jump links. It also explains atomic saves with two-slot backup and the behavior of backup=False and live modes. This adds substantial context not present in annotations, especially for a destructive tool where such transparency is critical. 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 concise but packed with essential information. It front-loads the primary action and side effects, then covers parameter specifics. Each sentence has purpose: the first covers delete semantics, the second covers the slide parameter, the third gives usage guidance, and the fourth covers backup and live behavior. No filler or redundancy.

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 (destructive, with side effects, multiple modes, output schema exists), the description is remarkably complete. It covers what is deleted, how to specify the target, backup behavior, live editing modes, and when to use an alternative. The output schema exists, so return values need no explanation. Nothing critical is missing 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?

Schema description coverage is 0%, so the description carries full responsibility for explaining parameters. It explains 'slide' format (0-based index or object with slide_id), 'backup' effect (skips rotation when False), and 'live' values and meanings. It does not explicitly explain 'file_path', but that is a common parameter and likely self-explanatory given the tool name. Thus, it compensates well for the schema's lack of descriptions.

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 ('Delete a slide' with garbage collection) and specifies the target via 'slide' parameter. It mentions the scope of cleanup (notes, charts, embeddings, etc.) which distinguishes it from simpler delete operations. The verb 'delete' plus the resource 'slide' is specific, and the mention of garbage collection sets it apart from potential sibling tools like 'duplicate_slide' or '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?

The description explicitly says 'Prefer set_slide_hidden (design pack) when it might come back', providing a clear alternative and the condition for using it. It also explains the 'live' parameter values ('auto', 'force', 'off') and their implications, giving the agent concrete guidance on when to use each. This is exemplary usage guidance for a destructive 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?

Beyond the readOnlyHint annotation, the description adds substantial behavioral detail: 'WITHOUT mutating anything' assures non-destructiveness; 'Output is PASTE-SAFE by default: no absolute paths...' explains a key default and its security benefit; 'verbose=True adds the sandbox roots, engine locations, and full file path' describes what changes with verbose; and 'Reports the update-check state; the only place the check runs' reveals a unique side effect. All of this materially enriches the annotation-only signal.

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. It front-loads the core function, then successively adds parameter details, safety properties, usage guidance, and a clear sibling contrast. No filler or repetition; the structure with 'With file_path:' and 'verbose=True' cleanly maps to the two parameters.

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 has an output schema (so return structure need not be described) and annotations cover read-only behavior, the description completes the picture: it covers purpose, both parameters, non-mutation, paste-safety, verbose effects, and the update-check side effect. It even tells the agent the one scenario where this tool is the designated first step and where a different tool is needed. There is no obvious missing information an agent would need to invoke it correctly.

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

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

With 0% schema description coverage, the description must carry full parameter meaning, and it does. For file_path it specifies the exact checks performed: 'existence, size, PowerPoint lock state, whether the package opens, and slide count.' For verbose it explains the added output ('sandbox roots, engine locations, and full file path'). This goes far beyond the bare schema names and defaults.

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

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

The description begins with a specific verb and resource: 'Self-check for this environment and, optionally, one file.' It enumerates concrete diagnostic outputs (engine availability, sandbox state, KS4P mode/policy, pack surface with token costs) and explicitly contrasts itself with the validate tool, which performs the real opens-clean check in PowerPoint. This clearly distinguishes it from sibling tools like get_presentation_info and get_presentation_view.

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 when-to-use instruction: 'Run it first when any tool refuses unexpectedly or an export engine seems missing.' It also names the alternative and its limitation: 'The validate tool (assembly-export pack) does the real opens-clean check in PowerPoint,' telling the agent when not to rely on this tool for that purpose. This is exactly the kind of routing guidance agents need.

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 idempotentHint annotation, the description explicitly states that already-disabled packs are reported rather than erroring. It also explains that presentation files are untouched and that the tool reports approximate token cost removed and remaining active surface, adding meaningful 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 front-loaded: purpose, accepted inputs, idempotence, side-effect scope, and output are each covered in separate efficient sentences with no filler.

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

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

For a single-parameter tool with only one required argument, the description combines with the annotations and output schema to cover everything needed: what the tool does, what values the parameter accepts, non-destructive behavior, idempotence, and what it reports.

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 input schema provides only a generic array of strings, but the description compensates by defining valid values: pack names from enable_tools or the special value 'everything.' It does not list example pack names, but enough meaning is added for correct invocation.

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

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

Description states a specific verb and resource: 'Switch pack tools back off to shrink the tool surface.' It clearly positions this as the inverse of enable_tools, and adds that the lite core always stays on, distinguishing it 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 names enable_tools as the counterpart and clarifies that it accepts the same pack names or 'everything.' It implies use for shrinking the tool surface, though it does not explicitly state when not to use it or name alternative tools beyond enable_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?

Beyond the sparse annotations, the description discloses deep-copy semantics, GUID regeneration with a corruption warning, layout/media sharing, atomic save, and two-slot backup rotation. These are exactly the behavioral traits an agent needs to anticipate side effects.

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

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

The paragraph is dense but efficient, front-loading the core action and parameter definitions. The enable_tools(packs=['design']) sentence is only loosely related to duplicating and adds slight noise, preventing a perfect score.

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 semantics, parameters, defaults, safety behavior, and backup handling; an output schema exists for return shape, and file_path is conventional. An agent has everything needed 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 compensates for slide, position, and backup by defining formats and defaults. file_path is left unexplained, but it is a conventional self-evident parameter and the rest are well-specified.

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 'Deep-copy a slide' and clarifies scope by enumerating what is cloned (notes, charts, embedded workbooks, embeddings) versus shared (layout/media), which clearly distinguishes it from sibling insert/reorder/delete operations.

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 practical invocation context (slide index forms, position default, backup switch) that an agent can act on. It does not explicitly name sibling alternatives or state when not to use this tool, but the behavior described is unambiguous enough for selection.

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

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

The description goes well beyond the annotations by disclosing that the client is notified to re-fetch the tool list, that the operation is idempotent, that it reports approximate token cost and active surface, and that disable_tools reverses it. This gives the agent a clear model of side effects and reversibility.

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 first sentence is front-loaded and clear, and the pack catalog is long but necessary because the schema provides no parameter descriptions or enums. The structure is organized by pack name and capabilities, and every sentence provides useful information, though the overall length is substantial.

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 single parameter, the presence of an output schema, and annotations, the description is complete: it explains the side effect, pack vocabulary, aliases, idempotence, cost reporting, active surface reporting, and reversibility. No critical calling information is missing.

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

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

Schema description coverage is 0% and packs has no enums, so the description carries the full burden. It compensates thoroughly by listing exact pack names ('graphics', 'tables-charts', 'design', etc.), their contents, and legacy alias resolution. An agent can correctly construct the packs argument from the description alone.

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 on optional tool packs mid-session' and clearly states the observable effect that the tool list grows. It also distinguishes itself from the sibling disable_tools by explicitly saying disable_tools reverses this action.

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 frames when to use the tool: mid-session, to enable optional packs, and gives a comprehensive catalog of pack contents to guide selection. It names disable_tools as the reversing alternative, though it does not explicitly state when not to use it or compare against other enabling mechanisms.

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 readOnlyHint=true already present, the description adds substantial behavioral detail: regex is guarded against catastrophic backtracking, text matching is on displayed text rather than raw XML, count is always the true total, pagination includes a 'page' block with omitted count and next offset, and compact changes the output shape. No annotation 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 but every sentence carries signal: output contract, regex safety, encoding nuance, pagination, compact mode, graphics-pack pointer, and sibling routing. It is front-loaded with the core purpose and return format.

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 is unusually complete for a read-only search tool: output schema exists, annotations cover safety, and pagination/regex/display semantics are explained. The main residual gap is the undocumented scope and include_notes parameters, which prevents a perfect completeness 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 must compensate. It does explain regex, compact, query escaping, and offset/pagination, but it leaves several parameters unexplained: scope, include_notes, limit, and file_path semantics. This is a meaningful gap for an 8-parameter tool.

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

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

The description names a specific verb and resource: 'Search the deck's text' and specifies exactly what is returned (slide index, shape id, paragraph index, character offsets). It also differentiates itself from get_text by stating 'Use this to locate text; to read it in order, use get_text' and explicitly links its output to format_text and 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?

It gives explicit routing guidance: use this to locate text, use get_text to read text in order, and notes formatting-aware replacement lives in the graphics pack via enable_tools(packs=['graphics']). This is clear when-to-use and alternative selection.

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

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

The description richly discloses behavior beyond the annotations: it rewrites run sizes, writes normAutofit fontScale, enables normAutofit, reports still_overflowing for shapes that cannot fit, and explains atomic save/backup behavior. It also honestly warns that the heuristic is an ESTIMATE without font metrics. This goes well beyond the destructiveHint flag.

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, purposeful sentences deliver the core action, scope, failure mode, estimation caveat, verification path, and backup behavior. Nothing is wasted, and the most important behavior appears first.

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 text-fitting tool with five parameters and an output schema, the description covers the algorithm, scope, minimum-size floor, failure reporting, precision caveat, verification path, and save behavior. The presence of an output schema makes the lack of a return-value explanation 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 description coverage is 0%, so the description carries the burden, and it does compensate for several key parameters: shape=None semantics, min_size as a floor in pt, and backup=False skipping rotation. file_path and slide are not explicitly described, but their roles are inferable from context and their parameter 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: 'Shrink overflowing text to fit,' and then details the mechanism, scope, and edge-case behavior. It is clearly differentiated from text-reading and editing siblings like get_text, find_text, and set_placeholder_text, so an agent can infer when this tool is the relevant one.

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

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

The intended use case is implied by 'overflowing text' and the explicit shape=None behavior, but there is no direct statement of when to choose fit_text over alternatives such as set_placeholder_text or search_and_replace. It does offer a verification suggestion with export_slide_images, which is useful, but it does not explain when not to use 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?

Annotations already declare readOnlyHint=true, so the description only needs to add scope. It does so by describing the tool as cheap, deck-level, and explicitly noting what it is not: element enumeration, rendering, validation, or PDF export. The presence of an output schema covers the need to describe return format.

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 sentences carry a dense, useful payload with no filler. The fact inventory is front-loaded, and the routing guidance for alternatives and the assembly-export pack is compressed into clear, actionable clauses.

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 readOnly annotations, output schema, and one obvious required parameter, the description fully covers what the tool returns, when to use it, when not to use it, and where to go for related functionality. Nothing an agent needs for correct invocation is missing.

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

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

The single required file_path parameter is self-evident from its name, but schema description coverage is 0% and the description never explains path format, file type expectations, or how to reference the presentation. The parameter's meaning is adequately implied by the tool's purpose, though the description could have been more explicit.

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 'Deck-level facts in one call' and enumerates concrete contents: slide count and size, slide order with durable ids and titles, masters and layouts, sections, and notes presence. This clearly names the resource and distinguishes it from sibling tools like get_presentation_view and list_elements.

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

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

Explicitly says this is 'the cheap first look before get_presentation_view' and instructs to 'use list_elements' when enumerating one kind of element. It also redirects rendering, validation, and PDF export to the assembly-export pack, leaving no ambiguity about when this tool should be used.

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 stable [s:id] and [a:hex] anchors, 1-based vs 0-based coordinate conventions, notes rendered as quoted blocks, and the budgeted pagination behavior with omitted counts and continuing offsets. 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 dense and front-loaded with the core purpose before diving into details. Every sentence adds useful information, though the density and parentheticals make it a little heavy; it is appropriately sized for the number of parameters and conventions it must explain.

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 the return format, anchor semantics, scope/detail options, pagination, coordinate system caveat, and how to use the result with apply_edits and enable_tools. With an output schema present and readOnlyHint true, nothing essential is missing 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?

Schema description coverage is 0%, so the description carries the full burden for parameters. It defines scope values (None, index, {'slide_id': N}, or list), detail values ('outline', 'text', 'full'), and explains limit/offset pagination in slides. This is 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 a specific verb and resource: 'the anchored markdown projection of a deck,' and explains exactly what the view contains (slide headers, shape blocks, tables, notes). This clearly distinguishes it from metadata-style siblings like get_presentation_info by emphasizing it is the cheap way to read a deck and feed anchors to 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 states it is 'THE cheap way to read' a deck and that anchors should be fed to apply_edits, giving clear context for when to use it. It also explains scope, detail, and pagination options. It does not explicitly name alternatives such as get_text or get_presentation_info, but the usage intent is strongly implied.

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 explicitly stating the call is read-only, requires no deck, touches no file, and returns a specific set of server-related fields. This fully discloses the behavior and scope of the tool without contradicting the 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 every clause earns its place: it front-loads the core purpose, then the detailed list of reported fields, then the usage distinction and the sibling pointer. No redundant or filler content is present.

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 the long list of reported fields, the description fully captures purpose, usage constraints, read-only behavior, scope, and the sibling relationship. With an output schema present, no return-value documentation is needed from the description, and nothing important is left out for an agent to call or interpret the 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?

The tool takes zero parameters, so the default baseline is 4. The description correctly describes the fixed output scope, which is all an agent needs to know about this parameterless tool.

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

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

The description names a specific verb and resource: 'Report the KitchenSink4PPT server build' and then enumerates exactly what is covered. It also distinguishes itself from siblings by stating it is 'the only tool that answers WHAT you are connected to' and that diagnose covers the environment.

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: it 'needs no deck and touches no file,' making it appropriate for a direct server-info query. It also names the relevant alternative, diagnose, and assigns it a different responsibility, so the agent has 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 already declare readOnlyHint=true and openWorldHint=false, and the description adds value beyond that: it discloses pagination behavior ('page' block with omitted count and next offset), the durable shape-id convention, and the live-save caveat (UNSAVED until live_save). This is useful behavioral context not present in the 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?

Front-loaded with the core return semantics in the first sentence, then narrows to parameter nuance. The final live-mode sentence is dense and slightly run-on, but still conveys three distinct modes in a compact way; nothing is 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?

An output schema exists, so return-value documentation is covered by the structured field. Given the tool's complexity (pagination, multi-mode live handling, shape-id addressing), the description is thorough enough for an agent to invoke it correctly; only minor polish around the live sentence would push it higher.

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 and delivers: it explains the 'slide' parameter (0-based index or {"slide_id": N}), the limit/offset pagination semantics, and the live parameter's three modes in detail. Only file_path is left to self-evidence.

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 ('get') + resource ('slide info') and enumerates exactly what is returned: durable slide_id, layout, hidden flag, notes presence, and every shape's id/name/kind/geometry/placeholder/text. Distinguishes from get_presentation_view, which is explicitly named as the all-slides counterpart.

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?

Routes the user to get_presentation_view for the all-slides use case and explains the live parameter's role when the file is locked by PowerPoint. Gives clear context for when to call this tool, though it does not state explicit exclusions for every sibling (e.g., apply_edits).

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 when the file is locked by it', which directly contradicts the readOnlyHint=true annotation. Even though scope/paging/live details add behavioral context, the rule requires score 1 when the description contradicts 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 main purpose is front-loaded and the content is dense rather than padded, with semicolon-separated behavioral notes. However, the middle section on paging is terse and the live sentence is convoluted, making the structure slightly harder to parse than necessary.

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 tool with an output schema, the description covers the key invocation concerns: scope, notes, paging, lock/live modes, and sibling routing. The remaining gaps are the implicit file_path and the contradictory live-editing claim, which prevents full completeness.

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

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

With 0% schema description coverage, the description carries the full burden and largely delivers: it explains scope forms, include_notes=True, limit/offset paging semantics, and live mode values. It leaves file_path implicit and does not fully spell out limit/offset mechanics, but it adds substantial meaning beyond the raw 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 outcome: 'Plain text of the deck in reading order' and defines the extraction conventions (spTree order, tab-joined cells, cached field text). It differentiates itself from siblings by explicitly routing edit-anchor needs to get_presentation_view and rendered-appearance checks to the assembly-export pack.

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 names concrete alternatives and when they apply: 'For edit anchors, use get_presentation_view' and 'Rendered-appearance checks live in the assembly-export pack.' It also documents live modes with conditions, helping an agent decide which setting to use for locked files.

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 openWorldHint=false, so the description doesn't need to repeat that. It adds value by explaining the parameter behavior: 'Call with no task for the index, with a task name for full steps.' This discloses how the tool behaves differently based on input, which is beyond the structured annotations. No contradiction exists.

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 somewhat long due to the recipe list, but every item serves a purpose – they are the valid values for the task parameter. The core purpose is front-loaded, and the usage instructions are clear. It's efficient given the information density, though it could be trimmed by moving the recipe list to a separate reference.

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 tool has one optional parameter and an output schema, so the description covers the essential call patterns and usage context. It explains when to read recipes and lists all known task names. No critical information is missing for an agent to invoke it correctly. The output format is presumably covered by the output schema.

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

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

The schema has zero description coverage, so the description must fully explain the 'task' parameter. It does so clearly: 'Call with no task for the index, with a task name for full steps.' It also provides a list of valid task names (recipes), which compensates for the lack of enums in the schema. This is excellent parameter documentation.

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

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

The description clearly states the tool's purpose: it provides step-by-step recipes for common jobs, naming the packs and tool order. It distinguishes itself from sibling tools by being a meta-guide rather than a specific operation. The list of recipe names adds concreteness, and the instruction to call with no task for index or with a task name for full steps clarifies the resource being accessed.

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 tells when to use this tool: 'Read the matching recipe before your first deck edit of a session; it prevents most wrong-tool detours.' This gives a clear context of use and implies it's a precursor to other tools. However, it doesn't explicitly name alternatives or state when NOT to use it, but the guidance is strong enough to route an agent correctly.

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?

Adds rich behavioral detail beyond the annotations: atomic saves, two-slot backup rotation, backup=False semantics, and the live='auto'/'force'/'off' behavior including the UNSAVED caveat until live_save. This is far more transparent than annotations alone 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?

Extremely information-dense with no filler, but presented as a single run-on paragraph that mixes parameter guidance, behavioral caveats, and workflow context. A structured format would improve scannability 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?

Covers all parameters, deck creation scope, backup behavior, locked-file live modes, and layout enumeration. With an output schema available on the tool, no essential operational detail appears to be missing 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 fully compensates: layout is explained as name or index with enumeration hint, position has 0-based and default-end semantics, backup and live parameters are detailed, and file_path is self-evident from 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?

States a specific verb and resource: 'Add a slide built from a layout', and clarifies the layout-based placeholder skeleton behavior. This clearly distinguishes it from sibling tools like delete_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?

Provides clear operational context: whole decks start via create_presentation, layouts can be listed with list_elements kind='layouts', and live mode behavior is specified for locked files. It lacks an explicit 'use this instead of X' statement for most sisters, so it is strong but not maximal.

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 say readOnlyHint=true and openWorldHint=false; the description adds substantial behavior: one kind per call, slide-scoped kinds and scope semantics, count always being the true count, pagination with a 'page' block so nothing goes missing, and compact=True output behavior. These go well beyond the annotations and schema.

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 information-dense; every clause contributes: capability, return shape, scope semantics, pagination guarantees, compact mode, and routing to related tools. It is front-loaded with the core behavior, making the most important disambiguation immediately visible.

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 6 parameters, 0% schema coverage, an output schema, and safe read-only annotations, the description covers all critical decision points: what kinds exist, how scope works, how paging/limits behave, how to reduce payload size, and which sibling tools to use instead. Nothing an agent needs to invoke 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?

Schema description coverage is 0%, so the description must compensate. It explains kind by enumerating valid values, defines scope with 'None = all slides, a selector, or a list', and describes limit/offset and compact=True behavior. Only file_path is not described, but it is obvious from the required parameter name and the tool's purpose.

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 resource: 'THE multiplex enumerator, one kind per call: slides, shapes, placeholders, tables, charts, images, diagrams...' It enumerates the kinds it handles and states what it returns ('flat item list with ids and locations'). This clearly distinguishes it from siblings like get_slide_info and get_presentation_view.

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

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

Explicitly says when to use it: 'Use it to find layout names for insert_slide and shape ids for editing.' It also routes to alternatives: 'For one slide in depth, use get_slide_info; for edit anchors, use get_presentation_view.' This is exactly the when/alternative guidance an agent needs.

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 with 'Read-only; the file is never modified.' It adds useful behavioral detail beyond annotations: broken-target detection categories, address compatibility with mutation tools, and the explicit exclusion of media controls.

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

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

The description is three well-structured sentences with the core behavior front-loaded. Every sentence adds distinct value: what is listed, how it relates to mutation tools, what is excluded, and the read-only 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?

Given the output schema exists and annotations cover safety, the description is complete for invoking this tool correctly. It covers scope, hyperlink types, broken-target detection, exclusions, and the read-only guarantee, leaving no critical ambiguity.

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 clarifies that scope defaults to all slides and that file_path is the file to inspect, but it does not specify the accepted format or values for scope. This is partial compensation for an otherwise sparse 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 uses a specific verb ('list') and resource ('hyperlinks in scope'), enumerating exactly what counts: external URLs and jump-to-slide links on shapes and text runs, with broken-target detection. This clearly distinguishes it from sibling tools like get_text or list_elements.

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 the scope default ('default all slides'), what is excluded ('Media playback controls... are not hyperlinks and are not listed'), and how the output relates to set_hyperlink and remove_hyperlink. It does not explicitly say 'use this when you need to inspect hyperlinks before modifying them,' but the context is sufficiently 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 discloses several behavioral traits beyond annotations: restore is undoable because current content rotates into prev, the payload is validated before the atomic replace, and purge defaults to dry_run and only deletes when dry_run=false. This materially exceeds what destructiveHint=true conveys.

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 packs a large amount of behavior into a compact semicolon-separated block with no filler. The opening noun phrase is slightly awkward and the density could be improved with bullets, 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 six parameters, a destructive risk profile, and no schema-level descriptions, the tool description covers the backup location, slot meanings, each action, restore safety, and deletion safeguards. Return values are not explained, but the presence of an output schema makes that unnecessary.

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

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

Schema description coverage is 0%, but the description compensates by defining all six parameters: action values, source choices, scope values, file_path vs directory, and dry_run semantics. It maps parameter names to concrete examples, adding meaning not present in the input 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 defines a backup-management tool by enumerating three actions—list, restore, and purge—against the .ks4p-backups/ slots, so an agent can tell what it does. It is less explicit than a clean 'manages automatic backups' statement and does not differentiate from the create_snapshot sibling, so it stops short of a 5.

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

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

It gives actionable guidance per action: list for inspecting slots or orphaned folders, restore for overwriting from a source, and purge with dry_run safety. It does not explicitly contrast with sibling tools like create_snapshot, but the action-level conditions are 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 discloses several non-obvious behaviors beyond the destructiveHint annotation: it removes both shape-level and run-level links, drops orphaned link rels, preserves media playback affordances, and saves atomically with a two-slot backup. This gives the agent a strong model of side effects.

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

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

The description is dense but every sentence contributes critical information: target syntax, scope of removal, side effects, and save behavior. It is front-loaded with the core action and uses compact, precise phrasing without redundancy.

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 and the existence of an output schema, the description is largely complete: target semantics, side effects, and backup behavior are all specified. The only notable gap is the lack of any explanation for file_path and slide, which are required parameters.

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

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

With 0% schema coverage, the description carries the burden for parameters. It thoroughly explains the target parameter and the backup parameter, but file_path and slide are left implicit and are not described anywhere. Overall it adds substantial meaning beyond the schema.

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

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

The description states a specific action ('Remove hyperlinks from a shape or text range') with a clear resource and granular scope. It distinguishes itself from related siblings like set_hyperlink and list_hyperlinks by the verb and by detailing two target modes.

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 clear context for when to use each target form: shape id for the whole shape including runs, and a paragraph/range object for only covered runs. It does not explicitly name alternatives or exclusions, but the usage conditions are effectively embedded in the target semantics.

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 destructiveHint annotation, the description discloses meaningful behavior: durable slide_ids and view anchors survive reordering while plain indices do not, saves are atomic with two-slot backup, and backup=False skips rotation. This gives the agent a clear picture of side effects and safety controls without contradicting the 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, starting with the core operation and immediately giving the critical permutation constraint. Every sentence adds necessary operational or routing detail, and there is no filler or repetition of schema/annotation data.

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 reordering operation with destructive implications, the description covers the full call contract: scope, permutation rule, behavior of identifiers, backup semantics, and the simpler alternative for single-slide moves. The presence of an output schema means return-value documentation is not required here, so 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?

Schema description coverage is 0%, but the description compensates well for the two key parameters: order is explained as a permutation where every current 0-based index must appear exactly once and partial lists are refused, and backup is tied to the two-slot backup rotation behavior. file_path is not described, but its meaning is conventional and the schema marks it as a required string.

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 further clarifies the scope by requiring a full permutation of all slide indices and explicitly contrasts with single-slide moves via move_slide, distinguishing it from sibling tools like insert_slide, delete_slide, and duplicate_slide.

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

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

It explicitly states when to use this tool versus move_slide: use reorder_slides for whole-deck rearrangement, and move_slide for moving a single slide. It also gives concrete activation instructions for the alternative via enable_tools(packs=['design']), so an agent knows the exact routing decision.

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 annotations, it discloses substantial behavior: atomic saves, two-slot backup, preservation of the first run's formatting, inclusion of SmartArt node text, skipped overlapping fields, and the exact semantics of live='auto'/'force'/'off'. This meaningfully enriches the agent's model of the operation and is consistent with destructiveHint=true.

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?

Every sentence is information-dense and the core purpose is front-loaded. The text is somewhat telegraphic and mixes multiple caveats into flowing sentences, but it remains appropriately sized for a tool with this many parameters and behaviors.

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 formatting safety, SmartArt behavior, skipped fields, atomic saves with backups, locked-file modes, and sibling alternatives. Given that an output schema exists and the description already provides a full behavioral picture, nothing essential is missing 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?

The schema contains no descriptions, so the description carries the burden. It adds real meaning for regex, live, and backup, and file_path/find/replace are inferable by name. However, scope, match_case, and include_notes are not explained, leaving important parameter behavior undocumented.

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

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

The description opens with 'Deck-wide find and replace,' which names a specific verb, resource, and scope. It further distinguishes itself by noting fragmented-run safety, SmartArt inclusion, and explicitly routing bulk cell rewrites to set_table_cells and batches to 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?

It gives explicit alternative conditions: 'Bulk cell rewrites: set_table_cells (tables-charts pack)' and 'Batches: apply_edits.' It also defines when each live mode applies to locked files, so an agent can decide whether this is the right tool and how to invoke it safely.

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 annotations (readOnlyHint=false, destructiveHint=true), the description discloses that existing links are replaced, saves are atomic with two-slot backup, and backup=False skips rotation. These are valuable behavioral details not present in the structured data, with no 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 compact but includes a cryptic phrase: 'the structure delete_slide knows how to neuter,' which requires cross-tool knowledge and is not self-contained. It could be clearer and tighter without losing information.

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

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

The description covers target, destination, tooltip, backup, and save semantics, but it omits the slide parameter semantics and does not explain how 'exactly one destination' is enforced or what happens on validation errors. Given the 0% schema coverage, these are notable gaps for a 7-parameter 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?

With 0% schema description coverage, the description meaningfully explains target structure, url/to_slide destination, tooltip hover text, and backup behavior. It leaves file_path and slide implicit, but those are inferable from the tool's presentation 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 'Set a hyperlink on a shape or text range, replacing any link already there,' which names a specific verb and resource. This clearly distinguishes it from siblings like remove_hyperlink and list_hyperlinks by being the setter operation.

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

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

It explains when to use the tool by describing target types (shape vs text range) and destination selection (url vs to_slide), and it pairs navigation buttons with insert_shape. It does not explicitly state exclusions or when-not-to-use scenarios, but the context is clear enough.

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 annotations already declaring readOnlyHint=false and destructiveHint=true, the description adds substantial beyond-annotation behavior: atomic saves, two-slot backup rotation with a backup=False escape hatch, and live='auto' editing of the open PowerPoint copy of a locked file. These are exactly the kind of side effects (file mutation, backup behavior) an agent needs to anticipate, and nothing in the text contradicts the 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?

Efficiently front-loads the core purpose and packs every sentence with new information — parameter semantics, routing, save behavior, live mode — with no filler. Some phrasing is cryptically compressed ('raw ph type', 'idx/paragraphs= file-mode only'), which slightly hurts readability despite the economical structure.

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

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

Given the high complexity (7 params, 3 required) and 0% schema coverage, the description covers the essential semantics, save/backup behavior, and alternative-tool routing, and an output schema exists so return values need no explanation. The remaining gaps are the undocumented required slide parameter and no guidance on invalid placeholder/error behavior, which prevent a top 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 parameter burden, and it does so extensively: placeholder matching semantics ('exact type wins', body/content synonyms, raw ph type, idx int), text encoding (newlines = paragraphs, tabs = levels), paragraphs format with level range 0..8, backup=False semantics, and live='auto' semantics. However, the required slide parameter (schema type {}) and file_path receive no clarification, leaving ambiguity on how to specify a slide.

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 statement, 'Fill a layout placeholder,' and immediately adds a distinguishing trait ('styling inherits from the layout'). It also separates itself from adjacent operations by naming free text boxes (graphics pack) and batches (apply_edits), so an agent can tell it apart from siblings without opening their 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?

Provides explicit routing for the main alternatives: free text boxes go to the graphics pack, and batched operations go to apply_edits. It also constrains when idx/paragraphs input is valid ('file-mode only'). It stops short of a full when-to-use versus the broader sibling set (e.g., fit_text, get_text), but the key adjacent cases are covered.

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