2026-08-12

How to pin MCP server schemas in CI (lockfiles for tool contracts)

Package managers solved dependency drift with lockfiles: record exactly what you built against, fail loudly on divergence. Remote MCP servers need the same discipline, and it takes about five minutes to set up.

The pattern

1. Snapshot: `zevruna snapshot <endpoint>` canonicalizes the server's advertised contract and writes a content-addressed JSON (the hash is your lock). 2. Manifest: `zevruna scan` generates a per-agent declaration of tools and fields used, with call sites. 3. Check: `zevruna check --against pinned` in CI fails the build when either side drifts, your code sending fields that no longer exist, or the server changing under an open PR.

Run the check on push, on PR, and nightly. The nightly run is the one people skip and shouldn't: it catches the case where the server drifted and your code didn't change, which no test in your repo can see because nothing in your repo changed.

Pin ≠ resolved

When a break lands, pinning the new snapshot means 'this is now the contract I code against', a lockfile update, not a fix. The incident resolves only when the check goes green against that pin, automatically, with the exposure window recorded. Resolution earned by CI beats resolution claimed by a human clicking a button, every time.

Keep reading

Why MCP servers break agents silently (and your error tracker stays green)

A field guide to MCP breaking changes: the 13 ways a tool schema can hurt you

Error tracking vs. contract monitoring: what each one structurally can't see