EaseWeb

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation risk profile is covered structurally. The description adds a consequence the annotations cannot: notes and replies are visible to every viewer of the presentation, which is exactly the kind of side-effect disclosure that matters for a write tool. It does not mention that repeated calls create duplicate notes (non-idempotent) or what failures look like.

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

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

Two sentences, front-loaded with the core action, with the placement options and the visibility caveat following immediately. No filler or restatement of the title.

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

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

An output schema exists, so return values need not be explained, and annotations plus full schema coverage carry the structural load. The description supplies the access requirement and audience visibility. The only gap is silence on duplicate-creation behavior for a non-idempotent write 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 description coverage is 100%, so the per-parameter baseline is 3. The description goes beyond the schema by explaining the interaction between parameters — omitting slide_id targets the whole presentation, and reply_to answers an existing thread rather than starting a new note — which the individual field descriptions do not make explicit together.

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 ("Leave a note on any presentation") and enumerates the three placement modes: slide-level, presentation-level, and thread reply. This cleanly separates it from delete_comment, list_comments, and resolve_comment. It stops short of naming a sibling explicitly, so a 4 rather than a 5.

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

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

The description tells the agent which parameter combination selects which behavior (slide_id for a slide note, neither for a presentation-wide note, reply_to to answer a thread), which is genuine when-to-use guidance. It also establishes the access precondition ("any presentation you can see"). No explicit when-not-to-use or error-condition guidance.

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

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

Annotations already cover the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description still adds real value: it discloses the edit-permission requirement and the return shape (the new slide, ids only unless response="full"), which annotations do not.

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

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

Two sentences, front-loaded with the action and placement, then the return contract. No filler, and the parenthetical qualifiers are load-bearing.

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 13-parameter mutation tool with nested objects and an output schema, the description covers placement, optional inline blocks, and response verbosity — the decisions an agent must make. Minor gaps remain around whether creating a slide shifts existing slide numbers and any limits on slide count, but nothing essential to a correct call is missing.

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

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

Schema coverage is 100%, so all 13 parameters including enums and the nested objects structure are already documented in the schema. The description restates position semantics and the response enum but adds no format, constraint, or interaction detail beyond what the schema provides. Baseline 3 applies.

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

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

Specific verb + resource ("Add a slide") plus scope details: append or at a 1-based position, optionally with blocks. It clearly conveys what gets created. It does not, however, distinguish itself from the sibling add_slides (plural/batch), which an agent must otherwise infer from the name alone.

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

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

"a presentation you may edit" implies the prerequisite permission, and the default placement (end) is stated, so usage is partially framed. But there is no explicit when-to-use guidance versus add_slides (batch insert), copy_slides, or edit_slides when adding blocks to an existing slide, and no stated failure conditions.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation. The description adds useful behavior: it requires edit permission, returns the new slides, and explains that slide_number links count slides after insertion so new slides can link to each other.

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: purpose first, then slide object shape, then link-resolution behavior, then return format. Every sentence contributes useful information without wasted prose.

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 a 100%-covered schema and an output schema, the description is nearly complete for invocation. The only minor gap is that nested block props are only referenced indirectly rather than described, but that is acceptable given the structured schema and block format reference.

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

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

Schema description coverage is 100%, so the schema carries the baseline. The description adds meaningful semantics beyond the schema by clarifying that position is 1-based, defaulting to the end, and by explaining that slide-number links are resolved after insertion.

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

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

The description states a specific verb and resource: adding several slides at once to an editable presentation. It also distinguishes bulk insertion from the singular sibling add_slide by emphasizing 'several slides at once' and specifying insertion positions.

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: the presentation must be editable, and slides are inserted at the end or from a 1-based position. It does not explicitly compare with add_slide or copy_slides, so the alternative selection guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the scope semantics of whole_project, but omits behavioral details such as whether the requester is notified, whether a declined request can be re-answered, or whether answering twice errors out.

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

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

Two tight sentences with the approve/decline action front-loaded and the scope modifier second. Slightly awkward embedded quoting of parameter names costs it a point but there is no filler.

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

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

Output schema exists, annotations cover safety, and all parameters are described, so remaining burden is small. The description covers the decision semantics and scope adequately, though it could note side effects on the requester or re-answering behavior.

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

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

Schema description coverage is 100%, so all four parameters (including the role enum and its meanings) are already documented. The description only restates the role default and whole_project behavior, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

Specific verb pair ('Approve or decline') plus a specific resource ('request for access to one of your presentations or projects'). It is clearly distinguishable from siblings like set_access (grant directly), request_access (create a request), and list_access_requests (enumerate).

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?

Conveys the decision context and clarifies the 'role' default ('what was asked for') and the 'whole_project' scope, but never states when to use this versus set_access or request_access, nor what happens on an already-answered request. Usage is implied rather than spelled out.

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?

This adds substantial behavior beyond the annotations: with the default 'fresh' the databases are rebuilt from scripts, but changes made by the blocks persist, which tells the agent about real state mutation despite destructiveHint=false. It also enumerates every status outcome and the exact comparison normalizations (whitespace around cells, table separators, row counts, table headers).

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

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

Purpose is front-loaded, but the body is one dense run-on sentence with nested parentheticals that is hard to parse on first read. Nearly all content is relevant, yet the phrasing is far less scannable than it could be.

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 four parameters, an output schema, and mutation side effects, this covers what an agent needs: ordering, comparison rules, side effects, and status semantics. The only omission is guidance on the 'only_expected' parameter and on permission failure behavior.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: 'fresh' is disclosed as defaulting to true and what it recreates, and 'slide_ids' is framed as the resumption mechanism after a timeout. 'only_expected' is not mentioned, leaving one gap.

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

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

The definition states a concrete verb+resource: run a presentation's code blocks in slide order and compare each output against its 'expect'. This is clearly distinct from presentation-reading siblings. It never names the closest sibling (run_code), instead explaining it as if no alternative existed, so sibling differentiation is implicit rather than explicit.

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

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

