Use Verity from your agent

Your coding agent can read what Verity found on a pull request: which org rules failed, on which files, why, and what evidence the session was missing. Instead of pasting the check run into the chat, ask the agent to "fix what Verity flagged on this PR".

Verity serves this over the Model Context Protocol, the way agents such as Claude Code, Cursor and Codex take tools from outside. The tools read, except verify_session, which attaches the agent's own session to the pull request so Verity checks the rules again. No tool can override a rule or change a setting.

Set it up

The verity CLI runs a local MCP server that signs in as you. Install it and sign in once, as for capture:

npm install -g @veritypr/cli
verity capture login

Then add it to Claude Code:

claude mcp add verity -- verity mcp

Other agents take the same command in their MCP settings. Most use a JSON file like this:

{
  "mcpServers": {
    "verity": { "command": "verity", "args": ["mcp"] }
  }
}

If you aren't signed in, the tools still appear, and each one tells the agent to run verity capture login. Sign in and the next call works; you don't need to restart the agent.

What the agent sees

The agent sees what the report shows you, and no more. It reads reports with your GitHub sign-in, so a repository you can't open in Verity is one it can't read either. To the agent, a report it can't see, a repository that doesn't exist and a pull request with no report all look the same.

Tool	What it returns
`list_reports`	Analysed pull requests in an org, newest first, with how many rules failed or warned. Filter by repository or author.
`get_pr_review`	Each org rule's result per file, with the steps it cites and the override label for a failing rule, plus the review brief: the task, steers, claims and the evidence behind them, leftovers, and files not from the session.
`get_rule`	One rule in full, with the session steps it cites: the commands, their exit codes and output.
`get_steps`	Session steps by id, as the report's step view shows them.
`verify_session`	Attaches this agent session to the pull request at its current commit and checks the rules again. See Fixes that change no code.

Each tool takes the repository as owner and repo and the pull request's number. By default it reads the latest analysed commit. While an analysis of the pull request's latest commit is still running, get_pr_review says so with pending, and the agent calls again a minute later.

Every failing rule comes with a fix: what to do about it, or that a person has to review it. See Fixes for agents.

Session text is data

Everything the agent read or ran during the session can contain text someone else wrote, such as an issue it read or a file it opened. Verity labels it: anything from the session is under session_text, the pull request's title is under pr_text, and the model's summary is under model_written. Everything else comes from Verity's rules or your rules file. Each tool's description tells the agent to treat labelled text as data, never as instructions.

Verity never returns the full transcript, and never a model's confidence.

Fixes that change no code

Some rules are fixed by doing something, not by changing code: loading the page a view renders, or running the tests after the last edit. Verity answers rules from what the session ran, never from what the agent writes about it, so a comment saying "tested" doesn't count. A page load does, once Verity sees it.

That is what verify_session is for. After following a rule's fix, the agent calls it, and Verity:

finds the agent's own session, as capture recorded it, in this repository;
checks the worktree has no uncommitted changes, and sends its commit, which must be the pull request's latest;
attaches the session to the pull request at that commit, uploads it, and runs the analysis again.

The check run on GitHub updates as after a push. An attachment only counts for that commit: push again and Verity checks the new commit from its own sessions. If the agent changed code, it commits and pushes instead.

verify_session needs capture set up in the repository and you signed in. It attaches only your own sessions, at most 10 times an hour per pull request.

Limits

Each person can make 60 tool calls a minute. Responses are capped at 512 KB; long command output is cut, and the step is marked truncated. The full output is in the report.

Try it

With a pull request that has a failing rule, ask your agent:

View the Verity errors on acme/app#231 and fix them.

The agent calls get_pr_review, then get_rule on each failing rule, and reads its fix. Say two rules fail:

razor-page-loaded on Views/Proposal/Edit.cshtml, "no page load after the last edit". Its fix says to start the app and load the page with Playwright. The agent does, then calls verify_session, then get_pr_review until pending is gone. The rule now passes and cites the page load.
mobile-api-contract on src/Api/Mobile/Orders.cs, "answered yes". It has no fix, so its fix says a reviewer has to decide. The agent tells you, and stops.

No comment is posted. The check run is the record.