Run Chromatic with cloud agents Beta
In a software factory, a cloud-based agent picks up a ticket, writes the code, opens a pull request, and reads the Chromatic build to find out if the UI is right. It fixes what it can and leaves visual changes for a person to review.

Why software factories need Chromatic
A software factory only saves time if its pull requests don’t need redoing. For UI, that depends on whether the agent can see what it built. That’s why most agents now screenshot the UI in a browser. But a screenshot only shows the current state of the UI. It can’t tell you what changed or if there are unintended consequences elsewhere.
Chromatic snapshots every story in parallel, compares each one against its baseline, and runs interaction and accessibility checks. With our MCP, that context is available to the agent, so it knows exactly what changed, what broke and how to fix it.
Set up
1. Connect your agent to the Chromatic MCP server
Add https://mcp.chromatic.com/mcp to your cloud agent’s MCP settings (Claude Desktop and claude.ai, or add the MCP server by hand) and authenticate. After that, every session the agent runs can use the Chromatic tools without asking again.
The agent acts as the person who logged in. It sees the projects that person can see, and anything it changes in Chromatic counts as that person’s action. If that person leaves your Chromatic account, the agent loses access with them.
2. Give cloud agents the skills
To give every cloud agent the skills, we recommend installing them in your repository with the skills CLI:
npx skills add chromaui/chromatic-plugins
Leave out --global so the skills go in the project, not your home folder. Commit them. Any agent that runs in the repository picks them up.
3. Tell your agent to respond to Chromatic
Add these instructions to AGENTS.md or your agent platform’s equivalent:
After you push, check the latest Chromatic build for this branch.
- Fix broken stories and new accessibility violations, push, and check the next build.
- Repeat until the build has no broken stories or new violations.
- List the remaining visual changes in the pull request for a person to review. Don't accept them.
- Mark the pull request ready only once the Chromatic build has finished. A passing CI job doesn't mean the UI passed.
- To test a UI change, add or update a story. Don't write a separate page-level test for the same thing.
See Mandatory PR checks for what each build status means.
4. Review the changes that need a decision
The agent works through Chromatic’s findings on its own. It fixes broken stories and accessibility violations, then uses the skills from step 2 to check whether each visual change matches the code on its branch.
You only step in when a change needs your call: is it an intended update or a regression? You review those few changes, not every snapshot.

Next steps
- Set up the Chromatic MCP server: See the tools it offers, how to add it to your agent, and how access works.
- See what each skill does: Learn what the skills check and when your agent uses them.
- Build your own workflows with the API: Query builds, tests, and accessibility results from your own scripts, bots, and dashboards.