Dependabot for MCP
Dependabot works because npm packages are versioned: nothing changes until you upgrade. Remote MCP servers break that assumption, the contract lives server-side and can change under you with no version bump, no changelog, and no PR to review.
Zevruna gives MCP dependencies the Dependabot experience: continuous watching, a classified diff when something changes, an advisory feed like a CVE database for contract breaks, and a CI gate that fails builds until your code catches up to the new contract.
Where the analogy ends
Dependabot opens a PR that bumps a version. Zevruna goes further: because manifests declare exactly which fields each agent sends and reads, the alert includes blast radius and a suggested patch, and its MCP server lets your coding agent apply the fix, `claude "fix ZV-42"` pulls the diff and edits the call sites, and a green check resolves the incident automatically.
What a pin can and cannot do here
An npm lockfile holds a dependency still. An MCP pin cannot: the server's new schema has already shipped, to everyone, before you saw it. What the pin does is record which contract your code was written against, so CI fails the moment the two disagree.
So the guarantee is different in kind. Dependabot promises nothing changes until you say so. Zevruna promises nothing reaches production while your code and the contract disagree. The second is the strongest promise available once the versioning is outside your control.
The part Dependabot cannot do
A version bump is the same edit for everyone. A contract change is not: it lands differently on every consumer depending on which fields they send and read. Because manifests record that per agent, the alert can say which agents break, at which call sites, rather than that a dependency moved.
And the fix loop closes the same way a Dependabot PR does. Zevruna ships its own MCP server, so a coding agent can be told to fix an advisory by id, pull the diff and blast radius, edit the call sites, and rerun the check, with the green check as the resolution and no repo write access on Zevruna's side.
Questions
My servers are pinned npm packages, do I need this?
Less urgently. Version-pinned stdio servers can't drift until you upgrade. The moment any dependency is a remote hosted server, the pinning guarantee disappears, that's the gap this fills.
Does it open pull requests like Dependabot?
Not on its own, and deliberately: it holds no write access to your repository. It hands your coding agent the diff, the blast radius and a suggested patch, and the agent makes the edit where you can review it.
What triggers a build failure?
A mismatch between a manifest and its pinned snapshot, from either side. Your code changing to send something the contract does not accept fails the same check as the contract moving underneath unchanged code.
Is there a feed I can watch without signing up?
Yes. Every breaking change observed on a public server is published as an advisory with a citable id, available as JSON and RSS, and each monitored server has its own changelog page.