How do I use true-deck-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@true-deck-mcp Convert this markdown into a True branded PowerPoint deck." 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.

true-deck-mcp

by ramzpat

Overview Schema Related Servers Score Discussions

Python

Hybrid

true-deck-mcp

An MCP server that turns Markdown into True Corporation branded PowerPoint decks. Same renderer as the true-deck skill — one template, two front doors.

See DESIGN.md for the architecture and the interactive-app plan.

Install

pip install -e .            # or: pip install mcp>=2.0.0 python-pptx pillow

Preview rendering additionally needs LibreOffice and poppler:

apt-get install -y libreoffice-impress poppler-utils

Without them everything except deck_preview still works, and deck_capabilities reports preview_available: false.

Related MCP server: marp-agent-mcp

Run

# local, for Claude Code / Claude Desktop / Gemini CLI
python -m true_deck_mcp --output-dir ~/Decks

# remote, for a Claude custom connector
python -m true_deck_mcp --transport http --port 3333 \
  --public-url https://decks.example.com

Env var	Meaning
`TRUE_DECK_PUBLIC_URL`	Base URL. Enables `download_url`; disables writing to caller-supplied paths.
`TRUE_DECK_OUTPUT_DIR`	stdio mode: always also save decks here.
`TRUE_DECK_ARTIFACT_DIR`	Artifact cache (default `~/.cache/true-deck-mcp`).

Connect

Claude Code / Claude Desktop — claude_desktop_config.json or .mcp.json:

{
  "mcpServers": {
    "true-deck": {
      "command": "python",
      "args": ["-m", "true_deck_mcp", "--output-dir", "/Users/you/Decks"],
      "env": { "PYTHONPATH": "/path/to/true-deck-mcp/src" }
    }
  }
}

