Your AI agent upgrades the vulnerable dependencies. We tell it what to upgrade and check the result.

One run, from an MCP client

The MCP server is hosted, so there is nothing to install. You need a Max account, an API key from Settings, and a lockfile already uploaded for the app.

claude mcp add --transport http vulneraibility \
  https://www.vulneraibility.com/api/mcp \
  --header "Authorization: Bearer vai_xxxxxxxx_yyyy"

Fix the vulnerable dependencies of billing-api.
Follow the vulneraibility patching loop: one pull
request, and verify it before you stop.

{
  "mcpServers": {
    "vulneraibility": {
      "type": "http",
      "url": "https://www.vulneraibility.com/api/mcp",
      "headers": {
        "Authorization": "Bearer vai_xxxxxxxx_yyyy"
      }
    }
  }
}

The calls the agent makes, in order

1. get_meYour plan and workspace role, so the agent knows what it may write.
2. list_appsYour apps, each with its stack and versions.
3. get_app_repoWhere the app’s code lives: provider, repository URL, default branch, and which manifest belongs to which lockfile. A note for the agent; the server never connects to it.
4. get_remediation_planPreview of the plan for each lockfile, in priority order. Stores nothing.
5. create_remediation_planStores one lockfile’s plan and returns its id. Calling it again for the same scan and items returns the same plan.
6. create_patch_runStarts a run in state planned from that plan id. With an idempotencyKey, a retried call returns the same run.
7. The agent creates a branch, edits the manifest and lockfile, installs, runs the tests, pushes, and opens the pull request with your credentials. No vulneraibility call is involved.
8. update_patch_runMoves the run to pr_open and records prUrl, branch and commitSha.
9. verify_patchSends the branch’s new lockfile. Verdict fixed moves the run to verified; anything else moves it to verify_failed and lists what is still open.
10. update_patch_runMoves the run to merged after you merge, then to closed.

To pick up an earlier run instead of starting a new one, the agent calls list_patch_runs and get_patch_run.

The same loop from CI, over REST

Every tool is a thin wrapper over one endpoint. Send the API key as a Bearer token.

# after your CI job has pushed the branch and opened the pull request
curl -sS -X PATCH -H "Authorization: Bearer $VAI_API_KEY" -H "Content-Type: application/json" \
  -d '{"state":"pr_open","prUrl":"https://github.com/acme/billing-api/pull/42",
       "branch":"vai/bump-lodash","commitSha":"3f9c2e1"}' \
  https://www.vulneraibility.com/api/v1/patches/$RUN_ID

# verify the branch's lockfile
jq -n --rawfile text package-lock.json '{lockfile: {filename: "package-lock.json", text: $text}}' |
curl -sS -X POST -H "Authorization: Bearer $VAI_API_KEY" -H "Content-Type: application/json" \
  --data-binary @- https://www.vulneraibility.com/api/v1/patches/$RUN_ID/verify
# -> { "success": true, "run": { "state": "verified", ... }, "verification": { "verdict": "fixed", ... }, ... }

Request and response fields, error codes and a ready GitHub Actions workflow are in the patching section of the docs.