Paths for developers, agents, platform, and CI

If you're on one API — or one MCP server you trust and actively maintain — a small in-repo check is often the right call. When you need a system across many endpoints — baseline, severities, CI gates, production watches, and incident evidence — that's the loop DriftGuard ships: OSS locally, hosted when it has to run without someone remembering.

For local diff, lockfiles, and proving value on a single endpoint, the MIT client is the right starting point — we'd tell you to start there. Hosted pays for always-on watches, drift history, alert routing, and fleet views when vendor changes land between your releases, not only on pull requests.

Retries help on timeouts and blips. They don't recreate a removed MCP tool or tell you a required field appeared upstream. On low-stakes flows, improvisation may be fine. On money-moving or compliance paths, you want contract drift detected before the agent rationalizes around it — not after support tickets spike.

Evals test agent behavior on scenarios you chose. Drift detection tests whether live APIs and tools/list catalogs still match what you committed to. If your evals hit production-shaped contracts and you refresh baselines as fast as vendors change, you're ahead of most teams — still, mocks that pass while live shape drifts is a common postmortem pattern. The two stack; neither fully replaces the other.

IDEs help you write and refactor code you own. They don't schedule snapshots against vendor MCP catalogs or fail a build when live OpenAPI drifts from your lockfile. Different layer — editor vs watchtower.

For a single experimental MCP hook, waiting is reasonable. If agents already call vendor tool catalogs in production, early is often when it hurts most — before stable SDKs, semver discipline, and changelog muscle memory exist.

Uptime and APM answer is it up? and what failed in our stack? DriftGuard answers did the contract change? — tool removed, field dropped, schema tightened. Often before error rates move. Same incident room, different signal.

Linting the spec in your repo is the right discipline for APIs you author. DriftGuard targets live endpoints and MCP tools/list — the surface your agents call, which can move without a PR in your org.

Consumer-driven contracts work when both sides participate. DriftGuard is for third-party REST and MCP servers that change on their schedule — no paired release, no provider test suite in your pipeline.

Error and observability tools tell you something broke. DriftGuard can tell you integration assumptions changed — sometimes days before exceptions cluster. We'd run both, not instead of either.

When vendors are disciplined and someone tracks every dependency, changelog-driven process can work. DriftGuard adds machine-checkable proof that live shape still matches your baseline — not a summary written for humans, easy to miss on a Friday deploy.

If every contract change ships through your pipelines and your tests already gate production, you may not need us — honestly. DriftGuard earns its place when someone else moves the goalposts: SaaS, partners, or MCP catalogs your agents don't control.