Making Dependabot and Renovate cleanup agent-ready with MCP

August 26, 2026 · 7 min read

Dependabot and Renovate are very good at one direction of travel. They watch your dependencies, notice when something moves, and open a pull request. What neither does is look backwards at the workarounds a previous upgrade made unnecessary.

That gap has a specific shape. When Renovate bumps request from 2.88.2 to 2.89.0, the override pinning tough-cookie may have just become dead weight — and the PR that caused it says nothing about that, because the bot has no idea the override exists.

Why the bots do not close this loop

It is not an oversight. Answering “is this override still needed?” requires joining three things a dependency bot deliberately keeps separate: the advisory that prompted the pin, the parent's current transitive resolution, and whether the parent version you would need is reachable without a major upgrade.

Dependency bots optimize for a different question — “is a newer version available?” — and answer it without needing to understand why your package.json looks the way it does. Override cleanup needs exactly that missing context.

A coding agent is a good fit for the gap precisely because it can hold that context: it can read the diff, ask a targeted question about an override, and act on the answer in the same session.

Giving the agent the missing tool

An agent asked to “check whether we can drop these overrides” without tools will guess from training data — and training data has a cutoff, which is the worst possible property for a question about current npm versions.

MCP is the mechanism for handing it a live answer instead. Point the agent at a server that can do the lookup and the guessing stops:

{
  "mcpServers": {
    "backpatch": {
      "command": "npx",
      "args": ["backpatch-mcp"],
      "env": { "BACKPATCH_API_KEY": "<your-key>" }
    }
  }
}

That exposes three tools:

analyze_overrides — every override in a package.json, each with a status and a reason
check_override — one package, when the agent is reasoning about a single entry
explain_override — the advisory behind a pin, for when the commit history has lost it

The workflow that actually pays off

The valuable trigger is not “ask occasionally.” It is attaching the check to the event that can make an override redundant — a dependency upgrade landing. Concretely, on a Renovate PR:

The bot bumps a parent dependency and opens a PR.
The agent reads the diff and runs analyze_overrides against the package.json on that branch.
Anything that comes back SafeToRemove is a candidate: the parent on this branch already pulls in a safe version.
The agent deletes those entries, re-resolves the lockfile, and runs the tests — the verification step no static analysis can skip.
It comments on the PR with what it removed and why, citing the advisory each pin was for.

The upgrade and the cleanup it enabled land together, reviewed as one change. That is the loop the bots leave open.

What to hold the agent to

A few constraints separate this from an agent confidently deleting your security fixes:

Removal is a proposal, not an action. The agent opens a PR; a person merges it. Override deletion touches the security posture of the application, and that deserves a human on the other side of it.

NeedsMajorUpgrade is not SafeToRemove. The distinction exists because collapsing it produces a PR that deletes an override and breaks the build. Instruct the agent to report those separately and leave them alone.

The test run is not optional. Static analysis says the parent should resolve safely. A clean re-resolve plus a green test run is what confirms it did. If the agent cannot run the tests, it should say so rather than claim the change is verified.

Every removal cites its advisory. The reviewer needs to see which advisory the pin was for and why it no longer requires the pin. “Backpatch said so” is not a reviewable justification.

Starting smaller

You do not need PR automation to get most of the value. Ask your agent, once, in the repository you most suspect:

Analyze the overrides in this package.json with backpatch.
For each one, tell me the status, the advisory it was added for,
and what parent upgrade would let us remove it.
Do not change any files.

In most repositories that have been running a couple of years, some of those entries have been unnecessary for months. Finding out which is a five-minute conversation — and it tells you whether the automated version is worth building.

Backpatch answers this question automatically.

It checks whether the parent dependency already pulls in a safe version, for every override in your package.json, and tells you which ones you can delete. Works as a REST API or an MCP server.

Start a 14-day trial Read the docs