It implicitly scopes usage to presentations 'you may edit' and tells the agent how to resume after a 'skipped' block via 'slide_ids' and 'fresh': false. However, it never says when to pick this over run_code, nor what to do when blocks fail vs. mismatch beyond listing statuses.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: measurements run in a server-side browser when available and fall back to font-width estimation ("measured": true), and edited slides carry their warnings into mutation responses as "layout_warnings". It stops short of disclosing cost or latency of the browser measurement, which is the main behavioral risk for an agent deciding to call it.

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 warning taxonomy is front-loaded, which is good, but the prose is roundabout and parenthesis-heavy, and the highly situational caveat about text running into bottom padding on unfilled blocks consumes a full sentence. The most decision-relevant fact for an agent - that mutations already attach layout_warnings - is buried at the very end.

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 values need not be explained, and the description still covers the interpretation caveats an agent needs (measured vs. estimated sizes, language tagging, only-visible-content rule). For a read-only diagnostic with full schema coverage this is essentially complete, though it omits any hint about cost or how many slides a range check can handle.

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

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

Schema coverage is 100%, so slug, slide_ids, from_number and to_number are all documented in the schema; baseline 3 applies. The description adds nothing about the relationship or precedence between slide_ids and the number range filters, and the "lang" it mentions is an output attribute of warnings, not an input, so no extra parameter meaning is conveyed.

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 capability: it returns warnings about how presentation slides will look, and enumerates the concrete warning classes ("overflow", "cut", "outside", "overlap") plus per-language reporting. The purpose is unambiguous, but it never explicitly contrasts itself with the visual sibling preview_slides, leaving the agent to infer the distinction between a rendered preview and a diagnostic warning 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?

Usage is only implied: the warning taxonomy suggests the tool is for validating layout before export or publish, and the final sentence hints that mutating operations already return layout_warnings. There is no explicit statement of when to call this versus preview_slides, and no guidance about when a full check is unnecessary.

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 covering safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description goes well beyond them: it discloses what is preserved (blocks, translations, background, speaker notes, with the notes caveat tied to edit permission), how internal links are rewritten, and that dangling links lead nowhere across presentations. It also states the return shape (ids only unless response is "full"), which is exactly the behavioral context an agent needs before invoking a mutating copy.

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

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

Front-loaded with the action and mode split, then the preservation and link semantics, then placement defaults, then the return contract — a sensible order with little filler. The dense link-rewriting sentence is hard to parse and would read better as separate clauses, but overall length is proportionate to the operation'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?

For a six-parameter copy tool with a full input schema and an output schema, everything an agent needs is present: scope, permission caveat on speaker notes, placement defaults, multiplicity semantics, link behavior, and return detail. Return values need not be re-explained given the output schema, and the description does not attempt to.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning on top: "copies" is explained as repeated duplication in turn (one prepared slide for each appendix) and "after" is given its default resolution for both the duplicate and cross-presentation cases, which the schema does not state. Enumerable "response" is only summarized, not enriched.

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 sentence states a specific verb (copy) and resource (slides with all their blocks) and immediately splits the operation into two distinct modes: duplicating within this presentation versus copying from another. It does not name the neighboring siblings (add_slides, reorder_slides, add_slide) that an agent might confuse it with, so sibling differentiation is implied rather than explicit.

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

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

"slide_ids" of this very presentation (to duplicate them) or of the presentation "from" (any you can see)" clearly maps each scenario to the relevant parameter, and the default placement rules are spelled out for both modes. What is missing is an explicit exclusion or alternates clause, e.g. when to use add_slides instead when the goal is new content rather than a copy.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description adds substantial context beyond that: that every presentation exists in all site languages simultaneously, that translations must be supplied via *_tr fields and "tr" props, and that the response reports "missing_translations". It omits permission/auth prerequisites but the access enum in the schema covers visibility.

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 action, then the slides/blocks format, then the translation rule, then the return shape — a sensible ordering. It is dense and uses compact code-like notation mid-sentence, which slightly hurts readability but wastes little.

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

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

For a 10-parameter tool with nested slide objects and an output schema, the description covers the parts that are hardest to infer: the block/slide payload shape, slide-link syntax, the multi-language obligation, and what the response contains. Database scripts and theme defaults are left to the schema, which is acceptable given 100% coverage.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns above that by explaining the cross-slide linking convention ({"kind": "slide", "slide_number": N} is 1-based within the submitted list) and the response="full" behavior of returning every prop — semantics not fully conveyed by the schema 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?

States a specific verb and resource ("Create a new presentation") plus meaningful scope: it can be created empty or fully populated with slides and blocks in one call. The phrase "in one call" implicitly contrasts with the create-then-add_slides path, though no sibling is named explicitly, keeping it short of a 5.

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

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

Usage context is implied rather than stated — batching slides into creation, and writing all site languages up front. There is no explicit guidance on when to prefer this over import_presentation, copy_slides, or create-then-add_slides, and no stated prerequisites (e.g. upload_image first for backgrounds).

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

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

Annotations declare a non-readonly, non-destructive, non-idempotent write, but they cannot express the side effect the description supplies: a presentation already in another project is moved out of it. That cross-resource mutation is exactly the kind of context annotations miss, though permissions/limits are not mentioned.

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

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

Two sentences, zero filler, and the primary action is front-loaded before the optional-parameter and side-effect details. Every clause carries information the caller needs.

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 values need no explanation, and annotations cover the safety profile. The description covers the notable side effect; only ownership/permission requirements for creating in a workspace are left unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the presentations array is consumed 'in this order', and the one-project-per-presentation constraint governs which slugs are valid inputs.

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

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

States a specific verb+resource ('Create a project') plus scope ('of yours') and the optional inclusion of presentations. It distinguishes itself from update_project/get_project only implicitly via the create framing and the move-over behavior; no sibling is named outright.

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 create framing implies when to use it versus update_project, but there is no explicit when-to-use, when-not-to-use, or alternative routing. The move-over sentence is behavioral, not usage guidance, so the agent must infer the boundary.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds two pieces of context the annotations cannot: the cascading deletion of replies when the note starts a thread, and the authorization requirement (author or presentation owner).

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

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

Two short sentences, no filler, with the core action and its cascade effect front-loaded before the permission clause. Every clause earns its place.

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

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

With annotations covering the mutation/destructive profile, an output schema present, and the parameter fully documented, the description supplies the remaining critical facts: cascade deletion and who is authorized. Only the distinction from resolve_comment is left implicit.

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

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

Schema description coverage is 100% for the single comment_id parameter, so the schema fully documents the input. The description adds no format, syntax, or lookup guidance beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Delete a note') and clarifies the cascade scope ('with its replies, when it starts a thread'). It is clearly distinguishable from add_comment/list_comments, though it does not explicitly contrast with resolve_comment, which is the nearest ambiguous sibling.

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

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

