https://api.slideforge.dev/mcp ↗
Generate reliable, editable PowerPoint from agent workflows — real .pptx files, not web previews. A structured slide intent (or a plain brief) renders deterministically in ~50ms–1.5s. Built for agents: REST + MCP at full parity, one price, no LLM in the render path. - **Structured intent or brief**: Send a typed slide intent (a form + fields) or just a natural-language brief — both render to deterministic, editable PowerPoint. - **Fast, deterministic render**: Sub-second to ~1.5s per slide, predictable layout, no model in the hot path. - **150+ slide patterns**: KPIs, comparisons, roadmaps, risk registers, OKR trackers, decision tables, timelines, funnels, quadrants, and more — picked automatically from your brief. - **Decks in parallel**: Multi-slide decks fan out as parallel jobs with a contact sheet and partial-failure isolation. - **Code mode**: Caller-supplied python-pptx runs in a sandbox — the escape hatch for layouts outside the catalog. - **Translation**: Localize an existing
SlideForge is a remote MCP server published at api.slideforge.dev. It has been probed 6 times since 9/10/2026. It answered in 6 of them (100.0%), a near-uninterrupted record. Median response time is 587 ms, a delay an agent will notice. It offers a narrow, focused set of 7 tools. On the protocol side it still runs 2025-11-25 and has not moved to the newer spec.
Can an LLM agent pick the right tool here — names, descriptions and parameter clarity are assessed.
browse_catalog — Parameter 'family' and 'q' lack type and requirement clarity.plan_slide — Truncated description omits critical details about 'next_action' handling.create_deck — Ambiguous 'slides' parameter schema for parallel slide generation.translate_deck — No mention of error cases for unsupported language scripts.upload_asset — Asset type constraints (e.g., 'max 5MB') are not explicitly called out.Risk: medium
tools/list structure, inputSchema validity, and a functional smoke test — the components of the 0-100 score.
Derived by comparing consecutive probes — changes in era, protocol version, build and reachability.
Add this badge to your README — it updates automatically as measurements change.
[](https://mcpmetrics.io/servers/smartdatabrokers-slideforge)<a href="https://mcpmetrics.io/servers/smartdatabrokers-slideforge"><img src="https://mcpmetrics.io/badge/smartdatabrokers/slideforge/era.svg" alt="mcpmetrics"></a>You are seeing the last 7 days. Sign up for the full history. Which check failed and why is in the dashboard.
Sign up free to see| Run | Era | Modern | ms | Legacy | ms | Versions |
|---|---|---|---|---|---|---|
| 2026-09-11 16:59:56 | Legacy | 401 | 590 | 200 | 587 | 2025-03-26 |
| 2026-09-11 15:07:20 | Legacy | 401 | 193 | 200 | 185 | 2025-03-26 |
| 2026-09-11 13:13:33 | Legacy | 401 | 611 | 200 | 612 | 2025-03-26 |
| 2026-09-11 11:20:19 | Legacy | 401 | 357 | 200 | 354 | 2025-03-26 |
| 2026-09-11 09:28:19 | Legacy | 401 | 651 | 200 | 645 | 2025-03-26 |
| 2026-09-10 21:16:35 | Auth-gated | 401 | 401 | 401 | 401 | — |
Each block is one measurement round. Green: working response. Amber: responded but the server was returning errors (5xx). Red: no response at all.
Each cell is one probe run. Faded cells are incomplete probes — one leg did not answer, so the era is inconclusive.
The two probe legs separately: modern server/discover and legacy initialize.