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

With no annotations, the description carries the full burden, and it does disclose a real behavioral constraint: templates must be discovered via list_templates first and this tool is the sole sanctioned path for adding slides. It does not cover failure modes, permission needs, or what the call returns, so it falls short of a 5.

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

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

Front-loaded with the primary directive and the sibling exclusion, then a compact numbered workflow. The ALL-CAPS emphasis is slightly noisy but each line carries distinct 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?

Three simple parameters, all schema-documented, no nested objects, and no output schema to explain, so the remaining need is behavioral routing — which the description supplies well. Minor gaps are the absence of any error/prerequisite detail for a mutation tool with no annotations.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by enumerating template IDs (title, section, image-full, two-column, quote, big-number, chart-bar) beyond the schema's shorter example list, clarifying what the 'template' parameter accepts. It says nothing extra about 'position', though the schema already documents append-vs-insert.

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

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

States a specific verb+resource (add slides) and immediately constrains it to pre-designed templates, which cleanly differentiates it from the sibling add_slide and from update_slide. An agent can pick this over siblings without opening the schema.

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

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

Explicitly says ALWAYS use this and NEVER use add_slide, then gives a 4-step ordering (list_templates → pick → add → update_slide for text). This is exactly the when/when-not/alternatives information the dimension asks for.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result is empty (no slides), but says nothing about required permissions, what is returned (e.g., an ID needed to add slides), or whether workspaceId placement has side effects. The one disclosed trait is meaningful but the mutation profile is under-specified.

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 with zero waste; the core action is front-loaded and the alternative follows immediately.

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

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

