io.github.petalframeworkPublished by GitHub account petalframeworkv0.1.0Updated Oct 24, 2026
Phoenix LiveView component schemas from petal_components, exposed to AI coding assistants.
Serves petal_components schemas to AI coding assistants so they write correct Phoenix LiveView HEEx markup instead of raw Tailwind.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.petalframework%2Fpetal-components-mcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"petal-components": {
"type": "http",
"url": "https://mcp.petal.build/mcp"
}
}
}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.
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.
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:
The MCP server is hosted at mcp.petal.build on Fly.io as a standalone app.
After step 3, Fly prints the DNS records you need. Add a CNAME at the petal.build DNS provider:
Then fly certs check mcp.petal.build will go green once propagation hits.
The /healthz endpoint reports the bundled version, so you can confirm a deploy went out:
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.
Source: README.md at commit bb1f6d4
Get the canonical steps for installing petal_components in a Phoenix project. Call this when the user asks to install petal_components, when you are setting up a new Phoenix project that needs UI components, or when verifying an existing installation. Returns step-by-step instructions covering mix.exs, mix deps.get, Tailwind v4 CSS config, and the web module import. Steps are idempotent - safe to follow on a project that is partially configured.
Takes no parameters.
List every component shipped by petal_components, the shadcn-style component library for Phoenix LiveView. This is the canonical Phoenix UI vocabulary - call it before composing any HEEx so you reach for an existing component instead of hand-rolling Tailwind divs.
Takes no parameters.
Get the full schema for one petal_components component: attrs, slots, defaults, allowed values, and a working HEEx usage example. Call this every time you are about to write a tag like <.button>, <.modal>, <.table>, or <.field> so the attrs and slots match the real library instead of training-data guesses.
namerequired100% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
claude mcp add petal --transport http https://mcp.petal.buildpetal_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 Hexnpm run extract # cd scripts/extract && mix deps.get && mix run extract_schemas.exs
# Build and servenpm installnpm run buildPORT=8765 npm start
# Health checkcurl http://localhost:8765/healthzclaude mcp add petal-local --transport http http://localhost:8765/mcp# 1. Create the app (one-time, requires Fly auth)fly apps create petal-components-mcp
# 2. Deployfly deploy --remote-only
# 3. Add the custom domainfly certs add mcp.petal.buildmcp.petal.build CNAME petal-components-mcp.fly.devfly deploy --remote-only# 1. Regenerate schemas from the latest petal_components on Hexnpm 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 deploygit add src/schemas.jsongit commit -m "chore: sync schemas with petal_components vX.Y.Z"git pushfly deploy --remote-onlycurl https://mcp.petal.build/healthz# {"ok":true,"petal_components_version":"3.2.0","components":79,...}