The PowerPoint MCP Server allows you to programmatically create, modify, and manage PowerPoint presentations with various features:
Create & Edit: Create new presentations or open and edit existing ones (with automatic backups)
Add Various Slides: Insert title slides, section headers, content slides, comparison slides, and slides with tables, charts, or images
Dynamic Content: Generate tables and charts from provided data
Image Capabilities: Generate images via Stable Diffusion API or use existing images
Save & Export: Save presentations to specified folders
Integration: Works with MCP clients like Claude Desktop for seamless workflow integration
Configuration: Supports environment variables for API access and file paths
Click on "Deploy 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., "@PowerPoint MCP Server create a presentation about quarterly sales with a title slide, section headers, and charts"
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.
A MCP server project that creates powerpoint presentations
Uses Stable Diffusion (ForgeUI/Automatic-1111) API instead of together ai.
Related MCP server: PowerPoint Editor MCP Server
The server implements multiple tools:
create-presentation: Starts a presentation
Takes "name" as required string arguments
Creates a presentation object
add-slide-title-only: Adds a title slide to the presentation
Takes "presentation_name" and "title" as required string arguments
Creates a title slide with "title" and adds it to presentation
add-slide-section-header: Adds a section header slide to the presentation
Takes "presentation_name" and "header" as required string arguments
Creates a section header slide with "header" (and optionally "subtitle") and adds it to the presentation
add-slide-title-content: Adds a title with content slide to the presentation
Takes "presentation_name", "title", "content" as required string arguments
Creates a title with content slide with "title" and "content" and adds it to presentation
add-slide-title-with-table: Adds a title slide with a table
Takes "presentation_name", "title", "data" as required string and array arguments
Creates a title slide with "title" and adds a table dynamically built from data
add-slide-title-with-chart: Adds a title slide with a chart
Takes "presentation_name", "title", "data" as required string and object arguments
Creates a title slide with "title" and adds a chart dynamically built from data. Attempts to figure out the best type of chart from the data source.
add-slide-picture-with-caption: Adds a picture with caption slide
Takes "presentation_name", "title", "caption", "image_path" as required string arguments
Creates a picture with caption slide using the supplied "title", "caption", and "image_path". Can either use images created via the "generate-and-save-image" tool or use an "image_path" supplied by the user (image must exist in folder_path)
open-presentation: Opens a presentation for editing
Takes "presentation_name" as required arguments
Opens the given presentation and automatically saves a backup of it as "backup.pptx"
This tool allows the client to work with existing pptx files and add slides to them. Just make sure the client calls "save-presentation" tool at the end.
save-presentation: Saves the presentation to a file.
Takes "presentation_name" as required arguments.
Saves the presentation to the folder_path. The client must call this tool to finalize the process.
generate-and-save-image: Generates an image for the presentation using a T2I model
Takes "prompt" and "file_name" as required string arguments
Creates an image using stable diffusion api (ForgeUI/Automatic1111)
An environment variable is required for image generation via ForgeUI API
"env":
{
"SD_WEBUI_URL": "http://your-sd-webui-url:7860",
"SD_AUTH_USER": "your-username", // Optional: if authentication is enabled
"SD_AUTH_PASS": "your-password", // Optional: if authentication is enabled
}A folder_path is required. All presentations and images will be saved to this folder.
"--folder-path",
"/path/to/decks_folder"MacOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | shWindows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"git clone https://github.com/Ichigo3766/powerpoint-mcp.gitOn MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
--directory: the path where you cloned the repo above (ex: /full/path/to/powerpoint-mcp/src)
--folder-path: the path where powerpoint decks and images will be saved to. Also the path where you should place any images you want the MCP server to use.
# Add the server to your claude_desktop_config.json
"mcpServers": {
"powerpoint": {
"command": "uv",
"env": {
"SD_WEBUI_URL": "http://your-sd-webui-url:7860",
"SD_AUTH_USER": "your-username", // Optional: if authentication is enabled
"SD_AUTH_PASS": "your-password", // Optional: if authentication is enabled
},
"args": [
"--directory",
"/path/to/powerpoint",
"run",
"powerpoint",
"--folder-path",
"/path/to/decks_folder"
]
}
}Create a presentation about fish, create some images and include tables and chartsCreate a presentation about the attached paper. Please use the following images in the presentation:
author.jpegAssuming you have SQLite MCP Server installed.
Review 2024 Sales Data table. Create a presentation showing current trends, use tables and charts as appropriateThis project is a fork of powerpoint by supercurses, with additional features and modifications. The original project provided the foundation for this MCP server.
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
Add a new a comparison slide with title and comparison content. Use when you wish to compare two concepts
| Name | Required | Description | Default |
|---|---|---|---|
| left_side_content | Yes | Content/body text of left concept. Separate main points with a single carriage return character.Make sub-points with tab character.Do not use bullet points, asterisks or dashes for points.Max main points is 4 | |
| left_side_title | Yes | Title of the left concept | |
| presentation_name | Yes | Name of the presentation to add the slide to | |
| right_side_content | Yes | Content/body text of right concept. Separate main points with a single carriage return character.Make sub-points with tab character.Do not use bullet points, asterisks or dashes for points.Max main points is 4 | |
| right_side_title | Yes | Title of the right concept | |
| title | Yes | Title of the slide |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states 'Add a new comparison slide,' implying a write/mutation operation, but doesn't disclose critical behavioral traits such as whether this requires specific permissions, if it modifies existing presentations, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant 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 extremely concise with two sentences that directly state the purpose and usage guidelines. Every word earns its place, and it's front-loaded with the core functionality. There's no wasted verbiage or 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?
Given the complexity of a 6-parameter mutation tool with no annotations and no output schema, the description is incomplete. It adequately covers purpose and basic usage but lacks behavioral details (e.g., side effects, permissions) and output information. The schema provides parameter documentation, but the description doesn't compensate for the missing behavioral context, making it minimally viable but with clear 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 the schema already documents all 6 parameters thoroughly. The description mentions 'title and comparison content,' which aligns with parameters like 'title,' 'left_side_title,' and 'right_side_title,' but doesn't add meaningful semantics beyond what the schema provides. 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 clearly states the verb 'Add' and the resource 'comparison slide' with specific content elements (title and comparison content). It distinguishes the tool's purpose from siblings by focusing on comparison slides rather than other slide types like pictures, tables, or charts. However, it doesn't explicitly differentiate from all sibling tools (e.g., 'add-slide-title-content' could be similar).
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 explicit usage guidance with 'Use when you wish to compare two concepts,' which clearly indicates the appropriate context. It doesn't specify when NOT to use this tool or name alternative tools, but the context is sufficiently clear for an agent to understand its purpose relative to the sibling tools listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new slide with a picture and caption to an existing presentation
| Name | Required | Description | Default |
|---|---|---|---|
| caption | Yes | Caption text to appear below the picture | |
| image_path | Yes | Path to the image file to insert | |
| presentation_name | Yes | Name of the presentation to add the slide to | |
| title | Yes | Title of the slide |
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 the tool adds a slide, implying a write/mutation operation, but doesn't disclose behavioral traits such as permissions needed, whether it modifies the presentation in-place or creates a copy, error handling for invalid inputs, or what happens if the presentation doesn't exist. This leaves significant gaps 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?
The description is a single, efficient sentence that front-loads the core action ('Add a new slide with a picture and caption') and context ('to an existing presentation'). There is no wasted wording, making it highly 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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or return values, which are critical for safe usage. The high schema coverage helps with parameters, but overall context for tool invocation is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters clearly documented in the schema (e.g., 'caption' as 'Caption text to appear below the picture'). The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions, constraints, or examples. Baseline 3 is appropriate when 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 clearly states the verb 'add' and resource 'new slide with a picture and caption to an existing presentation', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'add-slide-title-content' or 'add-slide-title-with-chart', which also add slides but with different content types.
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 like 'add-slide-title-with-chart' or 'create-presentation'. It mentions adding to 'an existing presentation', which implies a prerequisite but doesn't clarify when this specific slide type is appropriate compared to other slide-adding tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool adds a section header (a.k.a segue) slide to the presentation you are working on. The tool doesn't return anything. It requires the presentation_name to work on.
| Name | Required | Description | Default |
|---|---|---|---|
| header | Yes | Section header title | |
| presentation_name | Yes | Name of the presentation to add the slide to | |
| subtitle | No | Section header subtitle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'The tool doesn't return anything,' which is useful for setting expectations, and implies a mutation ('adds'). However, it lacks critical details like whether this requires specific permissions, if changes are reversible, or potential side effects (e.g., affecting other slides). For a mutation tool with zero annotation coverage, this is inadequate.
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 appropriately sized with two sentences that are front-loaded: the first states the purpose, and the second covers behavioral and prerequisite info. There's minimal waste, though the phrase 'a.k.a segue' could be slightly redundant. Overall, it's efficient 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?
Given the tool's complexity (a mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It covers the basic action and non-return behavior but misses critical context like error handling, what 'adds' entails (e.g., insertion position), or how it interacts with sibling tools. This leaves significant gaps for an AI 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 description coverage is 100%, so the schema already documents all parameters (header, presentation_name, subtitle) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as formatting examples or constraints. 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 clearly states the verb ('adds') and resource ('section header slide to the presentation'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from its siblings (e.g., 'add-slide-title-content'), which would require a 5. The mention of 'section header (a.k.a segue)' adds helpful context but not sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by stating 'requires the presentation_name to work on,' which is a prerequisite but not usage context. It lacks explicit when-to-use instructions, alternatives (e.g., vs. other add-slide-* tools), or exclusions, leaving the agent with no clear direction on when this tool is appropriate versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new slide with a title and content to an existing presentation
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content/body text of the slide. Separate main points with a single carriage return character.Make sub-points with tab character.Do not use bullet points, asterisks or dashes for points.Max main points is 4 | |
| presentation_name | Yes | Name of the presentation to add the slide to | |
| title | Yes | Title of the slide |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'add a new slide' which implies a write operation, but doesn't cover permissions, whether changes are saved automatically, error handling, or what happens if the presentation doesn't exist. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It wastes no words and directly communicates the tool's function without unnecessary elaboration, making it easy to parse quickly.
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's complexity (a write operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, success/failure responses, or how it integrates with sibling tools, leaving the agent with insufficient context for reliable use.
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 all three parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain the relationship between parameters or provide usage examples). 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 clearly states the verb 'add' and resource 'new slide with a title and content to an existing presentation', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add-slide-title-only' or 'add-slide-title-with-chart', which would require mentioning what makes this tool unique (e.g., 'content' vs 'only title' or 'with chart').
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. With siblings like 'add-slide-title-only' and 'add-slide-title-with-chart', it fails to specify scenarios where adding content is preferred over other slide types or when to choose this over creating a new presentation. No exclusions 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.
This tool adds a new title slide to the presentation you are working on. The tool doesn't return anything. It requires the presentation_name to work on.
| Name | Required | Description | Default |
|---|---|---|---|
| presentation_name | Yes | Name of the presentation to add the slide to | |
| title | Yes | Title of the slide |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that 'The tool doesn't return anything' (helpful behavioral trait) and mentions the presentation_name requirement, but doesn't address other important behaviors like whether this is a mutation operation, what happens if the presentation doesn't exist, or if there are permission 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?
Two sentences that are reasonably efficient. The first sentence states the purpose clearly, and the second provides important behavioral information. Could be slightly more concise by combining ideas, but overall well-structured with key information front-loaded.
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 mutation tool with no annotations and no output schema, the description provides basic purpose and one behavioral trait (no return value), but lacks important context about mutation effects, error conditions, or how this integrates with the presentation workflow. It's minimally adequate but has clear 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 the schema already documents both parameters completely. The description adds minimal value by mentioning 'presentation_name' requirement but doesn't provide additional semantic context beyond what's in the schema descriptions.
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 specific action ('adds a new title slide'), the resource ('presentation you are working on'), and distinguishes it from siblings by specifying 'title slide' only, unlike other title-related tools that include additional content like charts or tables.
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 needing a title-only slide, but doesn't explicitly state when to use this vs. alternatives like 'add-slide-title-content' or 'add-slide-title-with-chart'. It mentions the requirement of 'presentation_name' but doesn't provide broader context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new slide with a title and chart. The chart type will be automatically selected based on the data structure.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Chart data structure | |
| presentation_name | Yes | Name of the presentation to add the slide to | |
| title | Yes | Title of the slide |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds a slide with a title and chart, implying a write operation, but lacks details on permissions, side effects (e.g., modifies an existing presentation), error handling, or response format. The automatic chart selection is noted, but no further behavioral traits like rate limits or idempotency are described.
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, efficient sentence that front-loads the core action and key features. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from behavioral notes for clarity.
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 (3 parameters with nested objects, no output schema, and no annotations), the description is insufficient. It does not explain what the tool returns, how errors are handled, or the implications of automatic chart selection. For a tool that modifies presentations and involves data processing, more context on behavior and outcomes is needed to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'data structure' for chart selection but not elaborating on how data influences chart type or providing examples. With high schema coverage, the baseline score of 3 is appropriate as the description does not significantly enhance parameter understanding.
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 a new slide') and the key components ('with a title and chart'), specifying the chart type is automatically selected. It distinguishes from siblings like 'add-slide-title-only' or 'add-slide-title-with-table' by focusing on charts, but could be more explicit about differentiation from 'add-slide-comparison' or others that might also involve data visualization.
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 like 'add-slide-title-with-table' or 'add-slide-comparison'. It mentions automatic chart selection based on data structure, but does not specify scenarios, prerequisites, or exclusions, leaving the agent to infer usage from sibling tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new slide with a title and table containing the provided data
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Table data object with headers and rows | |
| presentation_name | Yes | Name of the presentation to add the slide to | |
| title | Yes | Title of the slide |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions adding a slide, implying a mutation, but does not disclose behavioral traits like whether it requires specific permissions, if it modifies an existing presentation, what happens on errors, or if there are rate limits. The description is minimal and misses key operational details.
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, efficient sentence that front-loads the core action. It wastes no words and is appropriately sized for the tool's complexity, making it easy to parse quickly.
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 involves mutation (adding a slide) with no annotations and no output schema, the description is incomplete. It does not cover behavioral aspects like error handling, side effects, or what is returned, leaving significant gaps for an agent to understand the tool's full context.
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 fully documents the parameters. The description adds minimal value by implying the 'data' parameter is used for the table, but does not elaborate on semantics beyond what the schema provides, such as formatting expectations or constraints.
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' and the resource 'new slide', specifying it includes a title and table with provided data. It distinguishes from siblings like 'add-slide-title-only' or 'add-slide-title-with-chart' by mentioning the table, but could be more explicit about the uniqueness compared to other table-related tools if any existed.
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 like 'add-slide-title-content' or 'add-slide-title-with-chart'. It lacks context on prerequisites, such as whether the presentation must exist or be open, or when a table is preferred over other content types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool starts the process of generating a new powerpoint presentation with the name given by the user. Use this tool when the user requests to create or generate a new presentation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the presentation (without .pptx extension) |
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 mentions 'starts the process of generating,' which implies a write operation, but doesn't disclose behavioral traits like whether it requires specific permissions, what happens if a presentation with the same name exists, if it's idempotent, or what the response includes (e.g., success/failure, file path). For a mutation tool with zero annotation coverage, this is a significant gap in 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 appropriately sized and front-loaded, consisting of two clear sentences: one stating the purpose and one providing usage guidelines. Every sentence earns its place with no wasted words, making it highly 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?
Given the tool's complexity as a mutation tool (creating a presentation), with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, error handling), output format, or how it integrates with sibling tools like 'save-presentation'. For a tool that likely has significant side effects, this is inadequate.
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 description coverage is 100%, with the parameter 'name' fully documented in the schema as 'Name of the presentation (without .pptx extension)'. The description adds no additional meaning beyond this, as it only references 'the name given by the user' without extra details. With high schema coverage, the baseline is 3, and the description doesn't compensate further.
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's purpose: 'starts the process of generating a new powerpoint presentation with the name given by the user.' It specifies the verb ('starts generating'), resource ('powerpoint presentation'), and scope ('with the name given'), though it doesn't explicitly differentiate from sibling tools like 'open-presentation' or 'save-presentation'. The description is more specific than a tautology but lacks sibling differentiation for a perfect score.
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 explicit guidance: 'Use this tool when the user requests to create or generate a new presentation.' This clearly indicates the context for usage. However, it doesn't specify when NOT to use it (e.g., vs. 'open-presentation' for existing presentations) or name alternatives, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates an image using a FLUX model and save the image to the specified path. The tool will return a PNG file path. It should be used when the user asks to generate or create an image or a picture.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | Filename of the image. Include the extension of .png | |
| prompt | Yes | Description of the image to generate in the form of a prompt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool 'will return a PNG file path,' it doesn't cover important behavioral aspects like error handling, file overwriting behavior, performance characteristics, or any limitations of the FLUX model. For a tool that generates and saves files with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that each serve distinct purposes: the first states what the tool does, and the second provides usage guidance. There's no wasted text, though it could be slightly more structured by separating behavioral information from usage guidance.
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 that there's no output schema and no annotations, the description provides basic purpose and usage information but lacks important contextual details. It doesn't explain what happens if the file already exists, what quality/size limitations the FLUX model might have, or error scenarios. For a tool that creates files with no structured output documentation, this leaves the agent with incomplete understanding of what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-documented in the schema. The description doesn't add any additional parameter semantics beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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's purpose: 'Generates an image using a FLUX model and save the image to the specified path.' This specifies the verb (generate and save), resource (image), and method (FLUX model). However, it doesn't explicitly differentiate from sibling tools, which are all presentation-related, making this distinction 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?
The description provides clear usage context: 'It should be used when the user asks to generate or create an image or a picture.' This gives explicit when-to-use guidance. However, it doesn't mention when NOT to use it or name specific alternatives among the sibling tools, which are presentation-focused and not direct image generation alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens an existing presentation and saves a copy to a new file for backup. Use this tool when the user requests to open a presentation that has already been created.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | No | Path where to save the presentation (optional) | |
| presentation_name | Yes | Name of the presentation to open |
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 mentions the tool opens and saves a copy for backup, implying a read operation with a side effect, but doesn't disclose critical behavioral traits like whether it requires specific permissions, if the original presentation is modified, error handling, or rate limits. This leaves significant gaps for a tool with potential mutation implications.
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 concise with two sentences that are front-loaded: the first states the core action, and the second provides usage context. There's no wasted text, but it could be slightly more structured by separating purpose and guidelines more clearly.
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 of opening and saving a presentation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'opens' entails (e.g., loads for editing, read-only view), the backup process details, or return values, leaving the agent with insufficient context for safe 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%, so the schema already documents both parameters ('presentation_name' and 'output_path'). The description adds minimal value beyond the schema by implying the 'output_path' is for backup, but doesn't provide additional semantics like format examples or constraints. Baseline 3 is appropriate as 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 clearly states the tool's purpose with specific verbs ('opens an existing presentation' and 'saves a copy to a new file for backup'), distinguishing it from sibling tools like 'create-presentation' and 'save-presentation'. However, it doesn't explicitly differentiate from all siblings, such as 'add-slide-*' tools, which is why it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'Use this tool when the user requests to open a presentation that has already been created,' which helps distinguish it from 'create-presentation'. However, it lacks explicit alternatives (e.g., when to use 'save-presentation' instead) and doesn't mention when not to use it, such as for editing without backup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the presentation to a file. Always use this tool at the end of any process that has added slides to a presentation.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | No | Path where to save the presentation (optional) | |
| presentation_name | Yes | Name of the presentation to save |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool saves to a file but lacks details on permissions, file formats, error handling, or whether it overwrites existing files. For a write operation tool, this leaves significant behavioral gaps, though it does imply it's for finalizing changes.
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 highly concise and front-loaded, with two sentences that directly convey purpose and usage without any wasted words. Each sentence earns its place by providing essential information, making it efficient 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?
Given the tool's complexity (a write operation with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral traits, output, or error handling, leaving gaps that could hinder an agent's effective use.
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 has 100% description coverage, documenting both parameters clearly. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Thus, it meets the baseline of 3, as 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 clearly states the tool's purpose with a specific verb ('Save') and resource ('presentation to a file'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'generate-and-save-image' or 'create-presentation', which might involve saving operations in different contexts, leaving room for minor ambiguity.
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 explicit usage guidance: 'Always use this tool at the end of any process that has added slides to a presentation.' This clearly indicates when to use it (after slide additions) and implies when not to use it (e.g., at the start or without changes), offering strong contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add-slide-comparisonadd-slide-picture-with-captionadd-slide-section-headeradd-slide-title-contentadd-slide-title-onlyadd-slide-title-with-chartadd-slide-title-with-tablecreate-presentationgenerate-and-save-imageopen-presentationsave-presentationScored across 11 tools
Most tools have distinct purposes focused on slide types or presentation management, but 'generate-and-save-image' stands out as unrelated to PowerPoint operations, potentially causing confusion. The slide-adding tools are well-differentiated by content type (comparison, picture, title-only, etc.), making them easy to distinguish for their specific use cases.
The naming follows a consistent 'verb-noun' pattern with hyphens (e.g., add-slide-comparison, create-presentation), which is clear and predictable. However, 'generate-and-save-image' deviates slightly by including an 'and' conjunction, breaking the pure verb-noun flow, though it remains readable and understandable.
With 11 tools, the count is reasonable for a PowerPoint server, covering slide creation, presentation management, and an image generation tool. It's slightly on the higher side but well-scoped for the domain, with each tool serving a specific function without obvious redundancy.
The toolset covers core presentation operations like creating, opening, saving, and adding various slide types, but lacks tools for editing or deleting slides, updating content, or managing slide order. The inclusion of 'generate-and-save-image' adds an unrelated capability, but for PowerPoint-specific tasks, there are notable gaps in lifecycle coverage.
Presentations.AI MCP server — create designed slide decks from a topic, text, or document.
Generate polished PowerPoint presentations from text prompts, YouTube videos, or structured outlin…
Generate professional PowerPoint presentations from text, YouTube videos, or structured JSON data.…
Deterministic, fully editable PowerPoint from typed slide intents. 200+ layouts, brand templates.