Provides a permission condition ('Its author or the owner of the presentation may do it') but gives no explicit when-to-use guidance versus alternatives such as resolve_comment (which likely closes rather than removes a comment). Usage is only 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds the specific effect that the presentation disappears from the site and from the list, which is modest context beyond the annotations but no irreversibility or permission 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?

A single efficient sentence with the core action front-loaded and the parenthetical clarifying scope. No wasted verbiage, though the parenthetical is nearly redundant with the destructive annotation.

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 values need not be described, and annotations cover the destructive/idempotent nature. However, for a permanent deletion tool there is no word on reversibility or preconditions, leaving a small but real 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 100% with a single well-documented slug parameter, so the schema carries the semantic load. The description adds nothing about the identifier beyond what the schema already provides, matching the baseline for full coverage.

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

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

States a specific verb (delete) and resource (presentation), making it immediately distinguishable from delete_slide and delete_project by name. It stops short of explicitly contrasting itself with siblings, but the action and target are unambiguous.

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

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

There is no guidance on when to use this versus alternatives (e.g., restoring via restore_version, or deleting slides individually), nor any stated prerequisite such as required permissions or confirmation. The agent must infer usage entirely.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false. The description adds genuinely new behavioral context: presentations are preserved, and their internal links dangle afterwards. That surviving-side-effect detail is exactly what annotations cannot express.

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

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

Two short sentences, front-loaded with the action and followed by the exact consequence. No filler, no restatement of the title.

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

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

An output schema exists and annotations carry the safety profile, so the description's job is narrow: clarify collateral effects. It does that well. What is missing is any mention of required permissions or whether the deletion is recoverable.

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

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

Schema coverage is 100% and the single 'project' param is documented as a slug with its address format. The description's 'of yours' hints at an ownership precondition but adds no syntax or identification detail beyond the schema. Baseline 3 applies.

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

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

Clear specific verb+resource ('Delete a project'), scoped by ownership ('of yours'). The consequence sentence implicitly distinguishes it from delete_presentation (presentations survive), though no sibling is named explicitly.

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

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

No statement of when to choose this over delete_presentation or update_project, and no prerequisites or warnings. Ownership ('of yours') is the only implied constraint; the rest is left to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds one genuinely useful side-effect disclosure — 'Links that led to it stop leading anywhere' — which is not derivable from annotations, but it says nothing about reversibility (restore_version exists) or the conflict behavior beyond what the schema already documents.

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

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

Two short sentences, zero filler, with the action stated first and the consequence second. 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?

An output schema exists, annotations cover the safety profile, and all three parameters are documented in the schema, so the description need not restate returns or field meanings. What is missing is guidance on when deletion is appropriate versus editing or restoring, and any note on whether the deletion is recoverable.

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

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

Schema description coverage is 100%, with slug, slide_id, and the optional base_version all fully explained in the schema itself, including the 409 conflict semantics. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (Delete) and resource (a slide of your presentation), which cleanly separates it from delete_presentation, delete_comment, and delete_project by resource type. It never explicitly contrasts with the neighboring slide-mutating tools (add_slide, update_slide, edit_slides), so it stops short of full sibling differentiation.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives such as update_slide or restore_version. The agent must infer usage entirely from the tool name and the sibling list.

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

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

The description explicitly supports deleting blocks, including a "delete": [block ids] operation and the title "Add, change or delete blocks", but the annotations declare destructiveHint=false. That is a direct contradiction about whether the tool performs destructive updates.

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 and organized around the three operations. Despite covering a complex multi-mode tool, every sentence adds operational detail and there is little wasted text.

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

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

Given the rich schema, 100% description coverage, and output schema, the description covers the essential operation semantics well. It does not discuss base_version conflict behavior, but the schema already documents that parameter and the contradiction lies primarily in behavioral transparency.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema, especially for update modes: only supplied props change, multiple ids can share props, and "inside" targets a card background plus all blocks within its rectangle while skipping unsupported props.

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 resource and set of verbs: add, update, and delete blocks of a slide, while leaving other blocks untouched. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like update_slide or edit_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 gives clear usage context: use it to change some blocks of a slide in one step while leaving the rest alone. It explains the three operation modes, but it does not name alternatives or state when not to use this tool versus sibling tools.

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

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

The description goes meaningfully beyond the annotations: it discloses all-or-nothing atomicity ('Nothing is changed when one item is wrong'), optimistic concurrency via 'base_version' and the 'slide changed meanwhile' check, that exactly one history version is produced, and that changed slides are returned. Annotations only declare the generic non-readOnly/non-destructive/non-idempotent profile, so this added context is real value.

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 batch+versioning purpose, then the payload contract, then the failure semantics and return value — a good information order. It is dense and slightly run-on with nested parentheticals, and the opening sentence trails into a fragment before the spec begins.

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 the risky behaviors an agent must know before calling a mutation tool: atomic failure, stale-write protection, history side effect, and return shape. With an output schema present it does not need to enumerate return values, and the 'response' enum is documented in the schema, so the remaining gap is only the missing sibling comparison.

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

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

Schema coverage is 100%, but the 'edits' items are declared only as untyped objects, so the description carries the entire payload contract: the add/update/delete/at_bottom/base_version keys, the 'add' block shape {type, props}, top-vs-bottom placement, and the three update targeting forms ('id', 'ids', 'inside' with a card block id). That is substantive meaning the schema does not provide.

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 concrete verb and resource ('change blocks on many slides') and adds the batch/versioning framing, which distinguishes it from single-block editing. It never names its closest siblings (edit_blocks, update_slide), so the differentiation is implicit rather than explicit.

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

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

Usage is implied through the batching semantics and the atomicity guarantee, which tells an agent this is the right tool when multiple slides must change together or not at all. However, there is no explicit 'use this instead of edit_blocks/update_slide when...' routing, which is exactly what an agent needs among 50 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the returned download URL works without a key for one hour (temporal/auth detail), export is restricted to the author (authorization), and each format's fidelity is described. This is meaningful added context beyond the structured fields.

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?

Dense single paragraph with zero filler; the format enumeration carries most of the information load and the permission constraint is placed last. The leading fragment 'A file of one of your presentations:' is slightly awkward as an opener but quickly resolves into specifics.

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 the essentials for a low-complexity, 2-param tool: output artifact types, the download URL, its expiry, and the caller restriction. With an output schema present there is no obligation to describe return structure, so the remaining gap (error modes) is minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema's terse 'The kind of file' by explaining what each enum value actually contains and whether it is editable or re-importable. That materially disambiguates the format choice.

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

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

