This MCP server generates self-contained A4‑landscape HTML presentation pages for bids, technical proposals, and reports, from pre‑paginated structured text. It provides a complete workflow:
Content Processing – Parse raw Markdown/plain text into structured content and image prompts (parse_source_content).
Template Management – List, load, and create templates from HTML, screenshots, or blueprints; auto‑select best template via planning.
Page Generation – Fill placeholders with direct text or LLM expansion (fill_placeholders), generate and inject images (generate_image), render local SVG icons (render_icons), and assemble the final HTML (assemble_page).
Quality Assurance – Validate pages for residual placeholders, icon rendering, image validity, and HTML correctness; enforce hard gates (size, overflow, contrast, etc.) with automatic fixes.
Orchestration – Plan multi‑page decks (plan_deck), generate pages with external asset injection, run cross‑page consistency checks, and support breakpoint resume.
Security & Portability – API keys only from environment variables; no path, URL, or key parameters accepted. Works over MCP stdio.
Provides integration with OpenAI's API for LLM text expansion and DALL-E image generation.
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., "@PPT Generator MCP generate a proposal page from the green-infographic-bid template"
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.
把已经分页的中文标书、技术方案或汇报正文，稳定转换成经过逐页 QA 的 A4 横向 HTML 展示页。
它会理解每页内容、选择兼容模板、提出图片需求、接收 Agent 生成的图片，并在真实 Chromium 中检查溢出、字号、碰撞、对比度、图片和事实覆盖。最终交付是可独立打开的自包含 final.html，不要求生成 .pptx。
第一次使用或不熟悉技术：完整非技术用户指南
需要了解算法、数据结构、安全和扩展方式：架构与实现原理
需要维护现有模板：green-infographic 模板说明
如果 Agent 已经连接 ppt-generator，准备好编号正文，复制下面的提示词即可。更省心的方式是直接让 Agent 调用 generate-bid-deck 技能（在支持技能的项目内运行 /generate-bid-deck，或要求 Agent 遵循技能说明）；完全没有图片 API 时，可用一键脚本自动生成带主题占位图的完整交付件：
请使用 ppt-generator MCP，把下面的编号正文生成正式标书风格的 HTML 展示页。
1. 校验 <page N> 和 pageNumbers，不要自动分页。
2. 调用 plan_deck，documentType=bid，templateDiversity=balanced。
3. 保留原文事实、数字、日期、范围、否定和责任关系。
4. 如果返回 assets，只按原资产 ID 和 prompt 生成图片；没有图片 API 时使用当前 Agent 的图片生成能力。
5. 调用 generate_deck；needs_assets 时补齐素材并复用同一个 requestId。
6. 逐页检查 QA 和整套 consistency。只有 deck 和每页均为 delivered 才交付。
7. 使用 get_deck 取回每页 final.html、quality.json 和整套 consistency.json。
正文：
[在这里粘贴完整编号正文]详细的 Agent 提示词、验收表和常见问题见非技术用户指南。
要求 Node.js 22 或更高版本。首次安装：
git clone https://github.com/SUSTechWLA/ppt-generator-mcp.git
cd ppt-generator-mcp
npm install
npx playwright install chromium
npm run check把下面配置加入支持 stdio MCP 的 Agent 或客户端，并将 cwd 改为项目的真实绝对路径：
{
"mcpServers": {
"ppt-generator": {
"command": "node",
"args": ["dist/src/server.js"],
"cwd": "/您的绝对路径/ppt-generator-mcp"
}
}
}保存后重启客户端。Agent 能看到 plan_deck、generate_deck 和 get_deck，即表示连接成功。项目也提供了可直接调整的 .mcp.json。完整安装排查见从零安装说明。
Related MCP server: Quick Design
上游必须先完成分页。每个 <page N> 独占一行，页码严格递增；每页至少有一个标签化标题，随后是 正文： 和实际内容。
<page 59>
一级标题：第一分节：优势与有利条件分析
二级标题：2.1 项目需求深度理解
三级标题：2.1.1 项目背景与采购需求解读
正文：
项目服务覆盖三个业务区域，要求在合同生效后30日内完成首轮建档。
项目团队须建立7×24小时响应机制，并按月提交质量分析报告。
<page 60>
一级标题：第一分节：优势与有利条件分析
二级标题：2.2 服务方案
三级标题：2.2.1 实施路径
正文：
实施过程分为启动准备、全面执行、持续优化三个阶段。调用 plan_deck 时，pageNumbers 必须是 [59, 60]。59、60 只是上游编号示例，不参与模板特判；高层 workflow 不猜页码，也不自动重新分页。
正文中的 ；；、；。 等重复或冲突标点会统一规范化，但数字、比例、日期、范围、否定和责任关系仍作为来源证据保留。格式规则和错误示例见准备正文。
flowchart LR
A["编号正文"] --> B["plan_deck：规划页面和模板"]
B --> C{"需要图片？"}
C -- "是" --> D["外部 Agent 按资产 ID 生成"]
C -- "否" --> E["generate_deck"]
D --> E
E --> F["逐页 QA 与定向修复"]
F --> G["整套一致性检查"]
G --> H["get_deck：取回 HTML 和报告"]plan_deck 固化正文事实、页面内容、模板选择和图片提示词，返回 deckPlanId。
若返回 assets，调用方只按原 ID 和 prompt 生成图片，并转换为 PNG、JPEG 或 WebP data URL（不接受 SVG：其内部脚本对校验层不透明）。
generate_deck 按不可变计划注入素材、生成页面，并独立执行 Chromium QA。
返回 needs_assets 时补齐 missingAssetIds，复用同一个生成 requestId 继续。
只有整套 status=delivered 且每页均为 delivered 才能正式交付。
get_deck 按返回的 UUID 读取每页 final.html、quality.json 和整套 consistency.json。含内嵌图片的 final.html 通常超过公共文本上限，get_deck 会返回 html_unavailable 并给出相对运行根目录的路径（如 <runId>/final.html），本地 Agent 直接按该路径读取即可。
规划示例：
{
"sourceText": "<page 59>\n一级标题：第一分节\n二级标题：2.1 服务理解\n三级标题：2.1.1 采购需求解读\n正文：\n这里是已经分页的事实正文。",
"pageNumbers": [59],
"documentType": "bid",
"templateDiversity": "balanced",
"audience": "招标评审专家与项目业主",
"quality": { "minScore": 90, "maxAttempts": 3 },
"requestId": "proposal-plan-20260731"
}生成示例：
{
"deckPlanId": "plan_deck 返回的 UUID",
"externalAssets": [
{ "id": "p59-img-001", "dataUrl": "data:image/png;base64,真实图片内容" }
],
"requestId": "proposal-run-20260731"
}没有图片需求时，externalAssets 传空数组。MCP 不会在规划阶段偷偷调用图片服务；没有图片 API 时，可由 Agent 使用自身图片能力生成后注入。完整操作过程见一次完整生产流程。
整套状态：
状态 | 含义 | 是否可交付 |
| 仍缺计划要求的图片，可以恢复 | 否 |
| 正在生成或恢复 | 否 |
| 有失败页或一致性问题 | 否 |
| 所有页面和整套检查通过 | 是 |
| 没有形成可继续的安全结果 | 否 |
每个页面都有独立 runId。通过 get_deck 读取该页的 final.html、quality.json 和 manifest.json；通过整套 deckRunId 读取 manifest 和 consistency.json。
本机默认目录是 output/runs：
output/runs/
├── <page-runId>/
│ ├── final.html
│ ├── final.png
│ ├── quality.json
│ ├── manifest.json
│ └── assets/
├── decks/
│ ├── plans/<deckPlanId>/plan.json
│ └── runs/<deckRunId>/
│ ├── manifest.json
│ └── consistency.json
└── template-knowledge/高层 MCP 接口只按 UUID 和白名单产物名读取，不接受任意路径。状态解释和验收方式见如何判断是否可以交付。
先做硬门禁，再考虑多样性：
每个模板独立证明能够容纳本页事实、语义角色、文字容量、图片数量、最低字号和文档类型；
失败候选直接淘汰；
只有接近本页最佳质量的成功候选，才参与整套组合选择；
整套选择奖励不同版式、惩罚连续重复，同时保持确定性和可复现。
templateDiversity 提供四种模式：
模式 | 建议用途 |
| 每页只选自己的局部质量赢家 |
| 极克制地打破近似平局 |
| 默认推荐；在窄质量范围内兼顾质量和整套节奏 |
| 更强调视觉变化，但仍不放松硬门禁 |
如果某页只有一个完整成功候选，重复模板就是正确结果。这个选择器不是强化学习：没有训练、探索或在线奖励更新；相同正文、模板目录和参数会得到相同结果。更详细的选择顺序和质量带见架构文档。
严格分页协议，不猜页码，不自动切页；
中文重复和冲突标点规范化；
事实、数字、日期、范围、否定与责任关系覆盖；
卡片与信息图组件使用来源正文派生的真实主题词，而不是通用角色标签；
高密度双栏文字版式与图文版式由模板多样性自动交替，整套页面版式不单调；
通用模板能力匹配，不针对页码、正文或模板名写特例；
整套页面的确定性模板多样性选择；
稳定图片 ID 和外部素材注入；
每页独立 Chromium QA，最多三轮定向修复；
中文页面硬门禁：系统无可用中文字体时拒绝交付（避免缺字方框通过 QA）；
整套一致性检查、幂等恢复和脱敏产物读取；
从参考 HTML、截图或通用蓝图沉淀模板知识；
文本、图片和复核 Provider 均为可选。
基本原理的非技术解释见为什么结果更稳定，完整实现见架构与实现原理。
普通多页生产只需要下面六个高层工具：
工具 | 用途 |
| 编号正文 → 不可变页面计划、模板证据和图片提示词 |
| 外部素材 → 页面生成、逐页 QA 和整套一致性检查 |
| 按 UUID 读取计划、manifest 和白名单产物 |
| 只读分析参考 HTML 的通用布局知识 |
| 从 HTML、截图或 blueprint 编译并 QA 模板知识 |
| 查看已批准的模板知识和 QA 证据 |
plan_slide、generate_slide、get_run、generate_image 和原子模板工具用于兼容、诊断或受控开发。部分高级工具可接收物理路径、远程地址、输出目录或调用方 provider 配置，属于 trusted-local surface，不应直接开放给不可信 Agent。完整边界见安全设计。
模板学习提取的是网格、层级、色板、间距、组件和视觉比例，不复制参考页正文、Logo、水印、品牌或整页截图。
对内联 HTML 先调用 inspect_template。
调用 create_template_from_reference，每次只传 HTML、受限图片 data URL 或合规 blueprint 中的一种。
截图在没有视觉分析器时会返回 needs_analysis；Agent 按提示生成通用 blueprint 后再次提交。
只有通过模板目录校验和真实 Chromium QA 的结果才成为 approved 知识。
使用 list_template_knowledge 查看记录；经人工晋升并重启 Server 后，才参与生产模板选择。
完整步骤见从优秀页面沉淀模板知识。
复制 .env.example 并按需设置。高层 deck workflow 在没有任何 Provider 时也能完成确定性规划、HTML 生成和 Chromium QA。
PPT_LLM_BASE_URL / API_KEY / MODEL：可选 OpenAI-compatible 文本模型，主要服务低层规划路径；
PPT_IMAGE_BASE_URL / API_KEY / MODEL：可选低层图片工具；
PPT_REVIEW_BASE_URL / API_KEY / MODEL：可选多模态复核；
PPT_OUTPUT_ROOT：运行目录，默认 output/runs；
PPT_MAX_CONCURRENCY、PPT_REQUEST_TIMEOUT_MS、PPT_MAX_IMAGE_BYTES：资源限制。
推荐高层工具不接受调用方 API Key，Provider 密钥只从 Server 环境读取。若选中的模板需要图片而 Agent 又无法生成，流程会停在 needs_assets，不会伪造图片或静默换模板。
.
├── src/ # MCP 工具、workflow、模板编译、渲染和 QA
├── templates/
│ └── green-infographic/ # A4 横向模板、能力档案、样式与图标
├── docs/
│ ├── user-guide.md # 非技术用户完整操作指南
│ ├── architecture.md # 生产架构、数据流和扩展边界
│ └── superpowers/ # 设计、实施计划与验证记录
├── .mcp.json # MCP stdio 配置
├── .env.example # 可选 Provider 与运行限制
├── package.json
└── tsconfig.jsondist/、output/ 和 node_modules/ 都是可再生成目录，不属于源码交付。
npm test
npm run check开发时可运行 npm run dev。新增或晋升模板必须提供唯一 slug、自包含 A4 横向 HTML 和严格能力 profile，并通过目录校验、自动测试、生产构建和真实 Chromium QA。
MIT
组装最终的可交付 HTML 页面：移除 XML 注释、检查残留占位符、可选内联 CSS、可选压缩输出、写入文件。编排层在所有填充/渲染步骤完成后调用此工具输出最终页面。
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | 待组装的 HTML | |
| config | Yes | 组装选项 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. Lists actions but omits failure modes (e.g., what happens if placeholders remain), permissions needed, or side effects. For a mutation tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no filler. 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?
Lacks output schema and does not describe return value or error handling. Given complexity of config and no annotations, more detail would be needed for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds context about the overall assembly process but does not enhance parameter understanding beyond schema. No contradictions.
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 it assembles final HTML page, lists specific actions (remove XML comments, check placeholders, inline CSS, minify, write file), and distinguishes from siblings as the final output step.
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?
Explicitly states it should be called after all fill/render steps, providing clear usage context. Could improve by specifying when not to use or alternative tools, but sibling context helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用实际内容填充模板中的 XML 占位符。支持两种模式：（1）direct 直接替换文本；（2）expand 提供要点，调 LLM API 扩写为正式段落。这是编排层调度文生文 LLM 的核心工具。
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | 模板 HTML 字符串 | |
| content | Yes | 填充内容。direct 为直接文本替换（{tag: text}），expand 为要点扩写（调 LLM） | |
| llmConfig | No | LLM API 配置，仅 expand 模式需要 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the two modes and that expand uses LLM API, but lacks detail on side effects, error handling, rate limits, or state modification. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences covering purpose, modes, and context. No redundancy or irrelevant details; each sentence 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 nested objects, two modes, no output schema, and no annotations, the description explains modes and that expand requires LLM config but omits output format, error conditions, and prerequisites. Adequate but incomplete for a tool with this complexity.
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 100% coverage with parameter descriptions. Description adds a concise summary of modes but does not significantly extend meaning beyond the schema. Baseline of 3 is appropriate.
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 fills XML placeholders in templates, explicitly names two modes (direct and expand), and positions itself as the core orchestration tool for LLM text generation, differentiating it from siblings like 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?
Mentions two modes and that expand calls LLM API, providing some context for use. However, it does not explicitly state when to choose direct vs expand, nor when to avoid this tool (e.g., for image generation). Guidance is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用 DALL-E 文生图 API 生成配图。可传入 HTML（自动提取 提示词），或直接传入 prompt 生成单张图片。生成后自动替换 HTML 中的 标签为 。
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | 含 <figures> 占位符的 HTML（可选，如果直接传 prompt 则忽略） | |
| prompt | No | 直接传入图片生成提示词（不依赖 HTML 中的 <figures>） | |
| outputDir | Yes | 图片输出目录（绝对路径） | |
| imageConfig | Yes | DALL-E API 配置 | |
| outputUrlPrefix | No | 图片引用 URL 前缀，默认 "./assets/images/" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the automatic replacement of <figures> with <img> in HTML. However, it omits details like rate limits, cost implications, error handling, and the fact that images are saved to the output directory (implied by required param but not stated). This leaves some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences with no redundancy. It immediately states the core purpose, then explains the two modes and side effect. Every part 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?
The description explains the core functionality but lacks some completeness. It does not specify what the tool returns (e.g., updated HTML or success message) despite no output schema. It also does not mention the file saving behavior or error conditions. For a tool with 5 params and a nested object, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds workflow context (HTML extraction vs direct prompt) that is not in individual parameter descriptions, but it does not provide deeper constraints or examples. Value added is moderate given the schema already documents each parameter.
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 calls DALL-E API to generate images, with two distinct modes (HTML with <figures> extraction or direct prompt). It is specific about the verb (generate), resource (images), and differentiates from sibling tools by focusing on image generation rather than template processing.
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 two usage modes (HTML-based or direct prompt), providing clear context. However, it does not explicitly state when to choose one over the other, nor does it mention prerequisites like API key availability. Still, it offers sufficient guidance for an AI agent given the sibling tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出 templates/ 目录下所有可用的 HTML 模板，返回模板元数据（名称、适用场景、格式、组件等）。编排层可据此选择最合适的模板。
| Name | Required | Description | Default |
|---|---|---|---|
| templatesDir | No | 模板目录的绝对路径，默认为项目根目录下的 templates/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It describes a read operation (listing) with no mention of side effects, permissions, or rate limits. While adequate, it lacks explicit read-only confirmation.
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 with a follow-up note, front-loading the core action. No wasted words; every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, the description is largely complete. It mentions the output (metadata fields) but could further specify the exact structure or field types, especially given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (templatesDir) with 100% coverage, so the description adds no additional meaning. Baseline 3 is appropriate as the schema suffices.
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 action (list templates) and the resource (templates/ directory). It specifies the return data (metadata including name, applicable scenario, format, components) and distinguishes from siblings by focusing on discovery rather than loading or processing templates.
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 for orchestration layer template selection but does not explicitly state when not to use it or compare with alternatives like load_template. Guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
加载指定模板的完整 HTML 内容，解析并返回所有占位符（XML 标签）和图标引用清单。编排层根据返回的占位符列表准备内容数据。
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 模板的唯一标识（slug），如 "green-infographic-bid-a4-landscape" | |
| templatesDir | No | 模板目录的绝对路径，默认为项目 templates/ |
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 that it loads full HTML, returns placeholders and icon references, and is used by the orchestration layer. However, it does not mention error handling, prerequisites, or potential side effects. Still, it provides adequate transparency for a read-only loading 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 two short sentences, front-loaded with the core action, and every sentence adds value. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description explains the return values (placeholders and icon references) and provides context about the orchestration layer's use. It is mostly complete, though could mention the return structure (e.g., list format).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters. The tool description does not add new meaning beyond what the schema already provides for parameters, meeting the baseline of 3.
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 that the tool loads the complete HTML content of a specified template, parses placeholders and icon references, and returns them. It distinguishes from siblings like list_templates and fill_placeholders by specifying its specific role in the orchestration pipeline.
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 what the tool does and its place in the orchestration, but does not provide explicit guidance on when to use it versus alternatives like list_templates or parse_source_content. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将原始 Markdown/正文解析为模板填充所需的结构化 content 对象。支持 direct（纯正则）和 llm（调 LLM 提取）两种模式。编排层调用此工具后，直接将返回的 content 传给 fill_placeholders。同时返回图片提示词和推荐的模板 slug。
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 解析模式：direct=纯正则解析，llm=调 LLM 提取（需 llmConfig） | |
| llmConfig | No | LLM API 配置，仅 llm 模式需要 | |
| sourceText | Yes | 原始 Markdown 或纯文本正文内容 | |
| templateSlug | No | 强制指定模板 slug；留空则自动推荐最匹配的模板 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述承担全部责任。解释了两种模式及llm模式配置要求，并列出输出项，但未说明错误处理、输入限制或副作用，行为透明度中等。
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?
两句话简洁明了，信息密度适中，但第二句话罗列输出项稍显密集，结构尚可。
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?
在无输出schema的情况下，说明了返回的结构化对象、图片提示词和推荐模板slug，并指明在编排中的角色（传递给fill_placeholders），对4参数工具较完整，但缺少错误处理描述。
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覆盖率100%，描述基本复述schema内容，对参数含义无显著补充（如sourceText仅重述‘原始Markdown或纯文本’），但额外说明templateSlug留空则自动推荐，略有增值。
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?
明确说明工具用于将原始Markdown/正文解析为结构化content对象，支持两种模式，并指出与fill_placeholders的衔接以及返回图片提示词和推荐模板slug，与兄弟工具区分度高。
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?
说明了调用时机（在fill_placeholders之前）和返回内容如何传递，但未明确说明不适合使用的情况或替代方案，仅提供基本使用导向。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将模板中的 描述 替换为实际的 。纯本地操作，不调 API。
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | 含 <icon> 标签的 HTML | |
| iconBasePath | Yes | 图标 SVG 目录的绝对路径 | |
| iconsRelativePath | No | 生成的 <img> 中 src 的相对路径前缀，默认 "./assets/icons/" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states 'pure local operation, no API calls,' which is helpful, but it omits details like error handling for missing icons or whether the original HTML is mutated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no superfluous words. It front-loads the core action and adds a behavioral note efficiently.
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 simplicity and complete parameter schema, the description covers the essential transformation and safety aspect. However, it lacks explanation of the return value format, which would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions, so the tool description does not need to add parameter details. It provides context about the transformation but does not enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: replacing <icon> tags with <img> tags using a specific verb and resource. It distinguishes from sibling tools like list_templates and generate_image by focusing on a localized icon substitution step.
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 mentions it is a local operation with no API calls, implying safe usage, but does not provide explicit guidance on when to use it versus alternatives like fill_placeholders. No exclusions or context for complex scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
验证生成的页面：检查是否残留 XML 占位符、 标签是否已渲染、图片引用是否有效、HTML 是否合法。编排层在交付前调用此工具做最终质量检查。
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | 待验证的 HTML | |
| checks | Yes | 要执行的检查项 | |
| htmlFilePath | No | HTML 文件路径（用于验证图片引用是否存在） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the checks performed but does not mention return format, error handling, or if the tool has side effects. As a validation tool, it is likely read-only, 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?
Two concise sentences: first lists all checks, second states invocation context. No redundancy, front-loaded with specific actions.
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?
Describes inputs and usage context well, but lacks information about output (e.g., does it return a boolean, error messages, or details?) and lacks behavioral transparency (no annotations). For a validation tool, return value is important for agents to act on results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds meaning to the 'checks' parameter by mapping each enum value to a natural language check (e.g., 'no-xml-tags' corresponds to '检查是否残留 XML 占位符'). This goes beyond the schema which only lists enum literals.
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 validates generated pages by checking for XML placeholders, icon rendering, image references, and HTML validity. It distinguishes from sibling tools (e.g., assemble_page) by being the final quality check before delivery.
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 specifies 'before delivery' as the usage context. It implicitly excludes earlier stages by stating it's a final check, but does not explicitly list when not to use or alternatives.
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.
v1.0.0assemble_pagefill_placeholdersgenerate_imagelist_templatesload_templateparse_source_contentrender_iconsvalidate_pageEach tool has a distinct role in the PPT generation pipeline: template discovery, loading, placeholder filling, image generation, icon rendering, page assembly, validation, and source parsing. No overlaps exist.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_templates, fill_placeholders). The convention is uniform and predictable.
With 8 tools covering the entire workflow from source parsing to final validation, the count is well-scoped for a specialized PPT generation server. No tool feels redundant or missing.
The tool set provides a complete pipeline: parse source content → list/load template → fill placeholders → generate images → render icons → assemble page → validate. All necessary steps for generating a presentation are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate, edit, merge, translate and PDF-convert PowerPoint (.pptx) over MCP. 8 tools.
8 MCP servers, 104+ tools: memory, social, PDF, email, images, calendar, scheduler, files.
Presentations.AI MCP server — create designed slide decks from a topic, text, or document.
HTML-to-PDF MCP server — render pixel-faithful PDFs from HTML.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SUSTechWLA/ppt-generator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
