Convert PowerPoint MCP server into a CLI + pi skill
Session from clean-slides-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Reduce context overhead of a 37-tool PowerPoint MCP server by converting it into a CLI (via mcporter) plus an on-demand pi skill, then package and publish it.
- +0Prompt · +0We have the powerpoint mcp, but it's context heavy. Check mcporter and skill-creator, then decide whether to convert it to a CLI and/or skill.
- +0mAgent did · +0mExplored the powerpoint MCP (37 tools, ~8400 tokens), cloned mcporter, generated a bundled CLI with mcporter generate-cli, tested it with bun, and laid out a comparison table of MCP vs CLI+skill vs CLI-only approaches.
- +21mPrompt · +21mUse it with bun, agree with the plan. Add a human-readable README (wrapper of original repo, install instructions) and MIT license, create the wrapper in ~/.pi/agent/, then gh repo create as powerpoint-cli.
- +22mAgent did · +22mCreated the skills/powerpoint directory with the bundled CLI, SKILL.md, README, LICENSE, removed the powerpoint MCP entry from mcp.json, git-initialized the repo, and ran a smoke test.
- +23mFail · +23mSmoke test failed: each CLI invocation spawned a fresh MCP server process, so state (the created presentation) didn't persist between commands.
- +23mAgent did · +23mWrote a batch runner (powerpoint-batch.ts) to keep one server session alive across commands, dug into the upstream Python source, found create_presentation_wrapper/open_presentation_wrapper were dead code never applied, and confirmed a workaround: explicitly passing presentation_id to every call.
- +27mAgent did · +27mUpdated the batch runner to auto-inject presentation_id, rewrote SKILL.md and README around the batch-first workflow, ran a full integration test, committed, and published the repo via gh repo create as tmustier/powerpoint-cli.
- +34mIntervention · +34mDeveloper asked 'is this a known issue? are we sure?' before accepting the root-cause claim about the upstream bug.Why: I wanted to verify the bug claim rather than let it ship as an assumption in the docs.
- +34mAgent did · +34mConfirmed via GitHub search that it's a known upstream issue (#19), read the issue comments (which added a second cause: stdio transport can respawn processes per call), and added a concise 'Known issues' section to the README only, keeping SKILL.md clean per developer's instruction.
- Break · 51m away, not counted
- +46mAgent did · +46mSet up package.json following pi-package conventions, published to npm as pi-powerpoint, tagged a v0.1.0 GitHub release with notes, and iteratively cleaned up docs so all install/implementation details live in the README while SKILL.md just points to it.
- +55mOutcome · +55mShipped powerpoint-cli/skill as github.com/tmustier/powerpoint-cli, tagged v0.1.0, and published to npm as pi-powerpoint; SKILL.md trimmed to agent-relevant content only.
I'd start the next prompt by asking explicitly whether the underlying MCP server has known state-persistence issues, since that turned out to be the crux of the whole build. Pushing back with 'is this a known issue? are we sure?' was the correction that mattered — it took the agent from a confident but unverified root-cause claim to an actually confirmed upstream bug report, which changed how we documented and workaround-proofed the batch runner. Keeping SKILL.md lean and pushing implementation detail into the README was also worth insisting on explicitly.