[Feature]: MCP Server Mode (Headless + Tool Exposure)

[258044aamm-Dev]

Enable Open CoDesign to run as a Model Context Protocol (MCP) server, so it can be used by external MCP clients.

---

🎯 Motivation
It would be highly valuable to support server mode, enabling:

• Integration with external MCP clients (Claude, custom agents)
• Automated design workflows
• Headless usage in pipelines

---

🧠 Proposed Solution

Add a CLI flag to run as MCP server:

open-codesign --mcp-server

Expose tools like:

• generate_design
• update_component
• export_html
• export_react

---

💡 Use Cases

• AI agents generating UI automatically
• CI/CD pipelines generating pages
• Integration with MCP ecosystem

---

🙋 Willing to contribute

Happy to help design or test this feature.

Proposed solution

🧠 Proposed Solution
Add a CLI flag to run as MCP server:
open-codesign --mcp-server
Expose tools like:
generate_design
update_component
export_html
export_react
🔌 Example MCP Config
{
"mcpServers": {
"open-codesign": {
"command": "uvx",
"args": [Here Argument]
}
}
}

Alternatives considered

No response

Scope

Provider / model

Hard-constraints check

• I have read the hard constraints in AGENTS.md or CLAUDE.md, and this proposal does not conflict with any of them.

[github-actions]

Thank you for the detailed feature request! Adding an MCP server mode is an interesting idea that aligns with the v0.2 direction of exposing Open CoDesign's agentic tools programmatically.

What we've verified from the codebase:

• The current architecture uses pi-agent-core and pi-ai as the agent runtime (packages/core depends on @mariozechner/pi-agent-core and @mariozechner/pi-ai). Per CLAUDE.md / AGENTS.md hard constraint feat(exporters): real PDF/PPTX/ZIP via system Chrome + pptxgenjs + zip-lib (lazy-loaded) #7, we should reuse pi primitives where possible. This means any MCP server should ideally delegate tool execution to pi's existing built-in tools and Open CoDesign's design tools (ask, scaffold, preview, gen_image, tweaks, todos, done) rather than duplicating logic.
• The project doesn't currently have a headless or CLI server entry point – apps/desktop is an Electron app, and there's no existing --mcp-server flag. This would be a new addition, likely as a separate entry point or package.
• The proposed tools (generate_design, update_component, export_html, export_react) map roughly to existing design tools, but the exact mapping would need design.

A few questions to help scope the implementation:

1. Transport: Would you expect stdio (as implied by the uvx config example) or HTTP/SSE? Both are valid MCP transports.
2. Tool set: Should the MCP server expose the full set of design tools (including ask, scaffold, preview, gen_image, tweaks, todos, done) or a curated subset focused on generation/export?
3. Session model: MCP clients typically expect stateless or lightweight session management. Should each MCP invocation create a new design session (pi session) or should the server maintain a persistent session?
4. Packaging: Should this live as a new CLI entry point in apps/desktop (enabled via flag) or as a separate package (e.g., packages/mcp-server) that can be installed independently?

We're happy to review a concrete design or prototype if you'd like to contribute further. Thanks again for the thoughtful proposal!

---

Open-CoDesign Bot