For a simple three-parameter create tool with no output schema, the description covers what it makes and which sibling to prefer. It omits return-value expectations (an agent likely needs the new presentation's ID) and any permission notes, but those gaps are minor at this complexity.

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 title, darkMode and workspaceId are already fully documented in the schema, including the 'omit for personal' default. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (create) and resource (presentation) and adds the scope qualifier 'empty', which distinguishes it from the sibling create_presentation_with_slides. An agent can pick between the two create tools from the description alone.

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

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

Explicitly routes the agent to create_presentation_with_slides for efficiency, implying this tool is for the case where no slides are supplied yet. It gives clear context but no explicit when-not condition or statement that this is the correct choice when slides will be added incrementally.

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

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

With no annotations, the description carries the full burden, and it does disclose the meaningful behavior that presentation and all slides are produced atomically in one call, plus how content fields map to element roles. It says nothing about permissions, validation failures, or limits on slide count, which matter for a creation tool.

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

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

Three short, front-loaded lines with zero filler; the atomicity claim leads, then the prerequisite, then a worked example. Every sentence earns its place.

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

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

Covers the core contract (template required, content fields are role-keyed) and points to list_templates, which is the main gap an agent would hit. But with no annotations and no output schema it leaves workspace scoping, dark-mode behavior, and the shape of the result unexplained.

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 title, template, darkMode and workspaceId, establishing a baseline of 3. The description adds real value on the loosely-typed content fields (mapping them to element roles via a concrete example) but omits darkMode and workspaceId entirely.

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+resource ('Create a presentation with slides') and adds the key scope detail 'in one call', which implies a batch alternative to create_presentation plus add_slide_from_template. It never names those siblings explicitly, so the differentiation is left partly 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?

Provides one explicit prerequisite: 'Use list_templates to see all templates and their contentFields.' That is genuine routing guidance. However it gives no when-to-use-vs-when-not guidance against create_presentation or add_slide_from_template, so the choice among creation paths 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?

With no annotations, the description carries the full behavioral burden. 'Soft-delete' is a genuinely valuable disclosure that the record is not permanently destroyed, but the description says nothing about permissions required, whether the deletion is reversible/restorable, or side effects on associated slides.

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 tight phrase with zero waste, and the key behavioral qualifier is front-loaded. Nothing to trim.

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

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

For a destructive operation with no annotations and no output schema, the definition is too thin. It should clarify recoverability, what happens to child objects like slides, and permission requirements to let an agent invoke it confidently.

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

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

The single parameter has 100% schema description coverage ('The presentation ID to delete'), so the schema already documents it fully. The description adds no additional meaning beyond what the schema provides, which is the baseline for high 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 and resource ('delete a presentation') and adds the meaningful qualifier 'soft-delete', which signals this is not a permanent removal. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like delete_slide beyond the resource 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?

Provides no when-to-use guidance, no mention of when a soft delete is appropriate versus alternatives, and no prerequisites or recovery context. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose that deletion is destructive/irreversible, whether remaining slides are re-indexed, what permissions are needed, or how failures (e.g., out-of-range index) behave.

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

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

A single front-loaded sentence with no filler, which is appropriate for a simple two-parameter tool. It is perhaps too terse to earn a 5, 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?

For a simple two-required-parameter deletion tool with full schema coverage and no output schema, the description is minimally sufficient. It omits the irreversibility and index-shift side effects that matter most for a destructive operation with no annotations.

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

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

Schema description coverage is 100%, so both parameters (presentationId, slideIndex) are already well documented in the schema, including the 0-indexed note. The description adds nothing beyond the schema, which is the expected baseline of 3 when structured fields do the work.

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

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

The description states a specific verb ('Delete') and resource ('a slide from a presentation'), so the agent knows exactly what the tool does. It stops short of distinguishing itself from siblings such as delete_presentation or update_slide beyond the word 'slide', so it earns 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?

There is no guidance on when to use this tool versus delete_presentation, update_slide, or move_presentation, and no prerequisites or exclusions are stated. The agent must infer usage entirely from the 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose that the response includes all slides and content (a deep/composite fetch rather than metadata only), but says nothing about read-only nature, permissions, or behavior when the ID is missing or invalid.

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

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

One short sentence, front-loaded with the verb and resource, with the payload scope appended. Nothing wasted and nothing that could be trimmed without losing information.

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

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

For a single-parameter read tool with no output schema, the description tells the agent what it receives (slides and content), which is the key return-value information. It is nearly complete, lacking only error/permission 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% for the single required 'id' parameter, so the schema already documents it fully. The description's 'by ID' adds no syntax, format, or sourcing detail beyond that, 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 ('Get a presentation') and adds scope ('by ID with all its slides and content'), which separates it from list_presentations. It does not, however, explicitly name a sibling alternative the way a 5 would.

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

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

Usage is only implied: 'by ID' suggests single-record lookup versus the list_* siblings, but there is no explicit when-to-use, when-not-to-use, or alternative named. Adequate context, 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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read-only operation and 'usually not needed' adds decision context, but it does not disclose return format, idempotency, or any side effects.

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

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

Two short sentences, front-loaded with purpose then guidance. No wasted 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?

Given zero parameters and no output schema, the description is nearly complete for a simple read tool: it states purpose and advises against typical use. However, it leaves 'schema reference' ambiguous about what is returned.

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?

Zero parameters, so the schema carries no parameter semantics and none are needed. Baseline 4 applies; the description adds nothing to parameter 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?

States a specific verb 'Get' and resource 'schema reference'. It is distinguishable from sibling tools like list_templates and get_presentation, though it does not specify which schema (template, slide, etc.).

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

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

Explicitly says 'Usually not needed - just use templates,' providing a when-not-to-use rule and a category of alternatives. It lacks a positive condition for when the tool is actually needed.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does explain the two-step flow (POST to uploadUrl, then use publicUrl) and the performance rationale, which is genuine behavioral context. But it omits material traits of presigned URLs: expiry, size/content-type constraints, and whether auth is required to call this tool, leaving key operational unknowns.

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

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

Front-loaded one-line purpose followed by a compact two-item Returns block, with zero filler. The capitalized emphasis is slightly informal but does not bloat the 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?

With no output schema, the description correctly compensates by enumerating the returned fields (uploadUrl, publicUrl) and what to do with each. For a simple two-param tool this is close to complete, though it leaves the presigned URL's lifetime and upload constraints 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 (filename, contentType) are documented in the schema with examples and a default. The description adds no parameter-level meaning beyond that, 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?

States a specific verb ('Get') and resource ('presigned URL') with the qualifying scope 'for fast direct image uploads'. This is clearly distinguishable from every sibling, which are all presentation/slide/workspace CRUD operations.

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

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

Implies usage via the contrast with base64 encoding ('This is MUCH faster than base64 encoding'), which tells the agent to prefer this path for image uploads. However, it never states when-not to use it, any prerequisites, or which sibling consumes the returned URL in practice.

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

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

With no annotations provided, the description must carry the behavioral burden. 'List' strongly implies a read-only operation, but the description does not explicitly state that no data is modified, nor does it mention pagination, default limits, sort order, or authentication requirements.

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

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

The description is two short sentences, front-loads the primary action, and immediately follows with the key filtering distinction. Every sentence earns its place with no wasted wording.

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

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

For a simple list tool with full parameter schema coverage and no output schema, the description covers the essential filtering behavior. It could mention pagination or default limit behavior, but those are absent from annotations and output schema, so the gap is minor for this tool's complexity.

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 input schema already documents limit, search, and workspaceId. The description repeats the workspaceId behavior ('omit for personal presentations') but adds no syntax, defaults, or constraints 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 clear verb ('List') and resource ('presentations'), so the agent can identify the operation. It does not explicitly distinguish itself from siblings like list_templates or get_presentation, but the purpose is still clear from the verb-resource pairing.

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

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

It explains how to filter by workspace versus omitting workspaceId for personal presentations, which is useful context. However, it gives no guidance on when to choose this tool over alternatives such as get_presentation or list_templates, leaving usage largely 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the mandatory ordering constraint and the zero-argument nature of the call, but says nothing about the return shape (e.g., template identifiers) or auth/rate-limit behavior. The workflow requirement is real added value, but coverage is partial.

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

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

Three short sentences, front-loaded with the imperative 'MANDATORY FIRST STEP' so the constraint is the first thing read. The closing sentences are mildly promotional ('perfect spacing, typography, and layout') but they justify why the mandate matters, so they mostly earn their place.

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

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

For a zero-parameter read tool with no output schema, the description covers purpose, prerequisite, and rationale adequately. The main gap is that it never hints at what a template looks like or that the returned template identity is what feeds the subsequent add_slide_from_template call.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema description coverage is reported as 100%, but with an empty properties object there is no parameter semantics to convey.

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 specific verb and resource ('List all available slide templates'), so the agent knows exactly what the call returns. It positions itself against the add-slide workflow rather than naming a sibling tool like add_slide_from_template, so 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 states an explicit precondition ('YOU MUST call this before adding any slides') and explains the consequence of skipping it (templates are the only way to create good-looking slides). This is unambiguous when-to-use guidance with a clear ordering constraint.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return shape (id, name, slug, role) in the absence of an output schema, but says nothing about auth requirements, ordering, pagination, or whether non-active/invited workspaces are included.

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, and the core purpose is front-loaded before the return-value detail. Every clause earns its place.

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

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

For a zero-parameter, no-annotation list tool with no output schema, the description covers what the tool does and what it returns, which is enough to invoke it correctly. It stops short of noting pagination or scope limits, which would be the only remaining useful additions.

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; the baseline for a parameterless tool applies. The schema itself is empty and fully consistent with the description.

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

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

States a specific verb (List) and resource (workspaces) with an explicit scope qualifier: 'the user is a member of'. No sibling tool in the set touches workspaces, so there is no ambiguity to resolve, and the second sentence previews the returned fields.

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

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

Usage is only implied: an agent can infer this is the discovery call to make before referencing a workspace id elsewhere, but the description never says when to use it, what prerequisites exist, or what to do if the list is empty. There are no competing siblings to route away from, so the gap is modest.

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

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

No annotations are provided, so the description carries the full burden. It discloses an important permission constraint (only the creator can move it), which is valuable. However, it does not mention side effects, reversibility, or what happens to sharing/permissions after the move.

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 two concise sentences with zero waste. The primary action and target options are front-loaded, followed by the permission constraint.

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

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

For a simple two-parameter mutation tool with no output schema, the description covers the essential purpose, target semantics, and a critical permission requirement. It leaves out minor behavioral details like side effects or error handling, but it is largely complete for correct invocation.

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

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

Schema description coverage is 100%, and the schema already explains that workspaceId may be omitted or null to move to personal. The description adds no parameter-level detail beyond what the schema provides, 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 states a specific verb (move) and resource (presentation) with explicit scope (different workspace or personal). It clearly distinguishes this operation from sibling tools like update_presentation or create_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?

The description provides clear context for when to use the tool—moving a presentation between workspaces or to personal—and includes a key precondition about creator-only access. It does not explicitly name alternatives or exclusions, but no sibling tool performs this same action.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool updates metadata but does not disclose permissions, whether omitted fields are preserved, side effects, reversibility, or any response behavior. For a mutation tool with zero annotation coverage, that is a notable 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?

The description is two short sentences with no wasted words. Its purpose is front-loaded and the sibling-routing sentence follows directly, making it easy to scan.

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

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

The schema is fully documented, the parameter count is small, and the description clearly separates metadata updates from slide edits. The remaining gap is behavioral detail around the mutation, but for a simple metadata update the definition is close to 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%, and the schema clearly documents id, title, and darkMode. The description adds only the general category 'metadata' and does not provide additional parameter semantics or examples beyond what the schema already contains. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: updating a presentation's metadata. It also distinguishes this tool from the closest sibling, update_slide, by explicitly routing slide content elsewhere. An agent can tell that title and darkMode belong here, while slide edits belong in update_slide.

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

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

The description gives a clear usage boundary by naming update_slide for slide content. However, it does not mention when to use this tool versus presentation-level siblings such as move_presentation or delete_presentation. The guidance is sufficient for the main ambiguity but not fully exhaustive.

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

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

With no annotations, the description carries the full burden and does disclose the single most important trait: the elements array is replaced entirely rather than merged, which is a destructive-adjacent behavior an agent must know. It still omits permissions/ownership requirements and what happens to elements not re-supplied, keeping it short of a 5.

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

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

Front-loaded with the core action and the critical replace behavior, then a scannable rules block. Slightly padded by design rules for font and text color that do not correspond to any input parameter.

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?

No annotations and no output schema, so the description must cover the mutation's consequences; it covers the replace semantics but not ownership/permission requirements or failure modes. For a four-parameter mutation tool this is adequate but leaves meaningful gaps.

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

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

Schema description coverage is 100%, so all four parameters are already documented, giving a baseline of 3. The 'design rules' block restates the backgroundColor constraint already present in the schema ('ALWAYS "default"') and mentions font/text color that are not parameters at all, adding no semantic value.

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

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

States a specific verb and resource ('Update a slide's content') and clarifies scope by noting the elements array is replaced entirely, which distinguishes it from add_slide_from_template or update_presentation. It never names a sibling explicitly, so an agent must infer the boundary from the tool 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?

There is no statement of when to use this tool versus add_slide_from_template, delete_slide, or update_presentation, nor any precondition (e.g., slide must already exist). The replace-semantics sentence hints at usage but is behavioral, not routing guidance.

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