Names a specific verb+resource ('export' a 'presentation') and immediately distinguishes itself from siblings like import_presentation and get_format by enumerating the three output artifacts it produces. An agent can tell exactly what this tool produces without opening the schema.

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

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

Gives clear selection guidance for the format enum (pptx = editable, zip = site archive re-importable, pdf = viewer-faithful), which is effectively when-to-use guidance for the enum. It also states the authorization prerequisite ('Only the author may export'). It does not explicitly name an alternative sibling for related reads, so it falls just short of 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-obvious semantics: that 'effective_level' can differ from the presentation's own level because a project's stricter level is inherited. That is behavioral context an agent cannot get from the schema or 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?

One front-loaded sentence that enumerates return content with two tight parentheticals. It is efficient, though the sentence is a noun phrase rather than a statement of action, which slightly weakens the opening.

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 values need no prose, and annotations cover the safety profile; the one input is fully described in the schema. The meaningful remaining gap is that the boundary with list_access_requests and set_access is never stated, which matters in a 48-tool surface.

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

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

Schema coverage is 100% and the single slug parameter is already documented in the schema as the address form /movie/<slug>/. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

The description enumerates exactly what the tool returns: own level, effective_level (with the inheritance rule), granted access with roles, and pending requests. That is a specific resource with real content, not tautology. It stops short of naming what distinguishes it from siblings like set_access or list_access_requests, which overlap on the 'pending requests' and 'level' concepts.

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

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

There is no when-to-use statement, no prerequisite, and no alternative named. The reader must infer from the name that this is the read counterpart to set_access, and the description's mention of 'pending requests' actually blurs the line with list_access_requests without resolving it.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered and the description does not contradict it. The description adds that this is a 'complete reference' (i.e. static documentation data), but offers no additional behavioral context beyond that; with annotations carrying the load, a 3 is appropriate.

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

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

A single front-loaded sentence with a colon-separated inventory of what the reference contains; nothing is padded. The enumeration is long but each item earns its place by signalling the reference's breadth.

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

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

For a zero-parameter static reference with an output schema already describing the returned structure, the description is largely complete — the agent needs no return-value detail. The only gap is the absent routing guidance relative to the many block/slide-editing siblings.

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

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

The tool takes zero parameters, so the baseline is 4. There are no argument semantics to clarify, and the description correctly does not waste space inventing any.

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 resource and enumerates its contents precisely ('block types with every prop and its default, allowed values of every enumerated prop, number ranges, colour props...'), so an agent knows this returns a schema-style reference document rather than slide data. It does not, however, explicitly contrast itself with adjacent tools such as check_layout or get_slide, so the distinction is inferable rather than stated.

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

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

There is no when-to-use guidance: nothing says to consult this before add_slide/edit_blocks, nor how it relates to check_layout. The agent must infer that this is a lookup resource for block structure. No alternatives or exclusions are offered.

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 establish that this is a safe, idempotent, non-destructive, closed-world read. The description adds genuinely non-obvious behavior: the merge/precedence rule that 'a presentation's own entries go over its project's'. That override semantics is exactly the kind of context annotations cannot express.

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?

Dense but earns its space: the sample entry format conveys the return shape compactly, and the precedence rule is stated in a single closing clause. Front-loading is slightly weak because the opening sentence is the awkward 'How the machine translator translates...' rather than a plain statement of the operation.

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

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

An output schema exists, so return values need not be spelled out, yet the description still sketches the entry format. With both parameters fully covered in the schema, the only real gap is guidance on when to use this versus set_glossary.

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

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

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description earns a point by tying the two parameters to their real meaning — slug for a single presentation versus project for all its presentations — and adding the precedence rule between them.

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 title ('Read the glossary of the translation') supplies the verb and resource, and the description explains exactly what a glossary contains, including a concrete JSON example. It does not, however, explicitly distinguish this read tool from the sibling set_glossary, so the agent must infer the read/write split from names alone.

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

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

There is no statement of when to call this tool versus alternatives (notably set_glossary). The slug-vs-project choice is described only inside the schema, not in the description, so the description itself offers no usage 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 readOnly/idempotent/non-destructive, so the description focuses on real behavioral traits: payload size (hundreds of thousands of chars for 30 slides), the pagination strategy, the texts_only reduction, and the optimistic-concurrency contract (slide version → base_version). That is genuinely beyond what annotations and schema convey.

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-loads the core payload description and the size warning well, but the sentences are long, run-on, and rely on awkward inline quoting; the base_version note about a different tool's parameter is buried at the end and could confuse.

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 and annotations cover safety, so the description's remaining job — scale, pagination, texts_only, and versioning — is mostly done. The missing piece is disambiguation from sibling retrieval tools, which matters given how many overlapping getters exist.

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

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

Schema coverage is 100%, so all five parameters are already documented with meaning. The description reinforces intent (from_number/to_number ranges, slide_ids, texts_only) but adds little syntax or semantics the schema lacks; the base_version linkage is useful but refers to a different tool's 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?

States a specific verb+resource and scope: returns every slide and block with ids and complete props in playback order. It's clear this is the full-detail retrieval tool for editing, but it never names the sibling it differs from (get_slides, get_slide, read_presentation), so the agent must infer the boundary.

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

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

Gives useful in-tool guidance — read big presentations in parts, use texts_only for reading/translating, pass the slide version as base_version when editing — but offers no explicit when-to-use-this-vs-alternative guidance against the many sibling retrieval tools. It also never says when *not* to call it (e.g., prefer get_slides for a few slides).

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

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

Annotations already establish that this is a safe, read-only, idempotent operation, so the description does not need to restate that. It adds useful behavioral context by saying only visible projects/presentations are returned and that presentations are ordered, but it does not explain what happens when a project is inaccessible.

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

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

The description is a single compact sentence with no wasted clauses. The parenthetical repetition of visibility is slightly awkward but still efficient.

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

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

Given a simple one-parameter read tool with an output schema and comprehensive annotations, the description provides the essential scope: it returns a visible project plus its visible presentations in order. Minor gaps around access failures are acceptable because the schema and annotations cover much of the rest.

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

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

Schema coverage is 100%, and the single parameter is fully documented as the project slug with an address format. The description adds no parameter-specific meaning beyond that schema, so the baseline of 3 is appropriate.

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 identifies the resource as a project and clarifies that it includes the project's presentations in order. It is clear enough to distinguish from presentation-focused siblings, but it does not explicitly contrast with list_projects or get_presentation.

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

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

