Quickstart

You’ll need an AI coding tool that supports MCP (Claude Code, Cursor, Windsurf, VS Code, Codex and others) and a copy of your app it can reach and use: running on your computer, a staging site, or production.

1. Create a free account

   Go to flowproof.dev/signup, enter your email and follow the link we send you. No card, no trial clock: the Free plan includes 10 test runs a month.

2. Create an API key

   In your dashboard, open Setup and create a key. Give it a name like “Laptop, Claude Code”: one key per computer or agent means you can switch one off without touching the others.

3. Connect your agent

   Paste one snippet into the AI tool you use, replacing fp_YOUR_KEY with your key. (The dashboard’s Connect your agent page shows the same snippets with your new key already filled in.)

   Claude Code

   Run this in your terminal, in your project folder:

   TerminalCopy

   claude mcp add --transport http flowproof https://mcp.flowproof.dev/mcp --header "Authorization: Bearer fp_YOUR_KEY"

   Every other tool

   Each one reads a slightly different file. The exact setup for yours:

   • Cursor (Editor)
   • Windsurf (Now called Devin Desktop)
   • VS Code (With GitHub Copilot)
   • Codex (OpenAI’s Codex CLI, in the terminal)
   • Claude Desktop (Chat app)
   • Replit (Replit Agent, in the browser)
   • Other tools (Any MCP client)

   To check it worked, look at your tool’s list of MCP servers (in Claude Code, type /mcp):flowproof should be connected. The “Get started” checklist in your dashboard also ticks off this step the first time your agent talks to Flowproof.

4. Ask your agent to test your emails

   If your app is built, paste this into your agent:

   Prompt · my app is builtCopy prompt

   Use Flowproof to test my app’s signup and password reset emails. Map every email my app sends first. Clean up the test users when you’re done, then show me the report.

   Still building it? Have Flowproof plan the emails your app needs from day one, then build and test each one as you go. Change the part in parentheses to what your app is:

   Prompt · I’m building my appCopy prompt

   Use Flowproof to plan the emails my app needs (it’s a SaaS with teams and Stripe billing), save them to the email map, then help me build and test each one as we go. Add Flowproof’s email rules to CLAUDE.md.

   More to try, like mapping every email your app sends or checking everything before launch, in Then ask it to test.

   Or be more specific about where your app runs and what to test:

   PromptCopy prompt

   Use Flowproof to test the signup, email verification and password reset emails of our app running at http://localhost:3000. Use the project name "acme". Test the unhappy paths too (wrong code, reused reset link, duplicate signup). When you're done, end the session and read me the report.

   The agent opens a run, signs up with a test address, waits for each email, clicks the links, tries the unhappy paths (a wrong code, a reset link used twice), then ends the run and reads you the report. If your AI can’t drive a browser, as in claude.ai, you do the clicking and it tells you where: Flowproof doesn’t count your typing time against your app’s email speed.

<!-- flowproof:email-rules -->
## Emails: built and tested with Flowproof

This app’s emails are planned, built and tested with Flowproof (the `flowproof` MCP server). Whenever you add or change code that sends email:

- When you add or change an email, add it to the Flowproof email map with `save_email_map`, status `built`. If it is in the map as `planned`, save the same key as `built`.
- Send it through the app’s real email provider. Never leave a `console.log` stub, a fake transport or a TODO in a code path production runs.
- Include a plain-text part as well as the HTML.
- Name the product in the subject and in the first line.
- On security email (verification, sign-in links and codes, password resets), add a line for people who didn’t ask for it: “Didn’t ask for this? You can ignore this email.” On notices that a password, email address or sign-in changed, say what to do if it wasn’t them.
- Give each email what its kind must have: `plan_emails` lists it (a reset says how long the link lasts and works once; a failed payment shows the amount and links to update the card; an invite says who invited them to what).
- Before you call the task done, test the email with Flowproof: `whats_next` first (it says where the project stands and what to do), then `start_session`, `new_address` for each recipient, `mark_step`, trigger the email, `wait_for_email` with its `map_key`, use its link or code and `record_outcome`, then `end_session`. Tell the user the grade and what to fix.
- Re-test only the emails whose map entry changed in this task. The others keep their results.
- Never test with a real inbox: use only addresses from `new_address`, and open the session before creating any user.
- Build a `suggested` email only after the developer accepts it (`accept_suggestions` makes it `planned`). Every email that is not transactional has an unsubscribe link and a link to email preferences; marketing goes only to people who opted in.
<!-- /flowproof:email-rules -->