A typical run

This is the order an agent follows for one finding. The fix_security_findings prompt gives an agent the same steps in one message; see The six tools.

1. 1

   Find the project

   Call list_projects with the repository's git remote, for example the output of git remote get-url origin. If more than one project matches, pick the one whose source matches the repository, branch and directory.

   If no project is found, pass repo as owner/name or the git remote. The connection must include the project, and you need read access to it.

2. 2

   List the findings

   Call list_findings for that project. Use pathPrefix to see only the findings in the files you are touching. Findings come most severe first, and open and unverified ones by default.

3. 3

   Read one and fix it

   Call get_finding, then fix the code in your own checkout and run its tests. Make the smallest change that removes the problem.

4. 4

   Report it

   Call report_finding_action with action: "fixed", a short note and evidence:

   • commitSha: 7 to 64 hexadecimal characters.
   • pullRequestUrl: a GitHub pull request of a repository linked to the project.
   • branch.

   Every report needs an idempotencyKey of 8 to 64 characters from A–Z a–z 0–9 _ -. Send the same key to retry safely, and a new key for each new report.

5. 5

   Re-check after the merge

   After the fix is merged to the tracked branch, request_recheck may confirm it. A re-check reads the tracked branch, so the fix must be merged first. If it finds the old code, the fix is not merged yet.

Cost

MCP calls are not billed. Each re-check is a costed run on your organization's plan, and it can be refused when the plan or the usage allowance does not allow it. See Troubleshooting.