Teaching AI assistants to write Phoenix UI

Here's a problem that didn't exist two years ago. You ask an AI assistant to build a settings page in your Phoenix app, and it writes three hundred lines of raw Tailwind divs. It works, sort of, but you already have a <.modal>, a <.table> and a <.button> that do all of that, styled and tested. The agent just didn't know they existed.

The agent isn't wrong to guess. It has no idea what's installed in your project, so it reinvents everything from scratch.

We fixed that with an MCP server. MCP, the Model Context Protocol, is the standard way to hand an AI assistant a set of tools it can call. Ours exposes Petal Components directly. The agent can list every component, pull the full schema for any one of them (its attributes, slots, defaults and allowed values), and get the canonical install steps.

Now when you tell Claude Code or Cursor to build that settings page, it asks the server what's available, sees the real components, and writes <.modal> instead of a div-soup approximation. The output reads like it was written by someone who actually knows the library.

Installing it is one line:

claude mcp add petal --transport http https://mcp.petal.build/mcp

The schemas come straight from the published package on Hex, so the tools always describe the version that really exists, not a stale snapshot baked in months ago. When we ship new components, the server picks them up.

This is the bet. AI assistants are quietly becoming the way developers discover and install tools. A library an agent can see and use correctly has a huge advantage over one it has to guess at. So we're making Petal the easy thing to reach for. The less div soup in the world, the better off we all are.