This server is an AI-driven PowerPoint deck creation tool that generates .pptx files from structured slide plans, applies design themes, and auto-generates images via ComfyUI.
Create presentations (create_presentation): Build a complete .pptx deck from a JSON slide plan, automatically generating images for slides with prompts, embedding existing images from local paths or URLs, and applying a chosen design theme.
List and inspect design themes (list_themes, get_theme): Retrieve available themes (e.g., dark_tech, corporate, minimal, academic) and their full definitions — color palettes, fonts, and image style descriptors.
Generate individual images (generate_image): Produce AI-generated images via a ComfyUI backend using a text prompt, with optional theme scoping, output size, negative prompt, and role (content or background). Returns the local file path.
Inspect ComfyUI models (list_comfy_models): Query the ComfyUI HTTP API to discover available checkpoints, samplers, and schedulers.
Highly configurable: Supports multiple image generation backends (remote ComfyUI MCP server or direct ComfyUI API) and server transports (stdio, SSE, streamable-http) via environment variables.
Docker support: Can be run in a Docker container or with Docker Compose.
Integrates with AI orchestrators: Designed to be called by tools like Open WebUI to execute document creation tasks.
Allows uploading generated .pptx files to a MinIO/S3 bucket, returning a direct link or presigned URL for retrieval, configurable via environment variables such as MINIO_ENDPOINT, MINIO_ACCESS_KEY, etc.
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., "@document-creation-mcp Create a 5-slide deck on quantum computing using the 'corporate' theme."
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.
MCP server for AI-driven document creation, starting with PowerPoint decks.
The server is the execution layer: it builds .pptx files from a structured
slide plan, applies consistent design themes, and auto-generates images via your
existing ComfyUI MCP server. The orchestrating model (e.g. in Open WebUI) does
any web research and composes the slide plan, then calls these tools.
Tool | Purpose |
| List available design theme names. |
| Return a theme's colors/fonts/image-style (incl. its |
| List the slide layouts the builder supports. |
| List the named per-slide variants on a theme. |
| Dry-run a plan: per-slide effective layout + warnings, without generating anything. |
| Generate one image via ComfyUI MCP; returns local path. |
| Build a deck from a |
| List checkpoints/samplers/schedulers available on the ComfyUI HTTP API. |
create_presentation will auto-generate any image that has an image.prompt
(using ComfyUI), and embed existing files/URLs when image.source is set.
Related MCP server: docx-forge-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e .Variable | Default | Meaning |
|
| Where |
|
| Where generated images are cached. |
|
| Transport for the server itself: |
|
| Bind address when serving over HTTP/SSE. Defaults to localhost for security; set |
|
| Port the server listens on for |
|
| Endpoint path for |
|
| Run streamable-http in stateless mode (no session). Recommended behind proxies (MetaMCP/Open WebUI) to avoid |
| (bundled) | Directory of |
|
| Image source: |
MCP backend ( | ||
| (none) | Address of your running ComfyUI MCP server, e.g. |
| (none) | Bearer token sent as |
|
|
|
|
| Name of the image tool in that server. |
| (fallback) | Only used if |
Direct API backend ( | ||
| (none) | Base URL of the ComfyUI instance, e.g. |
| (none) | Optional bearer token for the ComfyUI endpoint. |
| (auto) | Checkpoint to load. When unset, auto-selected from installed checkpoints (SDXL-style preferred). |
|
| KSampler steps / CFG scale. |
|
| KSampler sampler / scheduler (auto-matched to installed values). |
|
| Seed ( |
| (none) | Optional explicit VAE name for decoding, e.g. |
|
| When enabled (default), the |
|
| Seconds to wait for image generation (both backends). |
|
| Skip all image generation. |
|
| When |
MinIO / S3 retrieval ( | ||
| (none) | MinIO/S3 endpoint, e.g. |
| (none) | S3 access key id / secret access key (the MinIO username / password). Set these to match the credentials used elsewhere (e.g. an n8n S3 node). Optional only for anonymous / proxy-authenticated instances. |
|
| Target bucket (created if missing). A |
|
| Use HTTPS to the endpoint (usually |
|
| Region (default |
| (none) | If set (e.g. |
|
| Set |
|
| Upload objects with a public-read grant so browsers / Open WebUI can fetch them directly (same as n8n's S3 |
|
| Lifetime (hours) of the presigned URL when no public URL is set. |
| (none) | Object-name prefix inside the bucket, e.g. |
document-creation-mcp # stdio transport (recommended for Open WebUI)
# or: python -m document_creation_mcp.serverBuild and run the server inside a container.
# Build the image
docker build -t document-creation-mcp .
# Run with streamable-http transport (default in the Dockerfile)
docker run -p 8000:8000 \
-e COMFY_MCP_COMMAND='["python","-m","comfy_mcp_server"]' \
-v "$(pwd)/output:/app/output" \
document-creation-mcpOr use the provided Compose file:
docker compose up --buildThe container serves on port 8000 using streamable-http by default. Generated
.pptx files are written to /app/output (mount ./output to retrieve them).
Override DOC_MCP_TRANSPORT=stdio if you instead want the container spawned as a
stdio MCP server by its parent.
Start your ComfyUI MCP server separately (the command above must reach it).
In Open WebUI → Admin → Tools → Add MCP server, point at this server
(stdio command: document-creation-mcp, or an SSE URL if you wrap it).
The model can now call create_presentation (after doing web search and
drafting the plan) and generate_image for bespoke visuals.
When running this server in Docker, register it as an HTTP/SSE MCP server
pointing at http://<host>:8000/mcp (streamable-http) or /sse instead of the
stdio command.
The server only listens for sse / streamable-http when
DOC_MCP_TRANSPORT is set to one of those (the Docker image defaults to
streamable-http).
It must be reachable from the client: set DOC_MCP_HOST=0.0.0.0 and
publish the port (e.g. ports: ["3335:3335"] in Compose with
DOC_MCP_PORT=3335). A Connection refused means the container isn't up,
isn't on that port, or is bound to 127.0.0.1.
The client URL must include the endpoint path:
default → http://<host>:<port>/mcp
if your client POSTs to the server root (some MetaMCP setups do), set
DOC_MCP_STREAMABLE_HTTP_PATH=/ and use http://<host>:<port>/.
A 404 Not Found on a POST means the path didn't match — adjust
DOC_MCP_STREAMABLE_HTTP_PATH or add /mcp to the URL. Intermittent 404s
on /mcp (especially from different client IPs) are usually stateful-session
rejects from a proxy; set DOC_MCP_STATELESS_HTTP=true (the default) so each
request is handled without a session.
create_presentation writes the .pptx to DOC_MCP_OUTPUT_DIR and returns its
path. Because the server runs in a container, that path is internal — to get the
file:
MinIO (best for shared access): set MINIO_ENDPOINT (with keys). The tool
uploads the file and returns a download.url — a direct link if
MINIO_PUBLIC_URL is set, otherwise a presigned GET URL. Anyone with the link
can fetch the deck; the container needs the minio extra installed (the Docker
image includes it).
Base64 (no infra): keep DOC_MCP_RETURN_BASE64=true (default). The tool
result includes a download field with filename, mime_type and base64
data. Save/decode that to get the file through the chat client (Open WebUI).
Mounted volume: mount DOC_MCP_OUTPUT_DIR (the Compose file mounts
./output:/app/output) and read ./output/<name>.pptx from the host, then set
DOC_MCP_RETURN_BASE64=false to avoid the base64 in context.
The download object may contain any combination of url, data and
minio_error (if an upload failed but the deck was still built).
Factory themes ship inside the package at src/document_creation_mcp/themes/*.yaml
(dark_tech, corporate, minimal, academic, night), so they are always
available after install, including in Docker.
name: dark_tech
colors:
background: "#0B0E14"
primary: "#4F8CFF"
accent: "#00E0C6"
text: "#E6EAF2"
muted: "#8A93A6"
fonts:
heading: "Montserrat"
body: "Inter"
image_style: "cinematic, neon accents, dark moody background, 8k, highly detailed"
layout_default: title_and_content
logo: nullimage_style is appended to every generated image prompt for visual consistency.
Add or override themes: set DOC_MCP_THEME_DIR to a directory of *.yaml
files (e.g. a mounted volume in Docker). Its themes are merged on top of the
bundled ones, so a file with the same name overrides a factory theme.
Inheritance: a theme may set extends: <other-theme-name> and only override
the keys it wants; the base theme's other values are inherited (deep-merged, own
values win). The bundled night theme is an example (extends: dark_tech).
Variants: a theme can declare named per-slide variants:
name: dark_tech
variants:
sunset:
colors:
accent: "#FF6B6B"
primary: "#FFA94D"
image_style: "cinematic, warm sunset tones, neon accents, 8k, highly detailed"Apply one per slide with "theme_variant": "sunset" (or
theme_manager.get("dark_tech").apply_variant("sunset") in code). Per-slide
"theme_override" merges an arbitrary partial theme dict on top of that.
Transitions: transition: fade | push | wipe | none sets the default slide
entry transition (per-slide "transition" overrides it).
Note:
style_reference_image/controlnet.reference_imagepaths are resolved at runtime — in Docker, mount those assets and use absolute paths (or paths relative to the container working directory). The optional advanced workflowCOMFY_API_WORKFLOWsimilarly needs to be mounted into the container.
To refresh after editing theme files, the server reloads them on startup; there
is also a list_themes() tool to confirm what is loaded.
IMAGE_BACKEND=comfy_api drives ComfyUI directly and needs no workflow
JSON. On first generation it queries the instance's /object_info to discover
every installed model — checkpoints, LoRA, ControlNet, IP-Adapter,
CLIP-Vision and upscalers — then assembles a consistency pipeline in code using
only what is present (the checkpoint's built-in VAE decodes the output; set
COMFY_API_VAE only to force a specific VAE):
Checkpoint ─► [IP-Adapter] ─► [ControlNet] ─► KSampler ─► VAEDecode
│
[Upscale] ─► SaveImageBracketed nodes are inserted conditionally, so a bare text-to-image graph is used when only a checkpoint is available, and the full IP-Adapter + ControlNet + upscale pipeline kicks in automatically as more models are installed. There is nothing to configure by hand.
Purpose | Suggested model(s) | Effect when present |
Base checkpoint |
| Auto-selected (SDXL-style preferred). |
VAE |
| Optional. Set |
CLIP Vision |
| Enables IP-Adapter. |
IP-Adapter |
| Locks every slide to one deck-wide style. |
ControlNet |
| Keeps subjects off-centre so text stays readable. |
Upscaler |
| Sharper projector-grade output. |
Custom nodes |
| Provide the IP-Adapter / ControlNet nodes. |
Auto style reference. If a theme sets style_reference_image it is used;
otherwise the backend generates one anchor image per deck from the theme's
image_style and feeds it to IP-Adapter, so all slides share a look with no
supplied asset.
Per-role presets (ImageSpec.target):
background → stronger ControlNet + auto dim/blur post-process for legibility.
content → balanced style + composition lock.
icon → lighter composition control, placed as a small top-right asset.
Shared negative prompt + palette. The deck/theme negative_prompt and the
theme image_style suffix are applied to every prompt.
Graceful degradation. Missing ControlNet / IP-Adapter / upscaler → that stage is skipped; the graph always submits successfully.
name: dark_tech
image_style: "cinematic, neon accents, dark moody background, 8k, highly detailed"
style_reference_image: "themes/refs/dark_tech_style.png" # optional; auto-generated if omitted
ip_adapter_weight: 0.7
ip_adapter_weight_type: null # optional; omit so the node uses its own default
# (enum varies between IP-Adapter versions)
controlnet:
enabled: true
type: depth # depth | canny | openpose | tile
strength: 0.6
reference_image: "themes/refs/dark_tech_comp.png"
upscale_model: "4x-UltraSharp.pth" # optional; auto-selected if omitted
negative_prompt: "watermark, text, blurry, low quality, jpeg artifacts"
background_post: "dim" # light blur + dark overlay so text stays readable
contrast_target: 4.5 # min WCAG contrast ratio for body text on backgrounds
slide_backgrounds: true # per-slide AI background derived from each slide titleSet COMFY_API_AUTODISCOVER=false only if you want to pin specific model names
via the COMFY_API_* env vars instead of auto-detection.
create_presentation takes the plan as a JSON object (not a string). Slide
text is given as bullets (a list of strings) or content (a string, which is
split on newlines, or a list).
{
"title": "Deck title",
"theme": "dark_tech",
"output_filename": "my_deck",
"bucket": "presentations",
"slides": [
{"title": "Intro", "layout": "title", "subtitle": "An AI deck"},
{"title": "Topic", "bullets": ["Point 1"], "image": {"prompt": "futuristic city"}},
{"title": "Deep dive", "layout": "image_full", "image": {"prompt": "data flow"}},
{"title": "Roadmap", "layout": "timeline",
"timeline": [{"time": "Q3", "text": "Ship v2"}, {"time": "Q4", "text": "Go global"}]},
{"title": "By the numbers", "layout": "stats",
"stats": [{"value": "$4.2M", "label": "Revenue"}, {"value": "61", "label": "NPS"}]},
{"title": "Versus", "layout": "comparison",
"comparison": {"left_header": "Us", "left_points": ["Fast", "Cheap"],
"right_header": "Them", "right_points": ["Slow", "Costly"]}},
{"title": "Steps", "layout": "steps", "steps": ["Hire", "Ship", "Repeat"]},
{"title": "Grid", "layout": "gallery",
"gallery": [{"prompt": "mountain"}, {"prompt": "ocean"}]},
{"title": "Pinned variant", "bullets": ["a", "b"], "variant": 2,
"notes": "Speaker notes go in the notes pane."},
{"title": "Branded slide", "bullets": ["custom colors here"],
"theme_variant": "sunset",
"theme_override": {"colors": {"background": "#1B2A4A"}}}
]
}Layouts: title, title_and_content, two_column, image_full, section,
stats, comparison, timeline, steps, gallery. Slides with the default
title_and_content are auto-routed by content type (stats → stats,
comparison → comparison, etc.), so you can omit layout and just provide the
matching content field. Use validate_plan to preview the routing before
building. The optional bucket field sets the MinIO bucket for this deck
(overrides MINIO_BUCKET env).
Beyond plain bullets, each slide may carry:
Nested bullets — bullets may be a list of lists (sub-levels are indented)
or BulletItem-shaped dicts ({"text": "...", "level": 1, "style": "•"}).
Inline formatting — in any slide text: **bold**, *italic*,
~~strike~~, ==highlight==, `code` (monospace), [text](url) links,
~sub~ and ^sup^.
Tables — "table": {"headers": [...], "rows": [[...]]} (or a bare list of
rows); banded + header bar.
Code blocks — "code": {"language": "python", "code": "..."},
syntax-highlighted (Pygments).
Quotes — "quote": {"text": "...", "author": "..."} — a callout card.
Notes — "notes": "..." rendered into the PowerPoint notes pane.
Transitions — per-slide "transition": "fade" | "push" | "wipe" | "none"
(default comes from the theme).
Per-slide theming — theme_variant picks a named theme variant;
theme_override deep-merges a partial theme dict (e.g. colors) for one slide.
Instead of repeating one template, content slides vary deterministically:
Per-slide backgrounds. Each content slide (except title / section /
image_full) gets an AI background generated from its own title, cached on
disk by theme + title so repeated decks don't regenerate. Disable with
slide_backgrounds: false in the theme.
Adaptive text + scrim. The builder samples each background's mean colour,
then picks a text colour and adds a translucent full-slide scrim so body text
always meets contrast_target (default 4.5) under WCAG contrast. Theme
heading colours are kept when they still clear the target, otherwise text
falls back to the adaptive readable colour.
Layout variants. title_and_content slides rotate through three
arrangements (bullets full-width / two-column / centered title) and
two_column alternates image left vs. right, chosen by a hash of the slide
context. Force a specific variant per slide with the variant field:
Create a PowerPoint deck from a structured plan and return the file path.
The orchestrating model is expected to do any web research and produce the
slide plan. plan_json is a JSON string matching PresentationPlan:
{ "title": "Deck title", "theme": "dark_tech", "output_filename": "my_deck", "slides": [ {"title": "Intro", "layout": "title", "subtitle": "An AI-generated deck"}, {"title": "Topic", "bullets": ["Point 1", "Point 2"], "image": {"prompt": "futuristic city", "target": "content"}}, {"title": "Deep dive", "layout": "image_full", "image": {"prompt": "abstract data flow"}} ] }
Images declared with a prompt are auto-generated via ComfyUI. To reuse an
existing image, set image.source to a local path or URL instead.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 reveals that images are auto-generated via ComfyUI, and outlines the expected role of the model. This adds useful behavioral context, though it doesn't address error handling or potential side effects.
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, front-loading the purpose and then providing instructions and an example. At around 150 words, it is informative without being overly verbose, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a deck with auto-generated images, the description covers all necessary aspects: input format, model responsibility, image handling, and expected output (file path). The presence of an output schema (indicated in context) ensures return values are documented.
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%, but the description provides a detailed JSON example of the plan_json parameter, explaining each field and optional elements. This adds significant meaning beyond the schema's type definition, fully compensating for the lack of schema documentation.
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 'Create a PowerPoint deck from a structured plan and return the file path', providing a specific verb ('create') and resource ('PowerPoint deck'). The example of the JSON plan distinguishes it from sibling tools like generate_image, which produce images instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs that 'The orchestrating model is expected to do any web research and produce the slide plan', providing clear context for when this tool should be invoked. It also explains image generation behavior, though it lacks explicit exclusions or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a single image via the ComfyUI MCP server and return its local path.
Args:
prompt: Base image description.
theme: Theme whose image_style is appended for consistency.
size: Output size, e.g. "1024x1024".
negative_prompt: Optional negative prompt.
target: "content" or "background".
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 1024x1024 | |
| theme | No | dark_tech | |
| prompt | Yes | ||
| target | No | content | |
| negative_prompt | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full burden. It reveals generation and local path return but omits side effects, permissions, resource consumption, or failure behavior. For a generation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise but includes a bullet-like arg list that largely repeats schema information. Front-loaded with main purpose, but some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain how the output local path is structured or any server prerequisites. The 'theme' and 'target' parameters lack full context. For a 5-parameter tool, completeness is average.
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%, but the description explains all five parameters: prompt, theme, size, negative_prompt, target. It adds meaning beyond bare schema by clarifying 'theme' appends image_style and 'target' distinguishes content vs background. Minor lack of format 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?
Description clearly states 'Generate a single image' and specifies the server (ComfyUI MCP) and output (local path). It distinguishes from sibling tools like create_presentation and list_comfy_models, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, context for selection, or exclusions. It only lists parameters without usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full definition (colors, fonts, image style) of a theme.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states it returns a full definition but omits any info on read-only nature, authentication needs, or error behavior. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without any filler. Highly concise and 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?
Given the presence of an output schema (not shown but exists), the description doesn't need to explain return values. However, it lacks usage guidance and parameter details, making it minimally adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no description in schema). The tool description does not explain what the 'name' parameter represents (e.g., theme name, ID, where to find valid values). It adds no meaning beyond the schema property title.
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 ('Return'), the resource ('full definition of a theme'), and specific content ('colors, fonts, image style'). It effectively distinguishes from sibling tools like list_themes and create_presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., list_themes or generate_image). The description lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models available on the ComfyUI HTTP API (checkpoints/samplers/schedulers).
Useful to see what the direct comfy_api backend can use, and to pick a
value for COMFY_API_CHECKPOINT. Requires IMAGE_BACKEND=comfy_api and
COMFY_API_URL to be set.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like idempotency, safety, or error handling. It only implies a read operation but lacks explicit statements about side effects or behavior when prerequisites are not met.
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: two sentences that front-load the purpose and efficiently provide usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the existence of an output schema (which removes the need to explain return values), the description covers the tool's purpose, examples of what is listed, and prerequisites. It is complete for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4 as per instructions. The description adds no parameter information because none exist, and the schema coverage is trivially 100%. No additional meaning is needed.
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 'List' and identifies the resource as 'models available on the ComfyUI HTTP API', with examples (checkpoints/samplers/schedulers). It clearly distinguishes itself from sibling tools like create_presentation or generate_image.
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 its usefulness for viewing backend capabilities and selecting a checkpoint value, and lists the required environment variables (IMAGE_BACKEND, COMFY_API_URL). However, it does not explicitly mention when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available design theme names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a read-only listing operation, which is appropriate, but does not disclose potential pagination, ordering, or performance characteristics. For a simple list, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, directly states the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete enough for its simplicity. However, it could mention if the list is sorted or if it includes all themes without restrictions.
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 exist, so baseline 4 applies. The description does not add parameter information because there are none.
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 'List the available design theme names' uses a specific verb (List) and resource (design theme names), clearly distinguishing from sibling tools like 'get_theme' which retrieves a single theme.
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. For example, it does not suggest using this to see all themes before employing 'get_theme' to retrieve details of a specific one.
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. Dates show when Glama detected each change.
v0.1.0create_presentationgenerate_imageget_themelist_comfy_modelslist_themesEach tool has a distinct purpose: creating full presentations, generating images, retrieving themes, listing models, and listing themes. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_presentation, generate_image). No mixing of conventions.
Five tools is an appropriate scope for document creation, covering creation, image generation, and theme management without being excessive or insufficient.
Core workflows (create presentation, generate images, manage themes) are covered. Missing tools for updating or deleting presentations, but this is acceptable for a creation-focused server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Presentations.AI MCP server — create designed slide decks from a topic, text, or document.
MCP server for Wan AI video generation
AI presentation and report generation: slides, diagrams, PPTX export, live preview MCP App.
MCP server for Qwen Image 3 AI image generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheRealChickenlegs/document-creation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
