Add standalone OpenGenerativeUI MCP Server

[GeneralJerel]

Summary

Introduces a fully standalone, independently deployable MCP server that exposes OpenGenerativeUI's design system, skills, and renderer capabilities.

Key Features

• Standalone Package — open-generative-ui-mcp can be deployed independently
• MCP Tools — assemble_document wraps HTML with design system CSS and bridge JS
• MCP Resources — skills://list and skills://{name} for browsing skill instructions
• MCP Prompts — Pre-composed prompts: create_widget, create_svg_diagram, create_visualization
• Production Ready — Docker support, configuration options, comprehensive documentation
• Zero Demo Impact — Main app remains untouched; fully isolated

Files Added

apps/mcp/ — Complete MCP server package

• src/ — Server implementation (index.ts, server.ts, skills.ts, renderer.ts)
• skills/ — Own copies of skill instruction files
• README.md — Comprehensive deployment and API documentation
• Dockerfile — Multi-stage production container
• Configuration files (.env.example, tsconfig.json, etc.)

Usage

Development

cd apps/mcp && pnpm dev
# → MCP server running on http://localhost:3100/mcp

Production (Docker)

docker build -t open-generative-ui-mcp .
docker run -p 3100:3100 open-generative-ui-mcp

Connect from Claude Code

Add to .mcp.json:

{
  "openGenerativeUI": {
    "url": "http://localhost:3100/mcp"
  }
}

Status

• Server running and responding on http://localhost:3100/mcp
• Health check passing
• Ready for review and integration testing

[GeneralJerel]

Overall the implementation is clean and well-structured — nice separation of concerns across the 4 source files. A few issues to address before merging, noted inline.

[GeneralJerel]

Security: Path traversal vulnerability

name comes from MCP resource URI parameters and is passed directly into resolve(). A crafted name like ../../etc/passwd (with .txt appended) could read files outside the skills directory.

Suggest validating the resolved path stays within SKILLS_DIR:

export function loadSkill(name: string): string {
  const resolved = resolve(SKILLS_DIR, `${name}.txt`);
  if (!resolved.startsWith(resolve(SKILLS_DIR) + "/")) {
    throw new Error(`Invalid skill name: ${name}`);
  }
  return readFileSync(resolved, "utf-8");
}

[GeneralJerel]

Bug: --prod flag breaks the build step

--prod skips devDependencies, but tsc (used on line 23 via pnpm build) is listed under devDependencies. This Docker build will fail at the RUN pnpm build step.

Should be:

RUN pnpm install --frozen-lockfile

Or split into two stages — full install for build, then prune to prod for the runtime image.

[GeneralJerel]

Potential issue: Single shared transport instance

The WebStandardStreamableHTTPServerTransport is instantiated once and shared across all HTTP requests. MCP's streamable HTTP transport is typically per-session — if two clients connect simultaneously, they may experience session conflicts.

Worth verifying whether the SDK handles concurrent sessions internally, or if you need to create a transport per request (or per session ID).

[GeneralJerel]

Conflict with Dockerfile: The .gitignore excludes pnpm-lock.yaml, but the Dockerfile (line 11) copies it for --frozen-lockfile install. The Docker build will fail unless the lockfile exists at build time.

Either remove this line (and commit the lockfile) or update the Dockerfile to not rely on --frozen-lockfile.

[GeneralJerel]

The comment says this is forked from widget-renderer.tsx — that's ~290 lines of duplicated CSS. If the design system evolves, both files need manual sync. Consider extracting the shared CSS to a common file or adding a more visible warning about keeping them in sync.

[GeneralJerel]

Review Notes

Overall this is clean and well-structured — good separation of concerns, path traversal protection, per-session transports, and dual transport support. Build passes. A few things to consider:

Issues

1. Dockerfile won't build from apps/mcp/ context — Dockerfile:5 copies pnpm-lock.yaml, but the lockfile lives at the repo root (this is a workspace package). Running docker build -t open-generative-ui-mcp . from apps/mcp/ will fail. Either the build context needs to be the repo root, or the install strategy needs to change.

2. Session map has no TTL or size limit — index.ts:11 sessions Map grows with each new connection and only cleans up on explicit transport close. No eviction for abandoned sessions. Fine for dev, but could leak memory under sustained use.

3. LOG_LEVEL in .env.example is never read — Declared in the example env but not referenced anywhere in the code. Will confuse users trying to configure logging.

Minor observations

• SKILLS_DIR from env resolves relative to CWD, but the code default resolves relative to __dirname. These behave differently — worth a note in the README or .env.example.
• unsafe-eval in the CSP (renderer.ts:327) is a deliberate tradeoff for generated widgets, but worth calling out in docs.
• The forked CSS in renderer.ts (~350 lines from widget-renderer.tsx) has the sync warning comment which is good — extracting to a shared location would prevent drift long-term.

Verdict

The Dockerfile issue is the only thing that blocks a documented workflow. The rest are non-blocking follow-ups. 👍