There is no guidance on when to use this tool versus list_projects, get_presentation, or other project-related tools. The phrase 'you can see' hints at access scoping but does not establish selection criteria.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is fully covered. The description adds that the response contains blocks with their ids and complete props — useful return-shape context. The phrase 'a presentation you can see' hints at access scoping but is vague.

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

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

A single efficient sentence with no waste, front-loading the resource and then qualifying the payload. Slightly awkward phrasing ('a presentation you can see') but structurally sound.

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

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

For a simple read tool with a full output schema, complete parameter documentation, and rich annotations, the description covers the essentials. Only the access-implied restriction ('you can see') is underspecified, which 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?

Schema coverage is 100%: slug and slide_id are both fully documented in the schema, including the note that slide_id is stable while position changes on reorder. The description adds nothing beyond the schema, so baseline 3 applies.

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

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

States the specific resource retrieved: a single slide of a presentation, along with all of its blocks including ids and complete props. The singular framing distinguishes it implicitly from get_slides and get_presentation, though no sibling is named.

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

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

No explicit when-to-use or when-to-use-instead guidance. The agent must infer from the singular 'one slide' that this is for retrieving a single known slide rather than listing (get_slides) or previewing (preview_slides). Nothing about prerequisites or alternatives is stated.

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

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

Annotations already cover read-only/idempotent/no-destruction, so the description correctly spends its words on beyond-annotation behavior: the per-slide version must be echoed as base_version on edits, and the response carries the presentation version and slides_total. It does not discuss size limits or how large ranges are handled.

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

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

Core purpose is front-loaded in the first clause and every remaining clause carries information (selection axes, texts_only, version contract). The paragraph is dense and slightly run-on, but there is no filler.

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

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

With an output schema present, the description needn't explain return shapes, yet it still names the key returned fields (version, slides_total) and the edit-time version contract. For a 5-parameter read tool, an agent has enough to select slides and feed a subsequent edit correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by clarifying the range semantics (1-based, inclusive) and, importantly, what texts_only actually returns (words from html/tr/code blocks, no geometry). It leaves the interaction between slide_ids and the numeric range unstated.

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

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

States a specific verb and resource (get some slides of a presentation) plus exactly what comes back: blocks with ids and complete props. It is clearly narrower than read_presentation/get_slide by describing partial selection via from_number/to_number/slide_ids, though it never names those siblings explicitly.

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

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

The title and text frame it as the editing-oriented fetch, and it explains two concrete usage modes: texts_only=true for reading/checking/translating, and passing a slide's version as base_version when you change the slide. It stops short of explicit exclusions (e.g., when to prefer get_slide or read_presentation instead).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds some value by characterizing what is returned (slides and texts as markdown, or complete content as json), but says nothing about permissions actually required, size limits, or behavior on a non-existent version number.

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

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

A single compact sentence with the format options enumerated inline; nothing is wasted. The opening clause 'What a presentation you may edit looked like in a version' is slightly convoluted, which keeps it from a 5.

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 values needn't be explained, and the schema covers all three parameters. However, the description omits how an agent obtains a valid version number and how this read relates to restore_version, which is a noticeable gap for a tool living among many version/history siblings.

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

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

Schema description coverage is 100%, so the schema already documents slug, number, and format, and the enum with its default. The description repeats the format semantics ('markdown' default, 'json' complete content) rather than adding syntax or constraints beyond the schema. Baseline 3 applies when the schema carries the load.

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+resource combo — retrieving the content of a version of a presentation — and the format clause clarifies what 'content' means. It is clear on its own but does not distinguish itself from siblings like list_history, restore_version, or read_presentation, so the agent must still infer where it fits.

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

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

There is no explicit when-to-use guidance. The phrase 'a presentation you may edit' hints at a permission precondition but says nothing about when this tool should be chosen over list_history (finding the version number) or restore_version (reverting). No alternatives or exclusions are named.

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

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

With annotations only declaring the safety flags, the description carries real weight: it explains that slide N replaces the blocks and background of slide N while keeping the id, notes, history and translations, that trailing slides of the file are appended, and that title/theme/slide names/database scripts are left untouched. It also discloses the response contract (ids only unless "full") and the 'warnings' channel for unconvertible content.

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

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

Two paragraphs split cleanly along the create-vs-update axis, with the primary outcome and return shape front-loaded. A few sentences are long and clause-heavy (the 'into' paragraph chains four preservation rules), but each clause adds a distinct behavioral fact rather than restating the schema.

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

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

For an 11-parameter mutation tool with an output schema, the description covers what an agent actually needs to decide: mode selection, in-place replacement scope, what survives, and that conversion problems surface as warnings rather than errors. Return-value detail is correctly left to the output schema and parameter detail to the 100%-covered input 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?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully enriches the hardest parameters: it explains the 'into' replacement semantics and the exact meaning of 'slides' (1-based slide numbers of the file, with trailing file slides added). Parameters like 'access', 'project', 'rename', 'remove_extra' and 'base_version' are left entirely to the schema.

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

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

States a specific verb and resource ('Create a new presentation ... from a PowerPoint file (.pptx) or an EaseWeb archive (.zip)') and names the source formats and conversion behavior. It is clearly distinguishable from siblings like create_presentation (empty deck), copy_slides, and export_presentation.

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 lays out the two mutually exclusive modes: omit 'into' to create a new presentation, or pass 'into' to update an existing one in place. What is missing is a stated exclusion or pointer to alternatives (e.g., use create_presentation when you have no file), which keeps it 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?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the default result set is pending-only, and include_decided widens it to approved/declined, which is the kind of filtering default an agent needs and cannot get 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?

Two compact clauses, no filler, and the most important distinction (incoming vs outgoing) is front-loaded. The fragment format is terse to the point of being slightly telegraphic, but 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?

With an output schema present the description needn't explain return values, and annotations cover safety; the description fills the remaining gap about defaults and mode semantics. It stops short of relating this tool to answer_access_request/request_access, which would make the picture 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?

