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., "@deckproof-mcp Create a deck from my template with a cover, agenda, and bullets."
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.
Bring your own PowerPoint template - get spec-clean slides back. A Model Context Protocol server that creates, validates, audits, and repairs .pptx files against the real OOXML / ECMA-376 (ISO/IEC 29500) PresentationML spec.
Point it at your company deck; it adds new slides that match your existing masters, layouts, theme, and branding - and every file it hands back is validated against the same structural checklist it uses to inspect other people's files. Fully local. No API keys.
LLM-driven and library-driven PowerPoint generation quietly produces broken files. They open fine in PowerPoint (which silently self-heals on load) and then fail to import into Apple Keynote, Google Slides, or Apache POI - because those readers are strict about the spec.
This isn't hypothetical:
Anthropic's own /pptx skill shipped files that fail to open in Keynote (anthropics/skills#1167) - root-caused to a stale sldSz attribute, a missing notesMasterIdLst, and a Windows-only embedded part.
PptxGenJS passes invalid shape presets straight through, and its defineSlideMaster can write malformed [Content_Types].xml on multi-slide decks.
pptx-automizer (the template-cloning engine used here) can leave dangling relationships and unregistered slide IDs.
deckproof-mcp treats the OOXML spec as the source of truth: it generates against it, checks against it, and repairs to it. Creation is self-certifying - every generated or repaired file is run back through the validator before it is returned.
Related MCP server: PPT-MCP
Run it from npm with npx (no install needed) and register it with your MCP client:
{
"mcpServers": {
"deckproof": {
"command": "npx",
"args": ["-y", "deckproof-mcp"]
}
}
}Running from source (before the npm package is published, or to hack on it): clone this repo,
npm install && npm run build, then point your client at"command": "node", "args": ["/absolute/path/to/deckproof-mcp/dist/index.js"].
Tool | What it does |
| List the 15 built-in layout archetypes. Pass a |
| Build a deck - from your uploaded template (clone + refill, branding inherited) or from a neutral theme. Self-certifying. |
| Structural pass/fail for any |
| Validation plus advisory metrics: alt-text coverage, orphaned/duplicate media, counts, and per-viewer portability risk. |
| Auto-fix an existing |
Files are returned as a base64 resource block (correct PresentationML MIME type) plus a text summary; structured JSON reports come back in structuredContent.
Call pptx_list_layouts with your company .pptx as template. You get back its slides, each with an index and its placeholder types.
Call pptx_create_deck with the same template and a slides array. For each slide, choose an archetype (the content shape) and a stencilSlideIndex (which of your template's slides to clone for its look).
Text archetypes (cover, agenda, bullets, quote, ...) refill the cloned slide's placeholders. Rich archetypes (tables, timeline, org chart, matrix, ...) keep the cloned slide's branded chrome and generate their content on top, styled with colors pulled from your template's theme.
New slides are appended after your template's existing slides (this preserves spec-correctness), so your template must contain at least one slide to clone. Omit template entirely to build a fresh deck on a neutral theme.
cover, agenda, contentBullets, twoColumns, quote, sectionDivider, closingNextSteps, comparisonTable, dataTable, timeline, statsBanner, cardGrid, orgChart, matrixQuadrant, verticalSteps.
Structural errors (gate valid): dangling relationships; missing presentation ID-list registrations (sldIdLst / sldMasterIdLst / notesMasterIdLst); content-type completeness; stale/contradictory sldSz; slide-layout-master inheritance; duplicate slide IDs; theme color-map breakage; orphaned master/layout chains; duplicate relationship IDs; unregistered slide/layout/master/theme parts.
Advisory warnings (surfaced by pptx_audit): Windows-only platform parts; orphaned media; missing picture alt-text; duplicate media bloat.
The same binary also speaks Streamable HTTP so it can run as a deployable service. node dist/index.js picks the transport at runtime:
no PORT / MCP_TRANSPORT → stdio (the npx default).
PORT set (most PaaS set this automatically), or MCP_TRANSPORT=http → Streamable HTTP at POST /mcp, with a GET /healthz check.
The HTTP server is stateless (fresh server per request) - safe because every tool call is a pure function of its inputs; the uploaded template travels in the request bytes, not in server state.
npm run build
npm run start:http # MCP_TRANSPORT=http PORT=3000 node dist/index.js
# or:
docker build -t deckproof-mcp .
docker run -p 3000:3000 deckproof-mcpVariable | Default | Purpose |
|
| Port to listen on (setting it alone switches to HTTP mode). |
| (unset) | Set to |
|
| Interface to bind. |
| (unset) | Comma-separated allowed |
This server ingests untrusted .pptx uploads, so it is hardened accordingly:
path input is stdio-only. Reading a file from a local path is allowed only on the local stdio transport. Over HTTP the path input is rejected (local-file-read / SSRF protection) - remote callers must pass base64.
Input limits. Uploads over 50 MB are rejected; packages that decompress past 300 MB are refused (zip-bomb guard); a single call is capped at 200 slides.
XML entity expansion is disabled (no "billion laughs" amplification on crafted parts).
No built-in authentication. These tools are read-only pure computations with no network or credential access, but if you expose the HTTP server beyond a trusted network, put it behind a gateway that handles auth and set MCP_ALLOWED_HOSTS.
npm install
npm run build # tsc -> dist/
npm test # build + vitest (engine, tools, HTTP tiers)
npm run inspect # MCP Inspector against the built serverArchitecture: pure, dependency-free logic in src/engine/ (OPC package model, one file per validation rule, sanitizer, layout composers) with thin MCP wrappers in src/tools/. Tests build their fixtures in code (no checked-in binaries), so they never drift from what the engine emits.
jszip + fast-xml-parser model the .pptx as an OPC package; every rule and fixer operates on that model, never raw bytes.
pptxgenjs builds from-scratch slides; pptx-automizer clones template stencils and refills placeholders (targeting them by standard placeholder type + nameIdx, robust to duplicate element names).
The validator runs 14 pure (package) => violations[] rules; the sanitizer runs the safe subset as fixers and re-validates.
MIT - see LICENSE.
Full report on an existing .pptx: all structural validation violations, plus advisory metrics - alt-text coverage %, orphaned and duplicate media, slide/media counts, file size, and an estimated portability risk for PowerPoint, Apple Keynote, LibreOffice Impress, and Google Slides (strict readers reject bugs that lenient ones silently self-heal).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| metrics | Yes | |
| violations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context about the report's scope, including portability risk behavior ('strict readers reject bugs that lenient ones silently self-heal'), which goes beyond the annotations. No contradiction with annotations is present.
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, information-rich sentence that front-loads the purpose ('Full report') and then lists concrete report components in a dash-separated series. Every phrase adds value and no filler exists. The structure makes it easy to scan even though the sentence is long.
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 tool's substantive functionality thoroughly, and an output schema exists so return values need not be described in prose. It is complete enough for an agent to understand the audit scope and expected metrics. The only notable gap is the lack of explicit routing away from pptx_validate, but the 'plus advisory metrics' phrasing largely covers that.
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 0% according to context signals, so the description must compensate by explaining the `source` parameter and the path/base64 tradeoff. It does not: the entire description focuses on the output report and never mentions how to specify the input file. The schema provides some names and types, but the description adds no parameter guidance, leaving a gap for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it produces a full audit report of an existing .pptx. It enumerates concrete content ('all structural validation violations, plus advisory metrics') and explicitly includes validation plus quality metrics, which distinguishes it from the sibling pptx_validate. The title reinforces the same distinction.
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 when to use the tool: whenever a comprehensive report with validation and metrics is needed. However, it never explicitly states when not to use it, e.g., 'if you only need validation, use pptx_validate', or mentions any alternatives. The usage context is clear but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a .pptx from a declarative list of slides (see pptx_list_layouts for the archetype catalog). Bring-your-own-template mode: pass template (your existing company .pptx) and a stencilSlideIndex per slide - each new slide is cloned from that template slide, inheriting its masters, layout, theme and branding, then refilled with your content. New slides are APPENDED after the template's existing slides (this preserves spec-correctness; the template must contain at least one slide to clone). Omit template to build a fresh deck from a neutral default theme. Every call is self-certifying: output is validated against the same OOXML checklist pptx_validate uses before it's returned. Returns the file as a base64 resource plus a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Presentation title (metadata, not a slide). | |
| slides | Yes | The slides to build, in order. | |
| template | No | Optional existing .pptx to use as the brand template. When given, every slide needs a stencilSlideIndex. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| valid | Yes | |
| byteLength | Yes | |
| violations | Yes | |
| slidesAdded | Yes | Number of new slides created (appended, in template mode). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (all false), so the description carries the burden and does it well: it discloses that new slides are APPENDED after template slides, that the template must contain at least one slide, that output is self-certified against the same OOXML checklist as pptx_validate, and that the result is returned as a base64 resource plus a summary. This is far beyond what the annotations or schema convey.
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 dense but every sentence earns its place: purpose, template mode, append behavior, template requirement, default-theme fallback, self-certification, and return format are all covered without filler. It is front-loaded with the core purpose before diving into mode details.
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, the description covers the most important operational context: template cloning, append semantics, validation, and output shape. It also points to pptx_list_layouts for the archetype catalog, which compensates for not enumerating archetypes. Minor gaps remain around failure modes and explicit call-to-action sequencing, but the output schema and rich parameter schema cover much of the remaining detail.
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 baseline is 3, but the description adds substantial semantic value: it explains that template mode clones stencil slides and inherits masters, layout, theme and branding; it clarifies stencilSlideIndex's role; and it explains what happens when template is omitted. This goes beyond the schema's field-level 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 opens with a specific verb and resource: 'Build a .pptx from a declarative list of slides.' It clearly distinguishes the tool from its siblings by referencing pptx_list_layouts for the archetype catalog and by describing the create/append behavior rather than validation or repair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each mode: bring-your-own-template vs. omitting template for a fresh default deck. It also routes the agent to pptx_list_layouts for the archetype catalog and ties validation back to pptx_validate's checklist. It does not explicitly state when not to use this tool versus audit/repair, but those are clearly distinct operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the catalog of slide layout archetypes pptx_create_deck supports (e.g. cover, agenda, comparison table). If you pass a template (an existing .pptx), it also returns that template's existing slides with their layout names and placeholder types, so you can pick a stencilSlideIndex for each new slide in template mode.
| Name | Required | Description | Default |
|---|---|---|---|
| template | No | Optional existing .pptx to inspect for stencil slides. |
| Name | Required | Description |
|---|---|---|
| layouts | Yes | |
| templateSlides | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, and the description adds meaningful behavioral context beyond them: it behaves differently with and without the optional template, returning either the archetype catalog or also template slide details. OpenWorldHint=false is not contradicted by the description.
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 with no filler, front-loading the primary return value and then explaining the conditional template behavior. The title adds a concise summary, and every word contributes to operational understanding.
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 one optional parameter, a rich output schema, and clear annotations, the description fully covers both invocation modes and the practical purpose of the template parameter. There are no significant gaps for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents template, path, and base64 with 100% coverage, so the baseline is 3. The description adds functional value by explaining that passing a template lets the agent inspect existing slides and pick stencilSlideIndex values, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it returns the catalog of slide layout archetypes supported by pptx_create_deck, and optionally inspects an existing template's slides for layout names and placeholder types. It uses specific, distinct language that separates it from the sibling tools like create, validate, audit, and repair.
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 clearly explains when to use the tool: before creating a deck or when working in template mode, specifically to choose a stencilSlideIndex. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-fix an existing .pptx's structural problems: backfill missing presentation ID-list entries (the Keynote-import bug), add/correct missing content-type declarations, remove dangling relationships and orphaned/duplicate media, strip Windows-only printer-settings parts, and clamp invalid geometry. Returns the repaired file plus a log of changes made and any violations it could not fix safely (which it reports rather than guessing at).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
| byteLength | Yes | |
| stillValid | Yes | True if no error-severity violations remain after repair. |
| changesApplied | Yes | |
| remainingViolations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses specific mutations: backfilling ID-list entries, correcting content types, removing dangling relationships, stripping printer-settings parts, and clamping geometry. It also states it returns a change log and reports unfixable violations instead of guessing, which adds meaningful behavioral context beyond the readOnlyHint=false and idempotentHint=true annotations.
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 dense but purposeful: it front-loads the core action, then uses a colon to introduce a specific list of fixes, and closes with the output/log behavior. Every clause adds useful information, with no filler or tautological repetition of 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?
For a single-parameter repair tool with a true output schema and annotations covering read-only/idempotence, the description supplies all essential context: what will be fixed, what will be removed, and how unsafe violations are handled. Nothing critical appears missing for an agent to decide whether and how to invoke it.
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 description adds only that the tool operates on an existing .pptx and returns a repaired file; it does not explain how to provide the source via path versus base64. However, the input schema itself documents the nested path and base64 properties well, so the parameter semantics are still usable without requiring the description to compensate.
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 uses a specific verb and resource: "Auto-fix an existing .pptx's structural problems," then enumerates concrete repair actions. This clearly distinguishes it from sibling tools like pptx_validate and pptx_audit, which are inspection-oriented rather than repair-oriented.
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 intended use is implied by "auto-fix" and the enumerated structural defects, so an agent can infer this is for repairing broken OOXML packages rather than creating or auditing them. However, the description never explicitly names alternatives such as pptx_validate or pptx_audit, nor does it state 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.
Check an existing .pptx file's structural conformance to the OOXML/ECMA-376 PresentationML spec: dangling relationships, missing presentation ID-list registrations (the class of bug that makes files silently fail in strict readers like Apple Keynote), and content-type completeness. Works on any .pptx, regardless of what tool created it. Returns valid: true only if there are zero error-severity violations.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| violations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral details beyond those: it returns valid:true only with zero error-severity violations, targets specific bug classes, and promises cross-tool compatibility. No contradiction with annotations exists.
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 three sentences, front-loads the core purpose, and each sentence earns its place: purpose, scope, and return semantics. It is detailed without being bloated or redundant.
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 output schema exists, the description does not need to enumerate the full return shape. It covers what is validated, the strictness standard, the files it applies to, and the validity condition. Combined with the read-only/idempotent annotations and schema-documented parameters, nothing essential is missing.
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 description does not discuss the source parameter or the path/base64 distinction, but the input schema itself provides clear descriptions for both fields. The schema carries the parameter-semantics burden, so the description adds little beyond what an agent already sees in 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 states a specific action ('Check an existing .pptx file's structural conformance') and identifies the exact standard (OOXML/ECMA-376 PresentationML). It lists concrete violation classes, distinguishes validation from creation/repair/audit siblings, and clarifies the success condition, so an agent can tell what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever an existing .pptx needs conformance checking, and it explicitly says it works on any .pptx regardless of origin. However, it never names sibling tools like pptx_audit or pptx_repair, nor states when to choose validation over auditing or repair, leaving some routing to inference.
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.
v0.1.0pptx_auditpptx_create_deckpptx_list_layoutspptx_repairpptx_validateScored across 5 tools
Each tool addresses a distinct phase: layout discovery, deck creation, structural validation, audit reporting, and repair. The overlap between validate and audit is acceptable because validate gives a pass/fail health check while audit adds detailed metrics and portability risk.
All tools share the consistent `pptx_` prefix and use clear snake_case verbs: list_layouts, create_deck, validate, audit, repair. The pattern is predictable and makes tool purpose immediately recognizable.
Five tools is well-scoped for a deck-focused reliability server: one for discovering layouts, one for creation, and three for validation/audit/repair. Each tool has a distinct role without unnecessary bloat or missing essentials.
The tool surface covers the full intended workflow: understand available layouts, create a deck, verify it, inspect it in depth, and repair structural issues. The self-certifying creation step also closes the loop by ensuring newly created decks are valid before they are returned.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate, edit, merge, translate and PDF-convert PowerPoint (.pptx) over MCP. 8 tools.
Generate professional PowerPoint presentations from text, YouTube videos, or structured JSON data.…
Generate PDF/DOCX/XLSX/PPTX from templates+JSON. Convert Office/HTML/MD to PDF. Universal templating
Deterministic, fully editable PowerPoint from typed slide intents. 200+ layouts, brand templates.
