How to check Cursor's code changes before you commit.

Add a remote (streamable HTTP) MCP server with just the URL, in Cursor's MCP settings or your mcp.json:

{
  "mcpServers": {
    "veridu": { "url": "https://api.veridu.io/mcp" }
  }
}

Browser sign-in works in any client that signs in through a local (127.0.0.1 or localhost) redirect. If the sign-in fails (some clients use an app-specific redirect, which Veridu does not accept), create a token with the MCP only scope on the Tokens page and send it as a Bearer header. Full-access tokens are not accepted by the MCP server.

{
  "mcpServers": {
    "veridu": {
      "url": "https://api.veridu.io/mcp",
      "headers": { "Authorization": "Bearer <MCP-ONLY TOKEN>" }
    }
  }
}

Add this line to your project rules:

Before committing, call Veridu's verify_change. Review and fix valid findings, then run it again to check what is still open.

Or ask for a check when you want one: "verify this change with Veridu". No repository to connect.

1. 1
   Cursor sends the change. When it follows the rule (or you ask it to), it calls verify_change with the diff, the full content of the files it changed and a sentence on what the change is for. Independent reviewers check it in an isolated sandbox with no internet access, usually in one to two minutes.
2. 2
   It gets findings it can act on. An outcome (pass, review or block) and findings with the file, line, severity and evidence. Veridu tries to keep each finding's id the same across follow-ups, matching on the file, the code and the nearby lines.
3. 3
   It fixes what holds up and checks again. When it checks the fixed change, Veridu links the follow-up to the first check automatically. The follow-up reports which findings persist, which are new (possibly introduced by the fix) and which are no longer reported, which is not proof of a fix. The first two linked follow-ups are free.

A real example: one change checked four times, where a finding that went quiet came back under the same id.

It sees only the files Cursor sends, not your whole repository. For the code a change affects elsewhere, review the pull request too: how to review AI-generated pull requests.