How to check AI code changes in PhpStorm before you commit.

In PhpStorm, open Settings | Tools | Junie | MCP Settings and add a remote server with just the URL. It is stored in .junie/mcp/mcp.json in your project, or ~/.junie/mcp/mcp.json for all projects:

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

If Junie shows the server as needing authorization, authorize it and sign in to Veridu in the browser. If the sign-in fails, 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>" }
    }
  }
}

Open Copilot Chat in Agent mode, click the tools icon, then Add MCP Tools, and add Veridu to the mcp.json that opens. Copilot's file uses servers, and the token goes in requestInit. Create the token with the MCP only scope on the Tokens page:

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

In a Copilot Business or Enterprise organization, an admin must allow MCP servers in Copilot.

Add this line to Junie's guidelines (.junie/guidelines.md) or Copilot's instructions (.github/copilot-instructions.md):

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.

Veridu traces callers and overrides only within the files it is sent. When a change alters a method's signature or what it returns, ask the agent to include the classes that call it, and any interface or parent class it implements, alongside the changed files. In the worked example, the caller the agent missed was in a file it sent, which is why Veridu could find it. How Veridu looks for callers.

1. 1
   The agent 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; the check may take a few 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.

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