ai-slides-mcp
This server generates AI-powered images via the ChatGPT web backend and assembles them into customized PowerPoint presentations.
Check login status: Verify which ChatGPT accounts are authenticated and ready. Multiple accounts are supported, with auto-rotation to combine daily image quotas.
Generate images: Create one or more images from a text prompt with control over aspect ratio (16:9, 1:1, 3:4, 4:3, 9:16, or custom WxH), style (
auto,slide,fintech), and optional prompt enhancement. Reasoning effort (standard,extended,max) can be tuned to improve text fidelity in images.Build a deck from existing images: Assemble pre-existing image files into a full-bleed
.pptxpresentation.Generate a full slide deck from prompts: Create one AI image per prompt and automatically compile them into a PPTX, with slide-optimized styles and optional prompt enhancement.
Create a branded deck: Provide a logo — the server auto-detects brand colors, generates slides in those colors, composites the logo onto every slide, and assembles a PPTX.
Create a style-matched deck: Provide a reference design image — the server matches its visual style and color palette (without copying its content) and assembles a PPTX.
Generates images using OpenAI's ChatGPT backend, enabling creation of branded and styled slide decks for PowerPoint.
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., "@ai-slides-mcpgenerate a 3-slide deck about the benefits of AI in healthcare"
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.
ai-slides-mcp
An MCP server (and CLI) that generates images through the ChatGPT web backend and assembles them into full-bleed PowerPoint decks (brand-aware and reference-styled).
⚠️ Disclaimer
This project is provided for personal learning and research only. It reverse-engineers the ChatGPT web backend:
Not affiliated with, endorsed by, or sponsored by OpenAI.
Using it violates OpenAI's Terms of Service. Your account may be rate-limited or permanently banned.
Use a throwaway / secondary account — never your important one.
Provided as-is, with no warranty. You assume all risk. If you are not comfortable with these terms, do not use this software.
Related MCP server: Deckbuilder MCP Server
What it does
Generates images from text prompts at a chosen aspect ratio (16:9, 1:1, 3:4, 4:3, 9:16, or raw
WxH).Reasoning effort (
thinking): optionally make the model think harder before drawing (standard<extended<max) — markedly improves rendered text fidelity, e.g. Vietnamese diacritics.Auto-enhances prompts via your ChatGPT account's text model before drawing (mirrors what the web UI does silently). Three slide styles:
auto,slide,fintech.Builds full-bleed PowerPoint (
.pptx) decks from a set of images.Branded decks: auto-detects brand colors from your logo, generates slides in those colors, and composites your logo onto every slide.
Styled decks: matches the design style and palette of a reference image (without copying its text/content).
Multiple accounts (auto-rotation): log in several ChatGPT accounts; the tool probes each account's remaining image quota and rotates to the next when one runs dry, so several free accounts' daily caps combine into one deck. If all run out mid-deck you get a partial deck plus when quota resets.
Works as an MCP server across Claude Code, Codex, and Antigravity over stdio.
Multi-account, fully local auth - your tokens never leave your machine.
Requirements
uv — handles Python and dependencies (you do not need to install Python separately;
uvfetches Python 3.12 automatically).git
A ChatGPT account (use a secondary one — see disclaimer)
Install uv (one time per machine):
# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | shInstall
One-click installer (recommended)
After cloning, run the installer — it installs uv if missing, syncs deps, walks you through login, and registers the MCP server:
git clone https://github.com/vuhai2002/ai-slides-mcp.git
cd ai-slides-mcp# Windows (PowerShell) — or right-click install.ps1 -> Run with PowerShell
powershell -ExecutionPolicy Bypass -File install.ps1# macOS / Linux
bash install.shManual install
git clone https://github.com/vuhai2002/ai-slides-mcp.git
cd ai-slides-mcp
uv sync
uv run cgimg login
# A browser opens -> log into ChatGPT -> you land on a platform.openai.com page (it may say "Oops").
# Copy the FULL callback URL from the address bar, then run:
uv run cgimg login --callback "<paste the callback URL here>"If you keep your repo private, the cloning machine must be signed into a GitHub account with access (e.g.
gh auth login).
Why login is two steps
Login uses OAuth with PKCE. Step 1 builds the authorization URL and stashes a one-time secret (the PKCE verifier) on disk. Step 2 exchanges the code in the callback URL for tokens — and that exchange needs the same verifier that step 1 generated. Splitting it into two commands lets the verifier persist between building the URL and redeeming the code, instead of being lost when the browser hands control back to you.
Register as an MCP server
The config is the same shape for Claude Code, Codex, and Antigravity:
{
"mcpServers": {
"ai-slides": {
"command": "uv",
"args": ["run", "cgimg-mcp"],
"cwd": "<absolute path to the cloned repo>"
}
}
}Replace cwd with the absolute path where you cloned the repo (e.g. D:\\ai-slides-mcp on Windows — note the doubled backslashes in JSON). For Claude Code you can instead run:
claude mcp add ai-slides -- uv run cgimg-mcpMCP tools
Six tools are exposed by the server (src/cgimg/server.py):
Tool | Params | Returns | Description |
| — |
| List logged-in accounts (cheap, hint-based; use the CLI |
|
|
| Generate |
|
|
| Assemble existing images into a full-bleed PPTX. |
|
|
| Generate one image per prompt (one slide each, named |
|
|
| Auto-detects brand colors from the logo, generates slides in those colors, and composites the original logo onto each slide. |
|
|
| Matches a reference image's design style + colors (does not copy its text/content). |
For generate_slide_deck / branded_deck / styled_deck, each prompt is the content of one slide — pass raw slide content and the enhancer designs it.
Slide styles
When enhance=True, the prompt is expanded by your ChatGPT account's text model before drawing. The style argument picks the design treatment:
Style | Look | Enhancement |
| General — a dense infographic, or a photographic scene if the prompt names a real scene. | Skipped if the prompt is already long (≥280 chars). |
| Clean editorial presentation slide: light cream background, ONE warm accent color, a soft 3D hero visual, slide-number pill, bottom takeaway banner. | Always runs. |
| Premium light-blue dashboard look: glassmorphism cards, circular blue-gradient icon badges, optional 3D robot + chart widgets, bottom blue banner. | Always runs. |
Content completion (for slide / fintech): these styles complete your content into a full, information-rich slide — every main point gets a bold label plus a 2-line supporting description, sparse input is intelligently expanded into a sensible slide, and the prompt explicitly demands that all text be rendered in full (never dropped or abbreviated). It stays legible (not a wall of tiny text) and never fabricates fake statistics. See docs/styles.md for a full reference.
generate_imageand the CLIgenacceptstylevaluesauto,slide, andfintech.generate_slide_deckdefaults toslide.
Reasoning effort (thinking)
ChatGPT's web UI has an "Intelligence" selector that makes the image model reason more before drawing. generate_image, the deck tools, and the CLI expose the same via thinking:
| Effect |
| Sends no preference — ChatGPT's own default (fast). |
| Light reasoning. |
| More reasoning. |
| Most reasoning — best for rendered text (e.g. Vietnamese diacritics), slowest. |
Higher effort noticeably improves text fidelity inside the image. If generated slides garble Vietnamese diacritics at the default, try --thinking max (CLI) or thinking="max" (MCP). Values are passed to ChatGPT's image backend as thinking_effort; anything outside the set above is rejected by the backend.
CLI usage
# 1. Log in (two-step, see Install above)
uv run cgimg login
uv run cgimg login --callback "<paste callback URL>"
# Multiple accounts (auto-rotation): repeat the login for EACH account. To add a
# DIFFERENT account, sign out of chatgpt.com first or use an incognito/private
# window (login captures whichever account is signed in). Then:
uv run cgimg accounts # list accounts with live remaining quota
uv run cgimg logout you@example.com # remove one (by email or user_id)
uv run cgimg logout --all # remove every account
# The pool auto-rotates: it drains one account, then moves to the next. A deck
# bigger than your total quota stops and returns a PARTIAL deck + reset time.
# Note: rotating many accounts raises ban-detection risk - use throwaway accounts.
# 2. Generate image(s) (auto-enhance is ON by default; add --no-enhance to send the prompt as-is)
uv run cgimg gen "a serene mountain lake at dawn" --aspect 16:9 --n 1 --out out
uv run cgimg gen "AI agents for customer support" --style slide # clean editorial slide
uv run cgimg gen "real-time fraud detection" --style fintech # light-blue dashboard slide
uv run cgimg gen "ai agent" --aspect 1:1 --no-enhance # send prompt verbatim
uv run cgimg gen "Trí tuệ nhân tạo cho doanh nghiệp" --thinking max # max reasoning = best Vietnamese text
uv run cgimg gen "RAG pipeline" --style slide --accent "#10B981" --reserve-corner top-left # brand color + clear corner for a logo
# 3. Generate a multi-slide deck (one image per prompt; slides saved s01.png, s02.png...)
uv run cgimg deck --prompts "Intro" "How it works" "Pricing" --style slide --out deck.pptx
uv run cgimg deck --prompts-file slides.txt --thinking max --accent "#10B981" --reserve-corner top-left
# --prompts-file: one prompt per line (blank lines and lines starting with # are skipped)
# --no-enhance + --style: applies the slide look via a concise offline template (good for dense Vietnamese text)
# 4. Build a deck from existing images
uv run cgimg ppt img1.png img2.png --out deck.pptx --aspect 16:9
# 5. Branded deck — slides in your brand colors with your logo composited on each
uv run cgimg branded logo.png \
--prompts "What is RAG?" "RAG pipeline" "Benefits" \
--out deck.pptx --position top-left --scale 0.15
# 6. Styled deck — match a reference image's design (its text/content is NOT copied)
uv run cgimg styled reference-slide.png \
--prompts "Intro" "How it works" "Pricing" \
--out deck.pptxgen and deck accept --accent <hex> (forces a brand color) and --reserve-corner <pos> (keeps a corner clear for a logo you add later; the model draws no logo/text there). branded and styled also accept --aspect and --out-dir (default out). They print the deck path and each generated image path.
Aspect ratios
Aspect | Size sent | ChatGPT returns |
| 1920x1080 | ~1672x941 |
| 1024x1024 | 1024x1024 |
| 1024x1536 | ~1086x1448 |
| 1080x1920 | ~941x1672 |
| 1440x1080 | ~1448x1086 |
| as given | normalized by ChatGPT |
ChatGPT honors the ratio, not exact pixels — it normalizes to its own native dimensions (so 16:9 yields roughly 1672x941, not exactly 1920x1080). This is expected.
PPTX output is full-bleed: the image fills the slide edge to edge, so the image aspect should match the deck aspect to avoid cropping or letterboxing.
How it works
Vendors chatgpt2api's proven OAuth + image backend (under
src/cgimg/_vendor/).Stores a single account token locally at
%APPDATA%\cgimg\auth.json(Windows) or~/.config/cgimg/auth.json(Linux/macOS). It is never committed.Auto-refreshes the access token via the stored
refresh_tokenwhen it expires.
Examples
Showcase slides generated by this server live in examples/sample-slides/ — a mix of slide/fintech styles, dense multi-task slides, custom layouts, and tables.
Troubleshooting
Symptom | Cause / Fix |
| Run |
Token expired / auth errors | Re-run the login flow. |
Generation is slow (~30–90s per image) | Normal — it polls ChatGPT until the image is ready. |
Prompt rejected / blocked | ChatGPT's content moderation refused it. Adjust the prompt and retry — refusals are often transient ( |
Text in the image looks imperfect on a very dense slide | Image models can garble small text when a slide is packed. Reduce the content or split into more slides. |
Image dims aren't exactly what you asked | Expected — ChatGPT honors the ratio and normalizes to its native size. |
| OpenAI revoked the session, often after heavy/rapid checks (each |
Attribution & License
This project vendors code from:
chatgpt2api — Copyright (c) 2026 kunkun, MIT License. Powers the OAuth + image backend. Vendored under
src/cgimg/_vendor/.
Vendored files retain their original behavior. See NOTICE for details.
Available Tools
6 toolsbranded_deckB
Build a branded slide deck: auto-detect brand colors from the logo, generate slides in those colors, composite the original logo onto each slide, assemble PPTX.
| Name | Required | Description | Default |
|---|---|---|---|
| logo_path | Yes | ||
| prompts | Yes | ||
| aspect | No | 16:9 | |
| out_pptx | No | deck.pptx | |
| out_dir | No | out | |
| logo_position | No | top-left | |
| logo_scale | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the process steps (auto-detect colors, generate slides, composite logo, assemble PPTX) but lacks details on side effects, file overwrites, or required permissions. Moderate 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?
Single sentence that front-loads purpose and is efficient, but could be broken into structured steps for readability. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain parameter roles, output specifics, or error handling, leaving significant 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 0%, and the description does not elaborate on any of the 7 parameters. Only hints at 'logo' and 'prompts' implicitly. Fails to add meaning beyond the schema's default titles.
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?
Description clearly states the tool builds a branded slide deck with auto-detection of brand colors, slide generation, logo compositing, and PPTX assembly. It distinguishes from siblings like 'styled_deck' by emphasizing auto-detection from logo.
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?
Description implies use when needing a branded deck with logo-based color detection, but does not explicitly state when not to use or compare with alternatives like 'generate_slide_deck' or 'styled_deck'. Clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_pptxC
Assemble existing image files into a full-bleed PowerPoint deck.
| Name | Required | Description | Default |
|---|---|---|---|
| image_paths | Yes | ||
| out_path | No | deck.pptx | |
| aspect | No | 16:9 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions 'full-bleed' but does not explain what that entails (e.g., margins, image scaling). No details on ordering, resizing, or file handling, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks essential detail. While not verbose, it sacrifices completeness for brevity, so it does not earn a higher score.
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 absence of annotations, output schema, and any parameter descriptions, the description is severely incomplete. It fails to explain critical aspects like image order, aspect ratio handling, output location, or potential errors.
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%, and the description does not mention any parameters or their semantics. The agent must rely solely on parameter names (image_paths, out_path, aspect) which are insufficient for correct invocation.
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: 'Assemble existing image files into a full-bleed PowerPoint deck.' The verb 'assemble' and resource 'existing image files' give a specific action, and it is distinct from sibling tools like generate_image or styled_deck, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like branded_deck or generate_slide_deck. The description does not include context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageA
Generate image(s) from a text prompt at the given aspect ratio (16:9, 1:1, 3:4, 9:16, or WxH). Returns saved PNG file paths.
When enhance is True (default), the prompt is auto-expanded via the ChatGPT
text path before drawing. style='slide' = clean editorial slide (light cream,
one accent, hero visual); style='fintech' = premium light-blue dashboard look
(glass cards, blue icon badges, optional robot + charts). Both auto-complete
content into a full, information-rich slide (label + 2-line description per
point, sparse input expanded). style='auto' is the general default.| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| aspect | No | 16:9 | |
| n | No | ||
| out_dir | No | out | |
| enhance | No | ||
| style | No | auto |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the auto-expansion behavior when 'enhance' is True and explains the style behaviors. It also states the output format (PNG file paths). Does not cover auth or rate limits, but reasonable for this 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 well-structured with clear sections for aspect ratios and styles, but somewhat long. Core purpose is front-loaded. Could be slightly more concise by moving style details to secondary position.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description covers input, key behaviors, and output format. Missing details on aspect format constraints and error handling, but generally 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 has 0% description coverage; the description compensates by explaining 'prompt', 'aspect' with examples, 'enhance', 'style'. However, 'out_dir' is not explained, and 'n' is only implicitly mentioned.
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 generates image(s) from a text prompt with given aspect ratio and returns PNG file paths. It distinguishes from sibling tools like 'styled_deck' which are deck-focused.
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 explains when to use 'enhance' and describes specific styles ('slide', 'fintech'), but does not explicitly state when not to use this tool or compare to alternatives like 'styled_deck'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_slide_deckA
Generate one image per prompt then assemble them into a PPTX deck.
Each prompt should be the CONTENT of one slide. style='slide' (default here) applies a clean editorial presentation design (light, restrained accent, one hero visual, short labels, takeaway banner) — pass raw slide content and the enhancer designs it. Set enhance=False to send prompts verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| prompts | Yes | ||
| aspect | No | 16:9 | |
| out_pptx | No | deck.pptx | |
| out_dir | No | out | |
| enhance | No | ||
| style | No | slide |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (generating images and assembling into PPTX) and explains the effect of the style and enhance parameters. It does not contradict any annotations and adds sufficient context for safe invocation.
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 efficient, with the main action in the first sentence. Subsequent sentences add necessary detail without fluff. Slightly longer than ideal but earns its length.
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 6 parameters and no output schema, the description covers the purpose, all parameters, and behavioral choices. It does not discuss return values or errors, but for a generation tool this is acceptable. It provides enough context for correct 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 coverage is 0%, so the description must compensate. It adds meaning to each parameter: 'prompts' as 'CONTENT of one slide', explains the default style, and clarifies the enhance flag. This goes well beyond the raw schema, making the parameters understandable.
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 starts with 'Generate one image per prompt then assemble them into a PPTX deck,' clearly stating the verb and resource. It distinguishes from siblings by detailing the style and enhance options, which are specific to this tool.
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 on using the style parameter ('style='slide' (default here) applies a clean editorial presentation design') and the enhance parameter ('Set enhance=False to send prompts verbatim'). It implies the intended use case for slide decks but does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
login_statusA
Check whether a ChatGPT account is logged in for image generation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only check with no side effects, but lacks details on what happens when not logged in, error conditions, or return behavior. Since no annotations exist, the description carries the full burden but provides only basic 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?
Description is a single concise sentence front-loading the core purpose with no wasted words.
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?
Tool is simple with no parameters or output schema, but description does not specify the return type (e.g., boolean or status string), leaving room for ambiguity. Agent would benefit from knowing what the output represents.
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?
No parameters, so schema coverage is 100%. Baseline is 4; description adds no extra meaning beyond the empty schema, which is acceptable.
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?
Description clearly states the tool checks login status for image generation, using specific verb and resource. It implicitly distinguishes from sibling tools which generate content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Although it is implicitly a precondition for image generation, the description does not explicitly state that it should be used before calling generate_image or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
styled_deckB
Generate a deck matching a reference design image's style and colors (content not copied).
| Name | Required | Description | Default |
|---|---|---|---|
| ref_image | Yes | ||
| prompts | Yes | ||
| aspect | No | 16:9 | |
| out_pptx | No | deck.pptx | |
| out_dir | No | out |
TDQS
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 style copying and not content copying but does not disclose potential side effects, output file creation, or required permissions. The tool creates files but this is not stated.
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 single-sentence description is concise and front-loaded with the key action, but it lacks structure and fails to earn its place for parameter 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 (5 params, no output schema, no annotations), the description is incomplete. It does not explain parameters, return values, or behavior beyond the basic purpose.
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?
With 0% schema description coverage and 5 parameters, the description adds no meaning beyond the schema. Only 'ref_image' is indirectly explained by 'matching a reference design image's style and colors'. Prompts, aspect, out_pptx, out_dir are unmentioned.
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 'Generate a deck matching a reference design image's style and colors (content not copied)' clearly states the specific verb ('Generate'), resource ('deck'), and what distinguishes it from similar tools (style matching, not content copying).
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 context (when you want a deck styled like a reference image) but provides no explicit guidance on when to use this tool versus siblings like branded_deck or generate_slide_deck, nor any exclusion criteria.
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.
6 tool updates
v0.1.0- First observed
branded_deck - First observed
build_pptx - First observed
generate_image - First observed
generate_slide_deck - First observed
login_status - First observed
styled_deck
TDQS
Tools are mostly distinct: branded_deck uses a logo, styled_deck uses a reference image, generate_slide_deck uses text prompts, and build_pptx assembles existing images. login_status is orthogonal. Minor potential confusion between branded_deck and styled_deck but descriptions clarify.
Naming is inconsistent: some use verb_noun (build_pptx, generate_image), others use adjective_noun (branded_deck, styled_deck), and login_status follows a different pattern. No strong convention is maintained across the set.
6 tools is a reasonable count for a slide generation server. Each serves a distinct purpose in the creation workflow, and the number feels well-scoped without being too sparse or bloated.
The tool surface covers key slide generation capabilities: creating from prompts, logos, reference styles, and assembling existing images. Minor gaps like editing existing decks or converting formats are acceptable for the stated purpose.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Build decks in your own brand, from the AI agent you already use. Then edit them yourself.
Deterministic, fully editable PowerPoint from typed slide intents. 200+ layouts, brand templates.
Generate branded images at scale: design templates and render them to PNGs by prompt.
- emplusxOAuthcom.emplusx
Finished, on-brand .pptx and .docx from a brief - quality-gated by an agentic consulting team.
Related MCP Servers
- AlicenseAqualityDmaintenanceCreates and manipulates PowerPoint presentations with capabilities for adding various slide types, generating images, and incorporating tables and charts through natural language commands.11144MIT
- AlicenseNot gradedqualityCmaintenanceCreates professional PowerPoint presentations from Markdown or JSON with intelligent layout recommendations, rich content support including tables and images, and automatic template selection based on content analysis.7Apache 2.0
- FlicenseNot gradedqualityCmaintenanceGenerates PowerPoint presentations from templates using AI, injecting text and images based on schema definitions.1-
- FlicenseNot gradedqualityCmaintenanceEnables AI-powered generation of PowerPoint presentations with dynamic content, themes, and tones. Supports custom topics, audience, and slide count via the generate_ppt tool.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/vuhai2002/ai-slides-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server