Schema description coverage is 100%, so both parameters are already documented and the baseline is 3. The description largely restates the enum semantics, adding only the emphasis on 'YOUR presentations' and the pending-default behavior for include_decided, which is modest value over 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 never states the operation itself (listing/inspecting access requests); it only elaborates on the direction modes, leaning on the tool name to convey the verb. A reader can infer it enumerates access requests, but the definition starts mid-thought rather than declaring the resource and 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 clarifies the two modes (incoming = requests to your presentations, outgoing = requests you or your agents sent) and when pending-vs-all applies, which is useful implied routing. However, it never points to the related siblings that would be alternatives (answer_access_request, request_access, get_access), so the agent must guess how this differs from those.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely new context: the permission model ('Anyone who can view the presentation sees all its notes'), which tells the agent results are not scoped to the caller's own authorship.

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

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

Three short sentences with the return shape front-loaded and the default-filter rule last. No filler, though the include_resolved sentence partially duplicates the schema and could be trimmed or used to say something the schema does not.

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, full parameter coverage and rich annotations, the definition only needs to add the permission/visibility model, which it does. Missing only a note on whether slide_id narrows scope to one slide's threads.

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

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

Schema description coverage is 100%, so all three parameters including slug and slide_id are already documented. The description restates the include_resolved default, which the schema itself already states ('default: only open ones'), adding no new syntax or edge-case meaning.

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 the resource (notes/comment threads on a presentation) and return shape (threads with replies), which lets an agent distinguish it from add_comment, delete_comment and resolve_comment. It lacks an explicit verb, relying on the noun phrase plus the title 'Read the notes' to convey retrieval.

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

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

