Skip to main content
Glama

edit_speaker_notes

Set or replace speaker notes on one or more slides using markdown text, converting paragraphs and formatting into OOXML for live PowerPoint updates.

Instructions

Set speaker notes on one or more slides. Accepts markdown text (paragraphs, bold, italic). Converts to OOXML server-side and injects via single-slide reimport. Replaces all existing notes on the specified slides.

Input Schema

NameRequiredDescriptionDefault
notesYesArray of slide notes to set.
presentationIdNoTarget presentation ID from list_presentations. Optional when only one presentation is connected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the destructive overwrite ('Replaces all existing notes'), the accepted input format (markdown), and the server-side mechanism (OOXML conversion, single-slide reimport). It omits return behavior and any failure modes, 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.

Conciseness5/5

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

Four short sentences, front-loaded with purpose, then format, mechanism, and the destructive caveat. Nothing is redundant and every sentence adds a distinct fact an agent needs.

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

Completeness4/5

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

For a 2-parameter write tool with no output schema, the description covers the essentials: what it writes, format, mechanism, and overwrite behavior. The only real gap is not stating what a successful call returns (e.g., confirmation or affected slide indices).

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

Parameters3/5

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, including markdown support and the optional presentationId. The description restates markdown support and 'one or more slides' but adds no semantics 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.

Purpose4/5

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

Opens with a specific verb+resource: 'Set speaker notes on one or more slides.' This clearly distinguishes it from read_speaker_notes in the sibling list by verb alone, but it never names an alternative tool (e.g., edit_slide_xml) for the agent to consider.

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

Usage Guidelines3/5

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

Usage is implied by the verb and by 'Replaces all existing notes on the specified slides,' which warns of overwrite semantics. However, there is no explicit when-to-use/when-not guidance and no pointer to the read-only sibling (read_speaker_notes) or bulk XML editing alternative.

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