Breakage Calendar MCP server
Checks Celery dependency and version references for dated breakages, such as Celery beat behavior around repeated clock hours, and reports whether a project may hit them plus tested fixes.
Checks Docker image tags and versions, such as postgres:latest, against the Breakage Calendar for dated upstream changes, flagging hits and suggesting tested pins or fixes.
Checks GitHub Actions workflow files, action references, and runner labels for dated retirements or breaking changes, reporting affected lines and available fixes.
Checks macOS runner labels such as macos-14 for retirement dates and other dated breaking changes, reporting hits and suggested fixes.
Checks Node.js version and package references, including Homebrew entries such as node@18, for dated breakages and available fixes.
Checks npm package and version dependencies for dated upstream breaking changes, reporting hits and tested fixes.
Checks OpenAI model references such as gpt-4o snapshots for retirement dates and identifies libraries that may default to retiring models, with affected-version guidance.
Checks PyPI package and version dependencies for dated upstream breaking changes, reporting hits and tested fixes.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Breakage Calendar MCP server check my project for upcoming breakages"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Breakage Calendar MCP server
check docker:postgres:latest pypi:celery==5.4.0 pypi:langsmith runner:macos-14 → postgres:latest is due to move to 19 on 19 November 2026: HITS, tested fix (pin postgres:18; we ran it on 13 November). The macOS 14 runner was retired on 2 November: HITS. langsmith's evaluator sends gpt-4o by default, and OpenAI removes the snapshots gpt-4o points to on 14 January 2027: MAY HIT. Celery beat paused for the repeated hour in our tests when US clocks went back on 1 November: MAY HIT, tested fix.
That is this server's real answer on 13 November 2026 (five dates in all), from the Breakage Calendar: 65 dated upstream changes that break working software, each with the check that finds it and, for 29 of them, a fix we ran ourselves.
An MCP server (and a command) for coding agents that upgrade, pin or deploy a project. It answers: which dated breaks hit this repository or this dependency list, and what is the tested fix? No key, no account, no dependencies.
Install
Node.js 18.17 or later. Every client starts the same command:
npx -y github:CyberNative-AI/breakage-calendar-mcpClaude Code (from the project folder, so check_repository can read it):
claude mcp add breakage-calendar -- npx -y github:CyberNative-AI/breakage-calendar-mcpClaude Desktop, Cursor, Windsurf, Cline and other clients with an mcpServers JSON file:
{
"mcpServers": {
"breakage-calendar": {
"command": "npx",
"args": ["-y", "github:CyberNative-AI/breakage-calendar-mcp"]
}
}
}VS Code (.vscode/mcp.json):
{
"servers": {
"breakage-calendar": { "type": "stdio", "command": "npx", "args": ["-y", "github:CyberNative-AI/breakage-calendar-mcp"] }
}
}To pin a release, write github:CyberNative-AI/breakage-calendar-mcp#v0.1.0.
Without MCP, the same answers on the command line:
npx -y github:CyberNative-AI/breakage-calendar-mcp check docker:postgres:latest pypi:celery==5.4.0
npx -y github:CyberNative-AI/breakage-calendar-mcp repo .
npx -y github:CyberNative-AI/breakage-calendar-mcp upcoming 90Related MCP server: driftwatch-mcp
Tools
Tool | What it answers |
| Reads a local project folder and runs every date's published search over its files: which dates hit it, on which line, and the fix. |
| The same for a list such as |
| The same for file contents the agent passes ( |
| Dates still to come, by area ( |
| One date in full: what changes, who is affected, the check command, the fix, and the vendor sources with the day we last read each. |
Each finding says HITS (the search matched a line that uses what changes) or MAY HIT (it is used, and only some setups break; the entry's check tells which). Dates that took effect in the last 30 days are included, because a project still on the old line is already broken.
What it adds to endoflife.date and a web search
endoflife.date tells an agent when a version stops getting updates. A web search finds an announcement once the agent knows what to search for. Neither tells it that postgres:latest moves to 19 on 19 November 2026, and that a stack already holding 18's data then stops starting. This calendar records the day something stops working, which is often not an end-of-life date at all: an image tag that moves to a new major version, a model that a library sends by default, a CI runner label that is retired, a time-zone rule that changes. For each date it gives:
the search that finds it in a repository's files, run for you; for dates a repository cannot show (a running server, a clock, a certificate), the check to run where it lives;
who is and is not affected, from our own tests where we ran them;
the fix: one we ran, with the day we ran it, or a guide, or, where we have neither, the vendor's notice and the words "no tested fix yet";
the vendor's own notices, each with the day we last read it.
On 13 November 2026 that was 65 dates: 49 with a repository search, and 29 with a fix we ran. It does not replace either source: it covers the dates we have researched, not every version of every product. For a product's support dates, ask endoflife.date.
What it reads and sends
It fetches two files, by GET with no body:
https://cybernative.ai/breakage-calendar/entries.jsonandhttps://cybernative.ai/breakage-calendar/check/signatures.json, with the user agentbreakage-calendar-mcp/0.1.0 (+https://github.com/CyberNative-AI/breakage-calendar-mcp), and refuses redirects. It keeps them in memory and asks again after an hour (withIf-None-Match). Like any web request, these show our server your IP address and the time. Nothing from your project, dependency list or files is sent.check_repositoryreads text files up to 1 MB, at most 20,000 files, skipping.git,node_modules, virtual environments and build output, and does not follow symlinks. It reads only inside the folder the server was started in, and any folders listed inBREAKAGE_CALENDAR_ROOTS(separated by:;;on Windows). Started with--roots(npx -y github:CyberNative-AI/breakage-calendar-mcp --roots ~/code/app ~/code/api), it reads only the folders given after it, and no folder if none is given.The searches come from the calendar files, so they run in a separate thread with a 2-minute deadline and a 256 MB heap limit.
If cybernative.ai cannot be reached, the tools say so; after a first successful read they keep answering from that copy and say it is stale. There is no bundled copy of the dates.
Agents and scripts that do not use MCP can read the same public JSON directly: entries.json (every date) and check/signatures.json (the searches).
Limits
A search finds what a repository's files show. Dates that depend on a server, a certificate, a clock or a browser are listed as such, with their own check.
check_dependenciesturns each item into the line a manifest would hold, so a version-specific date matches only when you give the version.MAY HIT means "read the check": in our tests only some versions or settings broke.
Development
npm testNo dependencies. src/match.js is a byte copy of the matcher that the in-browser check runs, so both give the same answer for the same files.
Built and maintained by CyberNative AI LLC, an AI-run company with one human founder. This server, the calendar and this README were written by AI agents. Report a wrong or missing date as an issue here, or to hello@cybernative.ai. Apache License 2.0.
Available Tools
5 toolscheck_dependenciesDated breaks for a dependency listARead-onlyIdempotent
Which dated upstream changes (image tags that move, AI models and APIs that shut down, CI runners that are retired, packages that stop installing) will break these dependencies, and the fix for each, with the day it was tested. Runs each Breakage Calendar date's own published search. Use before upgrading, pinning or deploying. Write each dependency as ecosystem:name[@version]: npm package: npm:express@4.21.0, npm:@scope/name; Python package: pypi:celery==5.4.0, pypi:paramiko; Ruby gem: gem:rails@8.0.2, gem:sidekiq-cron; Go module: go:golang.org/x/crypto@v0.31.0; Maven artifact: maven:com.jcraft:jsch@0.1.55; container image: docker:postgres:latest, docker:node:lts, docker:php:8-apache; GitHub Action: action:actions/setup-python@v5; CI runner label: runner:ubuntu-latest, runner:macos-14; Homebrew formula: brew:node@18; AI model id your code sends: model:gpt-4o, model:claude-sonnet-4-5; R package: cran:decoupleR.
Inputs: dependencies (required), days_ahead.
check_filesDated breaks in given filesARead-onlyIdempotent
Runs every Breakage Calendar date's published search over file contents you pass (package.json, requirements.txt, pyproject.toml, Gemfile.lock, go.mod, Dockerfile, compose.yaml, .github/workflows/*.yml, source files that name AI models) and reports the dates that will break them, with the file line, the check and the tested fix. Use when the server cannot read the project folder itself.
Inputs: files (required), days_ahead.
check_repositoryDated breaks in a local repositoryARead-onlyIdempotent
Reads a local project folder (text files only; skips .git, node_modules, virtual environments and build output) and runs every Breakage Calendar date's published search over it: which dated upstream changes will break this repository, on which line, and the tested fix. Nothing from the folder is sent anywhere. The folder must be inside a folder this server may read: its working folder and BREAKAGE_CALENDAR_ROOTS, or, when the client chose folders, only those.
Inputs: path, days_ahead.
get_breakOne dated break in fullARead-onlyIdempotent
The full Breakage Calendar entry for one id: what changes, who is affected, how to check, the fix (with the day we tested it, if we did), the command, and the vendor sources with the day each was last read.
Inputs: id (required).
list_upcoming_breaksUpcoming dated breaksARead-onlyIdempotent
Lists Breakage Calendar dates still to come: runtimes, images, APIs, AI models, CI runners, certificates and time-zone rules that stop working on a known date, each with the kind of fix (tested, guide, or none yet). Filter by area or a word.
Inputs: area, query, days_ahead.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 5 tools
The three check_* tools are separated primarily by input source: a list of dependency identifiers, raw file contents, or a local folder path. The descriptions make this boundary reasonably explicit, though an agent with a repository in hand could plausibly hesitate between check_files and check_repository. list_upcoming_breaks vs get_break are cleanly distinct (browse vs fetch by id).
Every name is snake_case verb_noun (check_dependencies, check_files, check_repository, list_upcoming_breaks, get_break) with a single consistent verb family per action type. No mixed conventions or case styles.
Five tools is well scoped for a breakage-calendar lookup service: three input-variant checkers plus browse and detail retrieval. Each tool earns its place and nothing looks redundant padding.
The surface covers discovery (list), detail (get), and checking across all plausible input forms (dependency list, raw files, local repo). Minor gaps remain: no date-range or past-break filtering on the list tool, and no way to look up breaks by affected dependency name short of free-text filtering.
Maintenance
Related MCP Connectors
Dated, verified API breakages for coding agents, plus a local scan for them in your existing code.
Monitor third-party API changes in GitHub repos, map breaks to files, open reviewable auto-fix PRs.
Check exact npm/PyPI upgrades for evidence-backed breaking changes; query APIs and components.
What broke since your version, for 60 popular APIs/SDKs. Free quick check; full reports via x402.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides breaking changes analysis for libraries across multiple languages, enabling version upgrade planning, dependency audits, and migration reports through MCP tool access and expert workflows.-
- AlicenseNot gradedqualityBmaintenanceEnables AI coding agents to identify exactly what broke between two dependency versions, with citations for every claim, and to verify package existence to catch typosquatting, all without requiring an API key.MIT
- AlicenseNot gradedqualityCmaintenanceEnables coding agents to retrieve maintainer-written release notes and compare installed versus target dependency versions, search packages, and report on projects pushed to a dashboard.MIT
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to query breaking API changes in dependencies since a model's training cutoff, retrieve project dependency change summaries, and look up model training cutoff dates.35 PyPI10MIT