The only usage-relevant statement is the default filtering rule ('Without include_resolved only open threads'), which is implied guidance rather than an explicit when-to-use. No exclusions or named alternatives (e.g. use add_comment to write) are given, so sibling selection is inferred from name alone.

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

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lower, and the description still adds real semantics beyond them: the newest-first ordering, the non-obvious aggregation rule (one author's consecutive changes within 10 minutes collapse to a single version), and the permission-based visibility rule. It omits pagination/limit behavior, but the added behavioral context is substantive.

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, each carrying distinct information, front-loaded with the resource and its ordering. There is no filler; the only slight cost is that the opening sentence is dense with the returned-field list.

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 values need not be explained in prose, and the description still covers ordering, the version-grouping rule, and the visibility constraint. For a two-parameter read-only list tool this is nearly complete; only pagination behavior around limit is left unstated.

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

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

Schema description coverage is 100%, with both slug and limit fully documented in the schema (including the default of 50). The description adds no extra meaning to either parameter, so the baseline of 3 applies.

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

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

The description states a specific resource and its scope: versions of a presentation the caller may edit, returned newest first, with the fields it exposes (number, author, timestamp, diff). It is clear and distinguishable, but it never names or contrasts with the closely related siblings get_version and restore_version, so sibling differentiation is left to inference.

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 context is implied rather than stated: it tells you the history is only visible to those who can edit, which implicitly routes read-only users away. However, it gives no explicit guidance on when to call this versus get_version (single version) or restore_version (revert), so the agent must infer the boundary.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The one genuine addition is the access semantics — that "open" presentations are readable and editable by anyone signed in — which is real behavioural context. The rest of the text (the field list) largely restates what the output schema already provides.

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?

It is short with no filler sentences, but it is not front-loaded: the first token is a colon-terminated fragment rather than a statement of the action, and the line break mid-sentence makes it read like a clipped doc snippet. The most useful information (that this lists presentations filtered by scope) has to be reconstructed by the reader.

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 and full annotation coverage, the return shape and safety profile are already handled, so the description only needs to anchor purpose and selection rules — and it half does that. Missing are any statement of ordering/pagination and the project-overrides-scope rule, so an agent could still call it correctly but without full confidence about result ordering.

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

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

Schema coverage is 100% and the scope enum is already documented in the schema with the same wording. The description adds a minor gloss on visibility/permissions per scope but nothing about ordering, pagination, or the project-vs-scope precedence (that constraint lives only in the project parameter's schema text). Baseline 3 is appropriate.

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 never states a verb — it opens with the fragment "Presentations:" and then enumerates scope values and returned fields. The listing behaviour is inferable from the name/title and the scope enumeration, but an agent must read the whole text to conclude what the call actually does. It gives no explicit differentiation from siblings like get_presentation or list_projects.

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?

Scope semantics are spelled out well enough to imply when each variant applies (mine/shared/open), including that "open" material is editable by any signed-in person or agent. However there is no explicit routing guidance (e.g. use this to enumerate, then get_presentation for full content) and no mention of the interaction with the project parameter overriding scope, which only appears in the schema.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful scope context (your projects plus those you were granted access to, with presentations in order), but the trailing sentence about blocks leading to slides of other presentations is confusing and does not clearly describe this tool's 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 domain definition is front-loaded, which is reasonable, but the last sentence is opaque and arguably off-topic for a list operation, diluting otherwise compact prose.

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 rich annotations, the description is not required to explain return values or safety, and it does supply the access scope. However, it omits any routing information among the many sibling tools and ends with a sentence that confuses rather than completes the picture.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a 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 defines what a project is ('presentations that belong together') and describes the scope of what is returned, but never states the action verb directly — the listing behavior is carried entirely by the name/title. It also does not distinguish this tool from siblings like get_project or list_presentations, so the agent must infer the distinction from naming alone.

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

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

There is no when-to-use guidance and no alternative named; nothing tells the agent to prefer get_project for a single project or list_presentations for presentations. The access-scope sentence implies coverage but not when this call is appropriate.

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

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

Annotations already declare it is a write (readOnlyHint=false), non-idempotent, and non-destructive, but the description adds genuinely new behavior: manually-set names are overwritten, slides without text are left alone, and the new name persists and re-follows later title changes. Disclosing the overwrite of hand-set names is valuable context beyond the safety hints, though it stops short of stating auth specifics or exact return shape.

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 behavior is front-loaded, but the prose is convoluted, especially 'the text block with the biggest letters (the highest one of those)', which forces the agent to parse a nested clarification. Every sentence carries information, but the structure is denser and more awkward than needed.

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 write tool with an output schema present, the description gives a thorough account of the algorithm, its persistence behavior, and its edge cases (hand-named slides, textless slides). The main remaining gap is the absence of explicit usage/alternative guidance, which is minor given the detailed behavior.

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

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

The single slug parameter is fully documented in the schema (100% coverage), including its /movie/<slug>/ format. The description adds no syntax or meaning beyond that, so the baseline 3 for schema-driven parameters applies.

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

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

The description names a specific verb (name) and resource (every slide of a presentation) and defines the mechanism precisely: the title is 'the text block with the biggest letters'. It is clearly distinguishable from generic siblings like update_slide or edit_slides, though it never explicitly contrasts itself with those.

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

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

Usage is only implied via the prerequisite 'a presentation you may edit', which conveys a permission requirement but not an explicit when-to-use or when-not-to-use rule. No alternative (e.g. update_slide) is named or routed to, so the agent must infer placement from the sibling list.

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

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

Beyond the readOnly/non-destructive annotations, it discloses that rendering happens in a server-side browser, that there is a hard cap of at most 6 slides per call, and that layout_warnings are returned alongside the images. It does not explain failure modes (e.g., rendering timeouts, what happens if a slide id is out of range), and the return payload is partly covered by the output 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?

Densely packed with the essential facts (output type, renderer, cap, selection rule, width, warnings) and front-loaded with the core purpose. The sentences are long and slightly run-on, with a small amount of restatement of the schema's width behavior.

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 read-only rendering tool with a full output schema and full schema coverage, the description covers purpose, limits, and selection behavior adequately. It leaves a gap only around how this relates to the sibling layout-check tool and around error conditions.

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

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

Schema coverage is 100%, so parameters are already documented; the description adds precedence semantics not in the schema — that the 6-slide limit takes the first entries of slide_ids or of the from_number..to_number range, and that slide 1 is the default. That selection-order detail is genuinely useful and goes past the schema text.

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

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

The description gives a concrete verb and resource ('Pictures (PNG) of slides ... drawn by a browser on the server') and immediately frames the output as a visual rendering, which separates it from sibling readers like get_slides or check_layout. It also states what the pictures are useful for, so the agent knows it is not just another slide-metadata call.

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 a clear use condition: verify that text fits its blocks, blocks don't overlap, and the slide 'looks right' — i.e., visual QA where structural checks are insufficient. It does not, however, mention the obvious alternative check_layout or when that cheaper option should be preferred over rendering PNGs.

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 establish readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description still adds real value: it discloses what the output contains (reading order, image descriptions, code, link destinations), the 'card' grouping semantics with its block ids, and the compact-vs-structured tradeoff of the two formats.

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

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

Two sentences, purpose front-loaded, and the card detail is placed immediately before the format note where it matters. Slightly dense — the parenthetical defining a card is long — but no filler sentences.

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, the description need not explain return values, yet it does sketch the shape (per-slide entries, card entries with block ids) and the format choice. Combined with 100% schema coverage and read-only annotations, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the format enum ('markdown' default/compact, 'json' structured) without adding anything the schema lacks, and says nothing about lang, slide_ids, or the from_number/to_number windowing.

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 concrete verb and resource and frames the result precisely: reading a presentation 'the way a person sees it' — slide by slide, texts in reading order, image descriptions, code, and link targets. That framing implicitly separates it from a raw data fetch, but no sibling (get_presentation, get_slides, preview_slides) is named to anchor the difference.

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?

Access scope is stated ('any presentation you can see (not private, or shared with you)'), which is useful, but there is no explicit when-to-use rule and no comparison to the several sibling read tools (get_presentation, get_slide, get_slides, preview_slides). The agent must infer that this is the human-readable rendering path rather than having it stated.

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

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

Annotations already declare this is a non-readonly but non-destructive, idempotent mutation. The description adds genuinely useful behavioral context beyond that: the order array must contain ALL slides, implying full-replacement semantics where a partial list is invalid. It still does not say what happens if ids are missing or repeated (error vs. silent drop), which is the main remaining gap.

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

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

A single compact sentence that front-loads the action ('Set the playback order') and then explains the key parameter. The nested colon-and-quotes construction is slightly awkward but wastes no words.

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 values need not be explained, and annotations cover the safety profile. For a two-parameter idempotent mutation the description covers the essential constraint, leaving only the failure behavior for incomplete or invalid orders unstated.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, including 'Every slide id, once.' The description reinforces the same completeness constraint on 'order' but adds no new syntax, format, or edge-case detail, so the baseline of 3 applies.

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

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

States a specific verb and resource: set the playback order of a presentation's slides, identified by slug and an id list. It is clearly distinct from siblings like add_slide, delete_slide, and edit_slides, though it never names those alternatives explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (e.g., needing the presentation to exist, or permissions), and no routing to alternative tools such as edit_slides for non-order edits. Usage is only inferable from the verb itself.

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

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

Annotations only declare the generic mutation profile (readOnly=false, destructive=false, idempotent=false); the description adds non-obvious behavioral facts an agent could not infer: formatting is preserved but a phrase split by formatting is not matched, {{slide:N}} references are not treated as text, and the return value reports counts per slide. These are exactly the surprises that would cause silent failure.

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

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

Front-loaded with the core action and tightly packed, with caveats following the primary statement. Some density and parenthetical nesting (the formatting-split example, the reference aside) make it slightly harder to scan, but no sentence is 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 13-parameter mutation tool with annotations and an output schema, the description covers scope, matching rules, formatting behavior, dry-run, and return shape. It stays silent on edge cases such as how match_case interacts with regex: true and whether the slide-selection parameters combine, which leaves a small 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it clarifies that langs defaults to all languages, that in_code must be opted into, and — most valuably — that with regex: true the 'replace' string may use \1 backreferences, which the schema does not say. Minor combination semantics (slide_ids vs from_number/to_number) remain unaddressed.

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

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

States a specific verb+resource ('Find and replace words in a whole presentation') and enumerates the exact surfaces affected: text/shape/button block texts, slide names, and code blocks when in_code is true. An agent can distinguish this bulk-replace tool from edit_blocks or update_slide 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?

Gives clear operational conditions — regex: true for Python regex, dry_run: true to only count, in_code: true to include code — and explicitly redirects one case to a different mechanism ('to point a reference to another slide, write the block's html with a new {{slide:N}}'), which implies edit_blocks. It never names an alternative tool outright or says when not to use this one, so it falls 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 annotations, it explains the approval workflow: the author sees and approves or declines the request, access attaches to the account including all agents, and asking again updates the pending request. These are important behavioral details not captured by 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 front-loaded with the purpose and then sequentially explains roles, approval flow, account scope, and repeat behavior. It is compact 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?

Given the full schema descriptions, annotations, and output schema, the description supplies the missing workflow context: pending approval, account-level access, and behavior when asking again. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already explains slug, role, and message. The description reinforces the role meanings but adds little parameter-level detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: requesting access to a presentation, with the two possible roles. It distinguishes presentation access from project access by naming the resource explicitly, though it does not name the sibling tool request_project_access.

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

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

It gives clear usage conditions: use "view" to read a private presentation and "edit" to change one that is not open. It does not explicitly cover when to use this versus set_access, get_access, or request_project_access, but the main scenario is 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?

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world. The description adds real context beyond them: the request goes to the author and approval propagates to every presentation in the project, including ones added later. It does not say whether repeat calls re-notify the author or what state the request starts in.

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

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

A single front-loaded sentence with the scope guarantee tacked on where it matters. No filler, no repetition of the tool title.

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

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

Output schema exists and annotations cover safety, so the description need not explain return values. It is nearly complete for a 3-param mutation; the only omission is post-call behavior on repeated requests and how this differs from the per-presentation request_access sibling.

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

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

Schema description coverage is 100% and the enum values are already documented in the schema, so the description only restates what 'view' and 'edit' mean. Baseline 3 applies; no additional syntax or edge-case guidance (e.g., what default role is used when role is omitted) is offered.

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

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

States a specific verb+resource (ask for access to a project) and defines the two roles inline. The scope phrase 'all of it... counts for every presentation of the project' implicitly separates it from the sibling request_access, but it never names that alternative explicitly.

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

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

Usage is only implied: an agent can infer you call this when you lack access to a project, but there is no statement of when to prefer it over request_access, what happens if access already exists, or what prerequisites (e.g., being able to see the project slug) apply.

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 say destructiveHint=false and readOnlyHint=false; the description adds the authorization rule (who may resolve), which is exactly the kind of context annotations don't carry. It doesn't mention idempotency or reversibility explicitly, though the resolved:false path implies 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?

Two short sentences: action + toggle first, permission rule second. Nothing wasted, though the permission clause is slightly under-integrated.

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

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

For a two-parameter toggle with an output schema and full annotation coverage, the description covers what it does, the reopen path, and who can call it. Return values are covered by the output schema; idempotency behavior is the only 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?

Schema coverage is 100% and the schema already documents both comment_id and resolved (including the default true). The description restates the resolved:false toggle, adding a little semantic framing but nothing beyond the schema. Baseline 3.

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 (mark) and resource (a thread/note), and clarifies the toggle to reopen via resolved:false. Toggling resolve vs. open is distinguishable from sibling delete_comment or add_comment, though it doesn't explicitly contrast with them by name.

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?

Conveys the permission model – owner of the presentation or thread starter may do it – which is a real usage constraint. But it doesn't explicitly say when to choose resolve vs. reopen beyond the parameter flip, and names no alternative 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 give the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuinely new behavioral context: the restore is itself a new version, so it is undoable the same way, and an edit permission is implied. That is useful disclosure beyond the structured fields, though auth requirements and failure modes remain unstated.

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

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

Two short sentences, front-loaded with the action and scope, then the reversibility caveat. Every clause earns its place with no 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?

With annotations covering the safety profile and an output schema covering return values, the description supplies the key missing piece (undo semantics) and the edit precondition. It is complete enough to call correctly, with only minor gaps around permissions and error behavior.

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

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

Schema coverage is 100% (slug and number both documented in-schema), so the schema carries the parameter burden. The description adds no format or constraint detail beyond it; baseline 3 is appropriate.

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 ('make ... look exactly as it did') and resource (a presentation version), and enumerates the restored scope (slides, blocks, order, title). An agent can distinguish it from read-only siblings like get_version or list_history, though no sibling is named explicitly.

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

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

'A presentation you may edit' implies an edit-permission precondition, and the tool's role (reverting to a prior version) is inferable from context. However, there is no explicit when-to-use guidance, no statement of when to prefer it over update_presentation/edit_slides, and no exclusions.

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

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

Annotations only give generic hints (readOnlyHint=false, idempotentHint=false); the description adds the crucial side-effect model: sql/mongodb/redis/clickhouse mutate a persistent presentation-scoped database ('what you change stays in it'), while python/bash run sandboxed with no network and no retention. It also explicitly reassures the presentation itself is untouched, which is high-value context beyond the structured fields.

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?

Densely packed and front-loaded with the purpose, and nearly every clause carries information (language groups, persistence, sandbox, presentation safety). It is a single run-on sentence that would be easier to parse if split, which keeps it from a 5.

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 values need not be described, and annotations plus the description together cover the safety and side-effect profile. For a code-execution tool the agent has everything needed: what runs, where it runs, what persists, and what is left untouched.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it partitions the lang enum into two groups with distinct execution and persistence semantics that the schema's bare 'Language of the code.' does not convey. The reset parameter's effect is only covered by the schema, not the description, keeping it from a 5.

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

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

States a specific verb and resource ('Run code the way the Run button of a code block does') and immediately scopes the intent ('to check it'). No sibling tool executes code, and the description makes that distinct role obvious 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?

The stated purpose ('to check it') clearly frames the use case for verification, and the language groups imply when each mode is appropriate. It offers no explicit when-not or named alternatives, but the tool is unique enough among siblings that this is a minor gap.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false; the description adds real semantic content beyond that — what 'open' actually grants (edit rights for all signed-in users and agents, with full history retention), the public read/edit split, and that 'revoke' removes named users. It does not disclose required permissions or whether a level change is reversible, which is the remaining gap for a mutation tool.

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

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

Front-loaded with the action and resource, then the parameter semantics in a single dense sentence with no filler. The heavy quoting and inline parentheticals make it slightly harder to scan than a bulleted breakdown would be, but 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 values need not be explained. With all three parameters documented in the schema and the enum consequences spelled out here, an agent has everything required to invoke it correctly; only secondary details like permission requirements are absent.

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

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

Schema coverage is 100% so the baseline is 3, but the description genuinely adds meaning the schema lacks: it defines the consequences of each enum value rather than restating 'open, public or private'. The revoke parameter is described only as 'usernames whose access is taken away', which mirrors the schema without adding much.

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 ('Change the access of your presentation') and enumerates the two mutation modes, so an agent can distinguish it from get_access or request_access. It stops short of naming the read-side siblings explicitly, so the differentiation is inferred rather than stated.

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

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

Usage is implied by the verb-plus-modes framing: use this to modify access levels or revoke named users. There is no explicit when-to-use vs. when-not guidance, and no mention of the prerequisite that the caller presumably must be an owner or admin — the agent must infer it from the sibling set (get_access, answer_access_request).

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