Claude web / Cowork — run with --transport http, expose it (npx cloudflared tunnel --url http://localhost:3333 for a quick test), then Settings → Connectors → Add custom connector → https://.../mcp.

Gemini Spark — Settings & help → Connected Apps → add the server URL. Tools work; interactive UI is not documented there, so the server's text results are what you get.

Tools

Tool	What it does
`deck_capabilities`	Slide kinds, block types, capacity limits, palette.
`deck_validate`	Outline + layout warnings, without rendering. Fast.
`deck_generate`	Markdown → `.pptx`; returns an `artifact_id`.
`deck_preview`	Renders the deck to PNGs so the agent can see it.
`deck_fetch`	Returns the `.pptx` as an embedded base64 blob.

Resources: deck://format, deck://design-spec, deck://example. Prompt: build_true_deck(topic).

Typical agent loop

deck_capabilities()                     → learn the format (once)
deck_validate(markdown)                 → fix warnings
deck_generate(markdown, "board.pptx")   → artifact_id
deck_preview(artifact_id)               → LOOK AT IT
   ...edit the Markdown, regenerate...
deck_fetch(artifact_id) / download_url  → hand it over

Test

python3 tests/test_e2e.py

Spawns the server over real stdio and exercises every tool, writing the resulting deck and contact sheet to /tmp/true-deck-e2e.

Available Tools

5 tools

deck_capabilitiesDeck capabilitiesA

Read-only

What this deck builder supports: slide kinds, body block types, capacity limits and the brand palette. Call this before writing deck Markdown for the first time.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is covered. The description adds context about the content scope (what capabilities are exposed) and the recommended call time, going beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences deliver exactly the needed information: the categories of data returned and when to invoke the tool. Every word earns its place, with no padding or repetition.

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

Completeness4/5

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

For a simple read-only, parameterless tool, the description adequately covers what it returns and when to call it. It could be more explicit about the return format, but with no output schema and the clear scope, this is a minor gap.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema fully covers all parameters (vacuously). The description adds no parameter-level details because none exist, matching the baseline for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

The description explicitly states what the tool returns: 'slide kinds, body block types, capacity limits and the brand palette.' This is a specific, actionable scope that clearly distinguishes it from siblings like deck_fetch, deck_validate, deck_generate, and deck_preview.

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

Usage Guidelines4/5

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

The description provides clear usage guidance: 'Call this before writing deck Markdown for the first time.' This establishes a specific precondition and context, though it does not explicitly name alternatives or state when not to use the tool.

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

deck_fetchFetch deck fileA

Read-only

Return the generated .pptx itself as an embedded resource, for hosts that cannot fetch a download URL. Large files are refused — use download_url or file_path instead.

ParametersJSON Schema

Name	Required	Description	Default
`artifact_id`	Yes	artifact_id returned by deck_generate.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that large files are refused and that the file is returned as an embedded resource. This provides meaningful behavioral context not available from annotations alone. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences front-load the core purpose and immediately state the key limitation and alternatives. Every word earns its place.

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

Completeness5/5

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

For a simple single-parameter read-only tool with rich annotations and schema, the description is complete. It covers purpose, usage context, and failure mode (large files), which is sufficient for an AI agent to decide when to use this tool.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for the single parameter is 100%, with the artifact_id already described as 'returned by deck_generate'. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

The description explicitly states the tool returns the generated .pptx as an embedded resource, and clearly distinguishes from sibling tools by noting it's for hosts that cannot fetch a download URL. It also references alternatives like download_url or file_path.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance ('for hosts that cannot fetch a download URL') and when-not-to-use with a specific exclusion ('Large files are refused — use download_url or file_path instead'). It names exact alternatives.

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

deck_generateGenerate deckA

Idempotent

Render deck Markdown into a True-branded .pptx. Returns an artifact_id — pass it to deck_preview to look at the result and to deck_fetch to get the bytes. Regenerate from edited Markdown rather than editing the .pptx.

ParametersJSON Schema

Name	Required	Description	Default
`save_to`	No	Absolute path of a directory to also write the file to. Local (stdio) deployments only; ignored when the server disallows it.
`filename`	No	Output file name, e.g. 'Q3_review.pptx'.	deck.pptx
`markdown`	Yes	The deck source in the True deck Markdown format.

Output Schema

ParametersJSON Schema

Name	Required	Description
`filename`	Yes
`warnings`	No
`file_path`	No	Set when the deck was also written to disk.
`mime_type`	Yes
`next_step`	Yes
`size_bytes`	Yes
`artifact_id`	Yes	Handle to pass to deck_preview / deck_fetch.
`slide_count`	Yes
`download_url`	No	Set on remote deployments.
`save_to_ignored`	No
`expires_in_hours`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds valuable behavioral context by explaining the artifact_id return and the intended regeneration workflow, going beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is two sentences, front-loaded with purpose, and every sentence provides essential information: what it does, what it returns, and a key usage guideline. No wasted words.

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

Completeness4/5

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

With an output schema present, the description need not explain return values in detail. It adequately covers the generation workflow and integration with preview/fetch. Minor gap: no explicit mention of when to use deck_validate or deck_capabilities, but overall complete for selection and invocation.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond the schema; all three parameters are already well described in the schema properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

The description clearly states the tool's function: 'Render deck Markdown into a True-branded .pptx.' This is a specific verb and resource, and it distinguishes from siblings by explaining that it returns an artifact_id for use with deck_preview and deck_fetch.

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

Usage Guidelines5/5

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

The description provides explicit guidance: 'Regenerate from edited Markdown rather than editing the .pptx' and directs the user to pass the artifact_id to deck_preview and deck_fetch for viewing and retrieval. This clarifies when to use this tool and how it fits with alternatives.

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

deck_previewPreview deckA

Read-only

Render a generated deck to images so you can actually see it. Returns a contact sheet by default, or individual slides. Look for text spilling out of a card, a nearly empty slide, or a badly wrapped title, then fix the Markdown and regenerate.

ParametersJSON Schema

Name	Required	Description	Default
`dpi`	No	Render resolution.
`mode`	No	'contact_sheet' tiles every slide into one image; 'slides' returns them separately.	contact_sheet
`slides`	No	1-based slide numbers to render. Omit for all.
`artifact_id`	Yes	artifact_id returned by deck_generate.

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses the return format (contact sheet by default or individual slides) and suggests how to use the output for quality checks. Annotations already declare readOnlyHint=true, and the description adds value by explaining what the rendered images are for, going beyond the annotation's basic safety flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is three sentences, front-loaded with the primary action ('Render a generated deck to images'), followed by return format and practical usage guidance. Every sentence earns its place with no redundancy.

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

Completeness4/5

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

The description explains the return format and intended use, and the schema covers all parameters and defaults. It could explicitly state that the deck must already be generated, but 'generated deck' and the sibling deck_generate make this clear enough. With no output schema, the return value explanation is adequate.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All four parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description adds no parameter-specific details beyond what the schema already provides; the mention of 'contact sheet by default' merely reflects the mode parameter's default, not new information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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

The description uses a specific verb 'Render' with a specific resource 'generated deck', clearly stating it produces images for visual inspection. It distinguishes itself from siblings by focusing on visual rendering rather than capabilities, fetching, validation, or generation.

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

Usage Guidelines4/5

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 the tool: to visually inspect a deck for issues like text spilling, empty slides, or badly wrapped titles, and implies a follow-up workflow of fixing Markdown and regenerating. However, it does not explicitly name alternatives or exclusion conditions, stopping short of full when/when-not guidance.

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

deck_validateValidate deck MarkdownA

Read-only

Parse deck Markdown and report the slide outline plus layout warnings (overflow risk, too many cards, missing titles) without rendering a file. Cheap — use it while drafting.

ParametersJSON Schema

Name	Required	Description	Default
`markdown`	Yes	The deck source in the True deck Markdown format.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes	True when there are no warnings.
`meta`	No	Parsed front matter.
`slides`	Yes
`warnings`	Yes	Layout and capacity problems to fix in the Markdown.
`slide_count`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description's added value comes from clarifying that it does not render a file and specifies the type of warnings reported (overflow risk, too many cards, missing titles). This provides useful behavioral context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is two sentences, front-loaded with the action and output, and each clause earns its place. The usage hint ('Cheap — use it while drafting') is concise and memorable.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, output schema present, read-only annotation), the description covers the essential facets: what it parses, what it reports, when to use it, and that it avoids rendering. No critical context is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the parameter 'markdown' is already fully described as 'The deck source in the True deck Markdown format.' The description adds no new parameter-level semantics 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.

Purpose5/5

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

The description clearly states the tool's action ('Parse deck Markdown'), the resource ('deck Markdown'), and the output ('slide outline plus layout warnings'). It explicitly distinguishes itself from sibling tools by focusing on validation, not generation, fetching, or previewing.

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

Usage Guidelines4/5

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

The description provides clear usage context, recommending use 'while drafting' and emphasizing the tool is 'Cheap'. It does not explicitly name alternative tools or exclusions, but the context is sufficient for a single-purpose validation tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Aug 17, 2026
- First observeddeck_capabilities
- First observeddeck_fetch
- First observeddeck_generate
- First observeddeck_preview
- First observeddeck_validate

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: capabilities provides metadata, validate checks Markdown, generate creates the PPTX, preview renders images, and fetch retrieves the file bytes. No overlap or ambiguity.

Naming Consistency4/5

All tools share the 'deck_' prefix with a descriptive verb (fetch, validate, generate, preview), though 'deck_capabilities' breaks the verb pattern with a noun. The convention is still highly predictable and readable.

Tool Count5/5

Five tools is well-scoped for a deck-building server: each tool covers a distinct step in the workflow from capability discovery to final artifact retrieval. No redundant or missing tools.

Completeness5/5

The tool surface covers the full lifecycle: understand constraints, validate drafts, generate the deck, visually preview it, and fetch the output. Regeneration is explicitly handled via Markdown editing, so no update/delete tools are needed.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

presentations-aiOAuth
ai.presentations
Presentations.AI MCP server — create designed slide decks from a topic, text, or document.
Workplace & Productivity AI & Machine Learning
21
stagenth · 文档生成 A
com.stagenth
Generate PDF, Word (.docx) and PowerPoint (.pptx) documents from Markdown over MCP.
File Systems Workplace & Productivity
33
powerpoint-engineOAuth
io.powerpointengine
Generate, edit, merge, translate and PDF-convert PowerPoint (.pptx) over MCP. 8 tools.
Workplace & Productivity File Systems
2
Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31

Related MCP Servers

PPTX MCP Server
Multimedia Processing App Automation Developer Tools
samos123
A
license
Not graded
quality
D
maintenance
A FastMCP-powered server for programmatically creating, editing, and rendering PowerPoint (PPTX) presentations with features for slide creation, content insertion, and PNG rendering.
Updated a year ago (2025-05-20 03:36 UTC)
35
Apache 2.0
marp-agent-mcp
Workplace & Productivity Design Tools
iwamot
F
license
Not graded
quality
A
maintenance
MCP server for generating slides from natural language, with interactive preview and export to PDF, PPTX, and Markdown.
Updated 6 days ago (2026-09-01 16:14 UTC)
19
-
pptx-mcp-server
Developer Tools Workplace & Productivity
knorq-ai
A
license
Not graded
quality
B
maintenance
MCP server for creating, reading, and editing PowerPoint (.pptx) presentations.
Updated 5 months ago (2026-04-22 08:30 UTC)
1
MIT
ppt-generator
Design Tools AI & Machine Learning
haandol
F
license
A
quality
B
maintenance
An MCP server that auto-generates presentations from a topic using AI, supporting slide editing, visual QA, and export to HTML/PPTX.
Updated 9 days ago (2026-08-29 08:34 UTC)
30
7
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ramzpat/true-deck-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server