Exposes every component from petal_components (the Shadcn-style Phoenix LiveView library) as structured schemas so AI assistants stop inventing Tailwind soup and start writing idiomatic pc_* markup. Provides two tools: list_components returns the full catalog with summaries, get_component returns complete schemas with attrs, slots, defaults, allowed values, and HEEx examples. The schemas are extracted directly from Phoenix.Component metadata via a Mix task, so they stay in sync with each Hex release. Useful if you're building LiveView UIs with an AI assistant and want it to reach for library components instead of reinventing buttons and modals from scratch every time.
An MCP server that exposes petal_components — the Shadcn-style component library for Phoenix LiveView — to AI coding assistants (Claude Code, Cursor, Windsurf, etc).
Without this, AI agents writing HEEx invent raw Tailwind soup and never reach for pc_* components. With it, the AI gets the full schema for every component on demand — attrs, slots, defaults, allowed values, usage examples — and writes idiomatic petal_components markup by default.
claude mcp add petal --transport http https://mcp.petal.build
Then in any Phoenix project, ask the AI to build something. It'll call list_components and get_component to ground its output in real petal_components schemas.
list_components — every component in the library with a one-line summaryget_component — full schema (attrs, slots, defaults, values, docs) + HEEx usage exampleComing soon: search_components (natural-language match) and generate_pattern (composed blocks like form-in-card, modal-with-form, dashboard skeletons).
The MCP server is a thin TypeScript service that bundles a JSON snapshot of every component in petal_components. The JSON is generated by a Mix task that introspects Phoenix.Component.__components__/0 on every loaded PetalComponents.* module — so the schemas are always in sync with the actual library, no manual duplication.
petal_components (Hex) petal-components-mcp (this repo)
│ │
│ mix run extract_schemas.exs │
│─────────────────────────────────────► src/schemas.json
│
│ tsc
▼
dist/server.js ◄── deployed to Fly
# Regenerate schemas from the latest petal_components on Hex
npm run extract # cd scripts/extract && mix deps.get && mix run extract_schemas.exs
# Build and serve
npm install
npm run build
PORT=8765 npm start
# Health check
curl http://localhost:8765/healthz
The extraction is self-contained — scripts/extract/ is a tiny Mix project that pulls petal_components from Hex, introspects every Phoenix.Component.__components__/0, and writes src/schemas.json. No need for a local petal_components clone.
To use a local server with Claude Code:
claude mcp add petal-local --transport http http://localhost:8765/mcp
The MCP server is hosted at mcp.petal.build on Fly.io as a standalone app.
# 1. Create the app (one-time, requires Fly auth)
fly apps create petal-components-mcp
# 2. Deploy
fly deploy --remote-only
# 3. Add the custom domain
fly certs add mcp.petal.build
After step 3, Fly prints the DNS records you need. Add a CNAME at the petal.build DNS provider:
mcp.petal.build CNAME petal-components-mcp.fly.dev
Then fly certs check mcp.petal.build will go green once propagation hits.
fly deploy --remote-only
# 1. Regenerate schemas from the latest petal_components on Hex
npm run extract
# 2. Eyeball the diff (catches surprises before they ship to AI agents worldwide)
git diff src/schemas.json | head -50
# 3. Commit and deploy
git add src/schemas.json
git commit -m "chore: sync schemas with petal_components vX.Y.Z"
git push
fly deploy --remote-only
The /healthz endpoint reports the bundled version, so you can confirm a deploy went out:
curl https://mcp.petal.build/healthz
# {"ok":true,"petal_components_version":"3.2.0","components":79,...}
This is the artifact for bet 002 — testing whether AI coding assistants become the dominant install/discovery channel for Phoenix UI tooling. See the bet for hypothesis, metrics, and kill criteria.
MIT.