Set speaker notes

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

Annotations declare readOnlyHint=false and openWorldHint=false, and the description usefully adds that notes appear only in presenter view, not to the audience, plus supported Markdown formatting. However, for a 'set' mutation it omits critical behavior: whether existing notes are overwritten, merged, or cleared for unlisted 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?

Two tight sentences with the core action front-loaded. The presenter-view sentence carries real information about where the notes surface, though it is slightly decorative relative to invocation 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?

With only two parameters, no output schema, and sparse annotations, the description is nearly adequate but leaves gaps: overwrite semantics, handling of slides not listed, and behavior for an out-of-range step index. These matter for calling a bulk setter 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 50%: path and step are described, but the notes array and its text field are not. The description partially compensates by specifying Markdown syntax for note text (# heading, - bullet, **bold**), but it never explains whether the array replaces all existing notes or only the listed slides.

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 ('Sets the speaker notes of slides'), which cleanly separates it from on-slide text tools like add_text or update_elements. It does not name a sibling explicitly, so it stops short of a 5.

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

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

The use case is implied by the presenter-view explanation, which tells the agent these are presenter-only notes rather than visible slide content. There is no explicit when-to-use/when-not guidance or named alternative for adding visible text.

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