Cursor testing: verify the agent's change in the running app

Cursor testing works best when the agent has to prove its change in the running app before it calls the task done. Reticle is an MCP server the Cursor agent can call: it drives the changed flow and returns a pass or fail with evidence from the network, the app state and the console.

Why the agent's own tests are not enough

The Cursor agent reads the task, writes the code, often writes the tests, and reports back. When its reading of the task is wrong, the tests encode the same mistake and pass. The summary is a description of what it meant to build.

A screenshot or a passing test also misses the failures that look fine: a request that fires twice, a write that returns 200 and never persists, a store that disagrees with the total on screen. Why a green check isn't proof walks through how those slip past, and AI verification defines the step that catches them.

Set up Reticle in Cursor

Cursor talks to tools over the Model Context Protocol. Add Reticle's MCP server to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "reticle": { "command": "npx", "args": ["@reticlehq/server", "mcp"] }
  }
}

Restart Cursor, because it reads this list only when it starts. Then add the skill that teaches the agent to wire your app and prove one flow:

npx skills add reticlehq/reticle --skill reticle

Finally, wire the app from its folder with npx @reticlehq/server init. It adds the dev-only SDK and build plugin, writes agent rules to AGENTS.md, and adds a prompt hook in .cursor/hooks.json so each request is kept as the thing a verdict is checked against. --dry-run writes nothing. Details are in the Reticle README. The installer script (reticle setup install) can also register the MCP server with Cursor for you.

What the verify loop looks like

1. You ask the agent for a change.
2. It edits the code and calls Reticle to drive the affected flow in your running app.
3. Reticle reads the network calls, the state and the console after each step.
4. A fail names the evidence, and on React and Svelte the file:line. The agent fixes it and verifies again.
5. The flow is saved under .reticle/flows/ and replays later with no model in the loop.

In CI, npx @reticlehq/server verify <url> replays every saved flow and exits non-zero when one fails. Re-verifying a four-flow suite costs about 480 tokens, and the same flow replayed eight times gave the same verdict every time (benchmark scorecard).

Limits

• Full depth needs your app. Reticle also works on sites you don't own: it drives the page in its own browser, injects its SDK, and reads network, console, DOM and routing. App state and the file:line source pointer need the SDK built into your own app.
• One engine, no pixel diff. Reticle is not a cross-browser runner, and a screenshot is still the ground truth for pixels.
• Source lines on React and Svelte. Reticle works on React, Next.js, Vue, Svelte and Angular. The file:line pointer covers React and Svelte components; Vue and Angular get every other check without the line.

If you already use a browser MCP server in Cursor, Reticle vs Chrome DevTools MCP explains where each fits. The same setup for other agents is on the Claude Code testing and Codex testing pages.

FAQ

How do I test changes made by the Cursor agent?

Test changes made by the Cursor agent with a check the agent does not author. Run the app, drive the changed flow, and read what happened in the network calls, state and console. Reticle does this as an MCP server Cursor calls, returning a pass or fail with evidence and, on React and Svelte, the source line to fix.

How do I add an MCP server for testing in Cursor?

Add the server to ~/.cursor/mcp.json under mcpServers, then restart Cursor so it loads the new tools. For Reticle the entry runs npx @reticlehq/server mcp. After that, run npx @reticlehq/server init in your app's folder so the agent has something inside the app to verify against.

Why does Cursor say the change works when it does not?

Cursor says a change works when its own checks agree with its own code. The agent writes both from the same understanding of the task, so a wrong assumption passes its tests. Screens can also look right while a request fails or fires twice. A check that reads the running app catches those.

Does Reticle replace Playwright tests in a Cursor project?

No. Reticle checks the agent's changes inside your running app while it works and replays saved flows in CI. Playwright remains the tool for hand-written, cross-browser end-to-end suites and zero-setup runs on any URL. Many teams keep their Playwright suite and add Reticle for the agent's inner loop.