You can test a local app from Claude Code by connecting Swarm's MCP server, starting the dev server, and asking Claude to run a goal against localhost. The setup command is npx @useswarm/mcp@latest setup. Swarm opens a temporary tunnel, sends AI personas through the flow, and returns structured issues to the editor so it can fix and rerun the test. MCP access is included on Swarm's Startup plan; the free web tier does not include the editor integration.
What does MCP add to Claude Code?
The Model Context Protocol lets Claude Code discover and call external tools through a standard interface. Anthropic's Claude Code MCP documentation supports local stdio servers and remote HTTP servers with user, project, or local configuration scopes.
For UX testing, MCP closes a missing part of the coding loop. Claude can already edit files and run tests. Swarm gives it tools that open the built interface, attempt a real goal, and return what went wrong from a user's point of view.
How do you install the Swarm MCP server?
Run this from a terminal:
npx @useswarm/mcp@latest setup
The command detects Claude Code and Codex CLI, registers the local stdio server, and opens a browser login. Credentials are stored in ~/.useswarm/config.json. Restart the editor after setup so it reloads the MCP configuration.
To scope setup to one client, use --client claude or --client codex. Cursor and other MCP clients can run the same package over stdio with a manual configuration from the Swarm MCP page.
How do you verify the connection?
In Claude Code, run /mcp and confirm that useswarm is connected. Then ask Claude to list the available Swarm tools. A healthy installation exposes dev_list_swarms, dev_test, dev_watch, dev_status, and dev_close.
If the server reports that no API key is available, run npx @useswarm/mcp@latest login in a normal terminal. Authentication happens during setup or login, not inside an unattended MCP tool call.
What prompt starts a useful test?
Give Claude one URL, one outcome, and one audience:
Test http://localhost:3000. Goal: complete signup and reach the dashboard. Audience: first-time SaaS founders evaluating the product quickly.
Claude calls dev_test with the target URL and task. Swarm creates a temporary public route for localhost, runs the personas, and returns a batch ID. Claude then calls dev_watch to wait for structured findings and the synthesis report.
A narrow goal produces better evidence than "review my app." The persona needs a finish line, and the developer needs to know which flow a finding belongs to.
What happens to localhost during the test?
The MCP server starts a short-lived Cloudflare tunnel so Swarm's cloud agents can reach the running app. The tunnel carries HTTP traffic to the dev server. It does not upload the repository or give Swarm direct access to source files.
If the frontend and backend use separate ports, pass a backendUrl. The local proxy routes common API paths to the backend while the rest goes to the frontend. Extra prefixes such as /ws or /v1 can be supplied with backendPaths.
Keep both servers running until dev_watch finishes. The tunnel closes automatically after the completed result, and dev_close can tear it down manually if a run is cancelled.
Can Claude test authenticated flows?
Yes. Swarm supports three authenticated testing modes:
| Mode | Use it when | What you provide |
|---|---|---|
| Agent login | A reusable test account already exists | Login URL, username, and password |
| Signup | Each persona should create a fresh account | A base email that supports plus addressing |
| Cookie injection | You need to start from an existing session | Exported test-session cookies |
Use test-only credentials. Login details and cookies are sent to the Swarm API over HTTPS so cloud agents can perform the flow. Never use a production administrator account or a real customer's session.
For signup testing, Swarm creates a unique plus-addressed email for each persona. That keeps accounts separate while confirmation messages still arrive in one inbox. Cookie injection skips the login UI, which is useful when the test begins deeper in the product.
How does the fix-and-retest loop work?
The useful loop is short:
- Ask Claude to run one critical flow.
- Read the highest-severity finding and its screenshot.
- Let Claude inspect the related code and propose a focused fix.
- Run the same goal and audience again.
- Compare whether the original issue is gone and whether the change created a new one.
Keep the task stable between runs. If the audience, goal, and success condition all change, the second run is not a retest. It is a different study.
What can MCP usability testing catch?
MCP testing is good at broken navigation, unclear labels, validation problems, missing loading feedback, dead ends, and recovery paths that do not explain the next action. It is especially useful for signup, onboarding, checkout, settings, and other stateful flows that developers change often.
It is weaker at brand perception, emotional trust, and claims about what a market segment will buy. AI personas generate test coverage and hypotheses. They do not become customers because they clicked the button. For decisions that depend on real experience, follow the automated pass with human research. The AI versus human usability testing guide explains which evidence belongs to each method.
Does Codex support the same MCP server?
Yes. The setup command can register Swarm with Codex CLI, and OpenAI's current Codex MCP documentation describes MCP server configuration in ~/.codex/config.toml or a project-scoped config file. The same Swarm tools are available after Codex restarts.
That makes the workflow editor-agnostic. The agent that changed the flow can call the same test, read the same findings, and rerun it without copying reports between products.
How much does Swarm MCP cost?
Swarm MCP access is included on the Startup plan, currently listed at $150 per month. The free tier includes limited browser-based runs but does not include MCP. Check the MCP page for the current plan and install details before wiring it into a team workflow.
The fastest way to judge it is to pick a flow your team changes often. Set up Swarm MCP, run the same signup or checkout goal before each release, and see whether it catches enough concrete friction to earn a place beside your functional tests.