Provides tools to read, edit, and export Apple Keynote presentations on macOS. Allows AI agents to manage slides, text, images, shapes, fonts, colors, and layouts in Keynote documents programmatically.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@keynote-mcp Get a design snapshot of the current presentation."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local macOS MCP server that reads, edits, and exports Apple Keynote presentations via JXA (JavaScript for Automation). Enables Claude to visually analyze slides, apply design changes, and iterate on presentations directly — without any third-party tools.
macOS with Apple Keynote installed
Node.js 20+
Keynote must be running with at least one document open
Related MCP server: Keynote-MCP
git clone https://github.com/tszaks/keynote-mcp
cd keynote-mcp
npm install && npm run buildAdd to ~/.mcp.json:
{
"mcpServers": {
"keynote-mcp": {
"type": "stdio",
"command": "/opt/homebrew/bin/node",
"args": ["/path/to/keynote-mcp/dist/index.js"]
}
}
}Restart Claude Code. Tools appear as mcp__keynote-mcp__keynote_*.
All tools accept doc_index (0-based, defaults to 0 = frontmost document). Elements are addressed by slide_index (0-based) + element_type (textItem, imageItem, shapeItem) + element_index (0-based within that collection). Colors are [r, g, b] with values 0–255. Slide coordinates are in points; standard Keynote slide is 1920×1080 pts.
keynote_list_presentationsList all open Keynote documents.
Input: {}
Output: [{ index, name, slideCount, modified, filePath }]keynote_get_presentation_infoGet slide count and available master slide names. Call this first before redesigning — you need master names to call keynote_apply_master.
Input: { doc_index? }
Output: { name, slideCount, masterSlides: string[], filePath, modified }keynote_get_slideGet the full element tree for one slide: all text boxes, images, and shapes with position, size, font, font size, and color.
Input: { doc_index?, slide_index }
Output: {
slideIndex, masterSlide, skipped, elementCount,
elements: [{
type: "textItem" | "imageItem" | "shapeItem",
index,
text?, // textItem only
font?, // textItem only
fontSize?, // textItem only
color?, // textItem only — [r,g,b] 0-255
fillColor?, // shapeItem only — [r,g,b] 0-255
fileName?, // imageItem only
position: { x, y },
size: { w, h }
}]
}keynote_export_slide_imageExport a single slide as PNG. Returns the file path — use the Read tool on that path to see the slide visually.
Input: { doc_index?, slide_index }
Output: { filePath, slideIndex, exportDir }keynote_export_all_slidesExport all slides as PNG to ~/Library/Caches/keynote-mcp/<doc>/. Returns array of file paths.
Input: { doc_index? }
Output: { exportDir, slideCount, files: string[] }keynote_get_design_snapshotBest starting point for redesign. One call that exports all slides as PNG AND returns the full element tree for every slide.
Input: { doc_index? }
Output: {
presentationName, slideCount, exportDir,
slideImages: string[], // PNG file paths — Read these for visual analysis
slides: SlideData[] // full element trees
}keynote_set_textReplace the text content of a text element. Preserves existing font styling.
Input: { doc_index?, slide_index, element_type: "textItem", element_index, text }keynote_set_fontSet font family, size, and/or color on a text element. Omit any field to leave it unchanged.
Input: {
doc_index?, slide_index,
element_type: "textItem", element_index,
font_name?, // e.g. "SF Pro Display", "Helvetica Neue", "Didot"
font_size?, // points
color? // [r,g,b] 0-255
}keynote_set_element_positionMove an element. x = distance from left edge, y = distance from top edge, both in points.
Input: { doc_index?, slide_index, element_type, element_index, x, y }keynote_set_element_sizeResize an element.
Input: { doc_index?, slide_index, element_type, element_index, width, height }keynote_set_slide_backgroundSet slide background to a solid color. May fail if the slide's master has a locked background — apply a blank master first with keynote_apply_master.
Input: { doc_index?, slide_index, color: [r,g,b] }keynote_set_element_fill_colorSet the fill color of a shape element.
Input: { doc_index?, slide_index, element_type: "shapeItem", element_index, color: [r,g,b] }keynote_add_text_boxAdd a new text box to a slide.
Input: { doc_index?, slide_index, text?, x?, y?, width?, height? }
Output: { added, slideIndex, newElementIndex }keynote_add_shapeAdd a rectangle or oval shape, with optional fill color.
Input: { doc_index?, slide_index, x?, y?, width?, height?, fill_color?: [r,g,b] }
Output: { added, slideIndex, newElementIndex }keynote_delete_elementRemove an element from a slide. Keynote undo (Cmd+Z) still works in the app.
Input: { doc_index?, slide_index, element_type, element_index }keynote_apply_masterApply a master slide to one slide or all slides. Get valid master names from keynote_get_presentation_info.
Input: { doc_index?, master_name, slide_index? }
// Omit slide_index to apply to all slideskeynote_add_slideAppend a new blank slide at the end.
Input: { doc_index? }
Output: { added, newSlideIndex, slideCount }keynote_delete_slideDelete a slide.
Input: { doc_index?, slide_index }keynote_duplicate_slideDuplicate a slide. The copy is inserted immediately after the original.
Input: { doc_index?, slide_index }1. keynote_get_design_snapshot → get all slide images + element trees
2. Read(slideImages[0]) → see slide 0 visually
3. Read(slideImages[1]) → see slide 1 visually
...
4. Identify issues: inconsistent fonts, low contrast, crowded layouts
5. Apply fixes with set_font / set_element_position / set_slide_background
6. keynote_export_slide_image → verify the result visually1. keynote_get_slide for each slide → collect all font names and sizes
2. Identify the dominant font family
3. keynote_set_font on outliers to match1. keynote_export_slide_image → see current state
2. keynote_get_slide → get element positions and sizes
3. Apply repositions, resizes, font changes
4. keynote_export_slide_image → verify resultExport requires a saved file — if filePath is empty in list_presentations, save the document first (Cmd+S). Export will fail on unsaved presentations.
Element positions return 0,0 for some Keynote layouts — this is a JXA limitation with certain master/layout combinations. Text content and font data are unaffected.
Background color changes may be blocked by master slide locks. Use keynote_apply_master with a blank master first.
No animation access — JXA does not expose Keynote transition or build animation properties.
Image content is not readable — imageItem elements return file name and dimensions only, not pixel data.
TypeScript MCP server using the @modelcontextprotocol/sdk. All Keynote interaction goes through JXA (JavaScript for Automation) via osascript -l JavaScript. Operations and payloads are passed as environment variables; results return as a JSON envelope { ok: boolean, result? | error? } on stdout.
Follows the same pattern as reminders-mcp, safari-mcp, and other local macOS MCP servers in the same ecosystem.
Add a new shape (rectangle or oval) to a slide. Optionally set a fill color.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| x | No | X position in points. | |
| y | No | Y position in points. | |
| width | No | Width in points. | |
| height | No | Height in points. | |
| fill_color | No | Optional fill color [r, g, b] 0–255. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only mentions adding a shape and optional fill color, but does not disclose side effects (e.g., does it replace existing shapes?), requirements, or error conditions.
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 sentence, which is appropriate in length, but it lacks critical information such as shape type selection. It is concise but not fully informative.
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 7 parameters, no output schema, and no annotations, the description is far too minimal. It does not explain the coordinate system, default values, or what the tool returns. It is incomplete for a complex 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 coverage is 100%, so baseline is 3. The description adds that shapes are 'rectangle or oval', which is not in the schema, but omits how to specify the shape type (no parameter for it). This adds some value but leaves a 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 description clearly states the verb 'Add', the resource 'shape', and specifies the types 'rectangle or oval'. It also mentions optional fill color. This distinguishes it from sibling tools like keynote_add_text_box and keynote_add_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 provides no guidance on when to use this tool versus alternatives (e.g., keynote_add_text_box for text). No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new blank slide at the end of the presentation.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description indicates a mutation (adds a slide), which is appropriate. No misleading statements.
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?
Single sentence, no unnecessary words. Efficiently conveys the entire 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?
Given the simplicity (no output schema, one optional param), the description is fully adequate to understand the tool's 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%, but description does not elaborate on doc_index beyond schema. Baseline score applied.
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?
Clearly states the action (Add), resource (new blank slide), and location (at the end). Distinguished from siblings like duplicate_slide or delete_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?
No explicit when-to-use or alternative guidance, but the purpose is straightforward and siblings are distinct enough that usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new text box to a slide at a specified position and size.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| text | No | Initial text content. | |
| x | No | X position in points. | |
| y | No | Y position in points. | |
| width | No | Width in points. | |
| height | No | Height in points. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that a text box is added. It lacks details on mutation, error handling, side effects (e.g., modifying the slide), or behavior with invalid indices. Minimal behavioral disclosure.
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 concise sentence with no wasted words. It is front-loaded with the action and resource.
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 complexity (7 parameters, 1 required) and lack of annotations and output schema, the description is too sparse. It fails to mention coordinate system, default values, or any important context for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description reiterates 'specified position and size' but adds no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add), the resource (text box), and the context (to a slide at a specified position and size). It distinguishes from siblings like keynote_add_shape and keynote_add_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 provides no guidance on when to use this tool versus alternatives, nor does it mention any constraints, prerequisites, or explicit exclusions. The user must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a master slide to one slide or all slides. Use keynote_get_presentation_info first to see available master names. Applying a blank master before color changes can help unlock the background.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| master_name | Yes | Exact name of the master slide (case-sensitive). | |
| slide_index | No | Slide to apply to (0-based). Omit to apply to all slides. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not mention whether the operation is destructive, reversible, or requires permissions, leaving the agent unaware of risks.
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 concise sentences: first states purpose, second gives prerequisite, third offers a tip. No redundant 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?
Covers core action, prerequisite, and a common use case tip. Missing error behavior or return value, but adequate for a simple operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting baseline at 3. The description adds context for master_name (using keynote_get_presentation_info) and slide_index (one or all slides), but does not deeply explain parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies a master slide to one or all slides, with a specific verb and resource, and differentiates from sibling tools like keynote_add_slide by specifying the scope.
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 a prerequisite (use keynote_get_presentation_info first) and a tip for blank masters, but lacks explicit guidance on when to use this tool versus alternatives like keynote_set_slide_background.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an element from a slide. Use with care — this cannot be undone via the MCP. Keynote undo (Cmd+Z) still works in the app.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| element_type | Yes | Element collection to target. | |
| element_index | Yes | Element index within its collection (0-based). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must communicate behavioral traits. It discloses that the action is destructive and irreversible via MCP but reversible in the app. This is sufficient for a simple delete operation.
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 sentences long: the first states the purpose, the second adds a caution. It is front-loaded, contains no superfluous words, and 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?
The description lacks information about return values, error cases (e.g., invalid indices), or what happens after deletion. While the tool is simple, the absence of output schema and error handling guidance leaves gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so the description adds no additional meaning beyond what is already present. The baseline score 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 clearly states the action: 'Delete an element from a slide.' It uses a specific verb and resource, and distinguishes from sibling tools like keynote_delete_slide (which deletes slides) and other element manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that the deletion 'cannot be undone via the MCP' and suggests using Keynote undo as an alternative. This provides clear context for when to use the tool cautiously, though it does not explicitly list alternative tools for non-destructive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a slide from the presentation.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'delete' but does not mention permanence, reversibility, or side effects like reindexing of subsequent slides. For a destructive operation, this is insufficient.
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 sentence that directly states the action. No unnecessary words or filler. It is appropriately concise for a simple deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and no output schema. The description is minimal: it explains what the tool does but lacks context about safety (e.g., whether deletion is irreversible), dependencies (e.g., the presentation must be open), or the effect on other slides. It is adequate for a simple tool but not 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 coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a slide, which is a specific verb+resource. However, it does not distinguish from the sibling tool 'keynote_delete_element' which deletes an element rather than a slide, so the purpose is clear but lacks 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?
No guidance on when to use this tool vs alternatives. It does not mention that deleting a slide is different from deleting an element (keynote_delete_element) or that it might affect slide indexing. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a slide. The copy is inserted immediately after the original.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the key behavior of insertion location. However, it does not mention other relevant details such as whether the duplicate inherits all properties or if there are any side effects on slide numbering.
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 with zero waste. The main purpose is stated first, followed by a specific behavioral detail. Perfectly concise.
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 duplication tool, the description covers the core behavior and parameters are documented in schema. It could mention that duplication occurs within the same presentation and copies all content, but is largely sufficient.
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% (both parameters have descriptions). The tool description adds no additional meaning beyond the schema, so 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 clearly states the action 'Duplicate a slide' and specifies the resource. The behavior 'the copy is inserted immediately after the original' further clarifies the tool's effect, distinguishing it from siblings like keynote_add_slide which adds a new blank 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 implies the tool is used when duplicating a slide but provides no explicit guidance on when to use it versus alternatives (e.g., keynote_add_slide) or any prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export all slides as PNG images to /tmp/keynote-mcp-export/. Returns the list of file paths. Use Read on each path to visually analyze slides.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the export location and return value, but does not mention potential side effects (e.g., overwriting files, directory creation) or performance implications for many 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 sentences, front-loaded with the core purpose. Every word adds value, 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?
For a simple export tool with one optional parameter and no output schema, the description covers the action, destination, and return value adequately. It could mention that all slides are exported unconditionally.
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% for the single parameter doc_index, and the description adds no additional meaning beyond the schema's own 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?
The description clearly states the verb (export), resource (all slides), format (PNG), and destination (/tmp/keynote-mcp-export/). It effectively distinguishes from the sibling keynote_export_slide_image by scope.
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 a follow-up instruction ('Use Read on each path to visually analyze slides'), indicating a typical workflow. The purpose is clear from the name and description, but it lacks an explicit when-to-use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a single slide as a PNG image. Returns the file path. Use the Read tool on that path to visually analyze the slide with vision.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it returns a file path and suggests using Read tool. Does not disclose potential side effects (e.g., file creation location, overwrite behavior) or permissions needed.
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, no wasted words. Front-loaded with the main action and output, then provides follow-up instruction.
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 simple tool behavior and no output schema, the description sufficiently covers purpose, output, and next steps for the agent.
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 covers both parameters with descriptions (100% coverage). Description does not add further detail beyond what schema provides, so baseline score 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?
Clearly states 'Export a single slide as a PNG image' and mentions return value. Distinct from sibling 'keynote_export_all_slides' which exports all 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?
Explicitly instructs to use the Read tool on the returned path for visual analysis. Implicitly distinguishes from export all slides by specifying 'single slide'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call setup for redesign: exports all slides as PNG images AND returns the full element tree for every slide. This is the best starting point for a full presentation redesign or polish pass.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the dual action but omits behavioral traits like read-only nature, performance impact, or prerequisites. More detail on side effects or limitations is needed.
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 'One-call setup for redesign,' and every word adds value. 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?
The description covers the main functionality but lacks details on return format, prerequisites, or how to handle outputs. For a combined export and tree retrieval tool, more completeness would help agent usage.
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% for the single parameter doc_index. The description adds no extra meaning beyond 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?
The description clearly states the tool exports all slides as PNG images and returns the full element tree for every slide, distinguishing it from siblings like keynote_export_all_slides (images only) and keynote_get_slide (single slide info). It positions it as a starting point for redesign.
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 frames usage for 'full presentation redesign or polish pass,' providing context. However, it lacks explicit when-not-to-use or alternatives, though siblings imply other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for an open presentation: slide count, available master slide names, and file path. Call this first to understand what masters are available before redesigning.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately describes the read-only metadata (slide count, master names, file path) and implies the presentation must be open. While it lacks explicit safety notes, it is not misleading and covers key behavioral aspects.
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, concise sentence (20 words) that front-loads the return items and ends with a usage hint. Every element is meaningful 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?
For a simple tool with one optional parameter and no output schema, the description adequately explains what it returns and when to use it. It could mention that doc_index defaults to frontmost, but that is covered in the 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 description coverage is 100% (doc_index fully described in schema). The description adds no additional parameter details 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 clearly states the verb 'Get' and the resource 'metadata for an open presentation', specifying three concrete data items (slide count, master names, file path). This differentiates it from sibling tools that focus on slide or element actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first to understand what masters are available before redesigning', providing clear context for when to use. It does not mention when not to use or alternatives, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full element tree for a single slide: all text boxes, images, and shapes with their position, size, font, and color. Use this to understand the structure of a slide before editing it.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-only nature and the data returned (element types and attributes). With no annotations, it covers the key behavioral aspect. Additional details like response size are not necessary.
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, no fluff. First sentence defines purpose and output, second sentence gives usage context. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool returns (element types and attributes) and when to use it, which is adequate for a simple retrieval tool with only two parameters. Could optionally mention the tree structure format.
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. The description does not add extra meaning to the parameters beyond what the schema provides (doc_index, slide_index with defaults and required).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full element tree for a slide, listing specific element types and attributes. This distinctly separates it from sibling tools that modify slides or elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to understand slide structure before editing, providing clear context. It does not mention alternatives or when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently open Keynote presentations. Returns index, name, slide count, and file path for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it lists all open presentations, implying a read operation, but does not disclose behavior on empty state, performance, or any side effects. Adequate but minimal.
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 sentence with 13 words, front-loaded with the action, and no superfluous content. It 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 tool with no parameters and no output schema, the description is largely complete: it states what it does and what it returns. It could mention edge cases (e.g., no open presentations) but is otherwise sufficient.
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?
There are no parameters. Schema coverage is 100% by default. The description adds no parameter info because none exist, which is acceptable per the baseline of 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'currently open Keynote presentations', and the returned fields (index, name, slide count, file path). It is specific and distinguishes itself from sibling tools that perform other actions.
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 implies usage when the agent needs to know open presentations, but provides no explicit guidance on when to use alternatives. No exclusions or context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the fill color of a shape element.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| element_type | Yes | Element collection to target. | |
| element_index | Yes | Element index within its collection (0-based). | |
| color | Yes | RGB color as [r, g, b] with values 0–255 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states 'change the fill color' without mentioning that this replaces the entire fill with a solid color, whether it is reversible, or what happens to existing fill effects like gradients or images.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one short sentence, but it omits key context. The structure is front-loaded but not all sentences earn their place; a single sentence is acceptable but fails to add value beyond 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?
Given no annotations and a mutation tool that modifies a presentation, the description lacks completeness. It does not explain error conditions (e.g., invalid indices, non-existent shape), return value, or that changes are immediate and persistent. The output schema is absent, but the description fails to compensate.
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 already describes each parameter (doc_index, slide_index, element_type, element_index, color). The description adds no extra meaning beyond the action, meeting the baseline for a well-documented 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 specifies the verb 'change', the resource 'fill color', and targets 'shape element', which aligns with the element_type enum. It distinguishes from sibling tools that set position or size, but could be more explicit about the fill type (solid, gradient) and that it applies only to the 'shapeItem' collection.
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 guidance on when to use this tool versus alternatives like keynote_set_element_position or keynote_set_font. Does not mention prerequisites (e.g., shape must already exist) or when not to use it (e.g., for non-shape elements).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move an element to a new position on the slide. Coordinates are in points from the top-left corner. Keynote standard slide is 1920×1080 pts.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| element_type | Yes | Element collection to target. | |
| element_index | Yes | Element index within its collection (0-based). | |
| x | Yes | Horizontal position in points (from left edge). | |
| y | Yes | Vertical position in points (from top edge). |
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 states 'Move an element to a new position,' which implies a destructive mutation (changing state). However, it does not disclose whether the change is reversible, requires authentication, or has any side effects on other elements. The coordinate system details are helpful but insufficient for behavioral transparency.
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 sentences, front-loaded with the primary action, and contains no filler. Every word adds essential meaning: the action, coordinate units, and slide dimensions are all directly useful for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, yet the description does not explain what the tool returns (e.g., success indicator) or mention preconditions like the element must exist. While the coordinate information is good, the description is incomplete for an agent to understand the full context of invocation and results.
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 baseline is 3. The description adds value by clarifying the coordinate system (points from top-left) and standard slide size, which aids understanding of 'x' and 'y' parameters. However, it does not provide extra meaning beyond what the schema already offers for each 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?
The description clearly states the tool moves an element to a new position, specifying the coordinate system as points from the top-left and the standard slide dimensions (1920x1080). This verb-resource combination ('Move an element') is specific and distinguishes it from sibling tools like 'keynote_set_element_size' which handles resizing.
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 no guidance on when to use this tool versus alternatives. Sibling tools like 'keynote_set_element_size' or 'keynote_set_element_fill_color' perform different modifications, but the description does not explicitly say 'use this for repositioning, not for other adjustments.' No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize an element on the slide. Dimensions are in points.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| element_type | Yes | Element collection to target. | |
| element_index | Yes | Element index within its collection (0-based). | |
| width | Yes | Width in points. | |
| height | Yes | Height in points. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that dimensions are in points but does not disclose whether the resize is relative or absolute, whether constraints apply, or what side effects (e.g., overlapping) may occur. This is minimal for a mutation operation.
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 exceptionally concise at two sentences, front-loading the purpose and including only essential information. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks information about return values (e.g., success indicator or new size) and does not mention error conditions or constraints (e.g., size limits). For a mutation tool without output schema or annotations, this is insufficient.
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 adds no additional meaning beyond the schema's parameter descriptions, except possibly reinforcing the unit (points) which is already implied by 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 clearly states the action ('Resize') and the target resource ('an element on the slide'), and distinguishes this tool from siblings like keyboard_set_element_position or keynote_set_element_fill_color by specifying 'size'. The unit clarification ('Dimensions are in points') adds precision.
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 guidance is provided on when to use this tool versus alternatives (e.g., when to set position vs size). There is no mention of prerequisites, order of operations, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set font family, size, and/or color on a text element. Any omitted fields are left unchanged. Use this to enforce typographic consistency across slides.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| element_type | Yes | Element collection to target. | |
| element_index | Yes | Element index within its collection (0-based). | |
| font_name | No | Font family name, e.g. "SF Pro Display", "Helvetica Neue". | |
| font_size | No | Font size in points. | |
| color | No | Text color as [r, g, b] 0–255. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that omitted fields are left unchanged, a key behavioral trait, but does not detail error handling or validate permissions/effects beyond that. Partial update behavior is well communicated.
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, no filler. First sentence defines the action and partial update; second sentence suggests a use case. Every sentence is purposeful and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (3 required, no output schema), the description covers the essential action, the partial update nature, and a use case. It could elaborate on return values or error states, but for a simple mutation tool, it is sufficiently 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 coverage is 100% with parameter descriptions. The description adds value by summarizing the three font-related parameters and explicitly stating the partial update behavior ('Any omitted fields are left unchanged'), which is not fully clear from 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?
The description clearly states 'Set font family, size, and/or color on a text element,' specifying the verb, resource, and what can be set. It distinguishes from siblings like keynote_set_text (which sets content) and keynote_set_element_fill_color (fill).
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 usage context with 'Use this to enforce typographic consistency across slides,' but does not explicitly exclude cases or name alternatives for when not to use it. It gives a clear context without deep guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the background color of a slide to a solid color. Use this to establish a consistent color palette across all slides.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| color | Yes | RGB color as [r, g, b] with values 0–255 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states the basic action without mentioning side effects (e.g., overwriting existing background, undo capabilities, permission requirements). The description is insufficient 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?
Extremely concise: two sentences, no unnecessary words. The purpose and use case are front-loaded. Every sentence contributes meaning.
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 no output schema and annotations, the description should cover what happens after the tool runs (e.g., immediate visual change). It only states the action and a use case, leaving out completeness about behavior and return value.
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?
Input schema has 100% coverage, with clear descriptions for all three parameters. The description adds no extra meaning beyond the schema, adhering to the baseline of 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?
The description clearly states it changes the slide background to a solid color, specifying 'solid color' which differentiates it from gradients or images. However, it does not explicitly differentiate from siblings like keynote_set_element_fill_color, but the resource is clearly the slide background.
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 use case: 'establish a consistent color palette across all slides.' This gives some context for when to use, but lacks explicit when-not-to-use or alternatives. No mention of prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the text content of a text element on a slide. Preserves existing font styling.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_index | No | Document index (0-based). Defaults to 0 (frontmost). | |
| slide_index | Yes | Slide index (0-based). | |
| element_type | Yes | Element collection to target. | |
| element_index | Yes | Element index within its collection (0-based). | |
| text | Yes | New text content. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral info: it replaces text and preserves styling. It doesn't disclose side effects like undo implications or behavior on non-text elements.
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 sentence without unnecessary words, but could be slightly expanded for completeness without losing conciseness.
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?
Missing output schema, and the description doesn't mention return value or behavior on invalid indices. For a 5-param tool with no output schema, it provides only basic purpose but not enough context for complete usage.
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 description adds no extra parameter meaning. Baseline 3 is appropriate as schema already documents each 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?
The description clearly states it replaces text content of a text element on a slide, and distinguishes itself by noting preservation of font styling, which differentiates it from sibling tools like keynote_set_font.
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 guidance on when to use this tool vs alternatives. The description does not mention prerequisites, scenarios to avoid, or when to prefer sibling tools like keynote_add_text_box.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action on specific elements (slides, shapes, text boxes, masters, exports, queries). No two tools have overlapping purposes, ensuring clear differentiation for an agent.
All tools follow a consistent 'keynote_verb_noun' pattern in snake_case, making the tool set predictable and easy to navigate for both agents and humans.
19 tools is on the higher side but appropriate for Keynote's complexity. Each tool serves a specific need, covering slides, elements, masters, exports, and queries without redundancy.
The set covers core slide and element manipulation (CRUD, styling, positioning, export). Minor gaps exist (e.g., no grouping or image insertion), but the surface is sufficient for common redesign and editing tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Presentations.AI MCP server — create designed slide decks from a topic, text, or document.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
Generate, render, and host Slidev presentations from markdown
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tszaks/keynote-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
