Skip to main content
Glama
Breakage Calendar MCP server

Breakage Calendar MCP server

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-mcp

Claude Code (from the project folder, so check_repository can read it):

claude mcp add breakage-calendar -- npx -y github:CyberNative-AI/breakage-calendar-mcp

Claude 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 90

Related MCP server: driftwatch-mcp

Tools

Tool

What it answers

check_repository

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.

check_dependencies

The same for a list such as docker:postgres:latest, pypi:celery==5.4.0, npm:cron@3.1.7, gem:rails@8.0.2, go:golang.org/x/crypto@v0.31.0, maven:com.jcraft:jsch, action:actions/setup-python@v5, runner:macos-14, brew:node@18, model:gpt-4o, cran:decoupleR. Also names the libraries we found sending a retiring AI model when you do not choose one.

check_files

The same for file contents the agent passes (package.json, requirements.txt, compose.yaml, Dockerfile, .github/workflows/*.yml, Gemfile.lock, …), for a server that cannot read the folder.

list_upcoming_breaks

Dates still to come, by area (AI APIs, CI runners, Time zones, …) or word.

get_break

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.

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.json and https://cybernative.ai/breakage-calendar/check/signatures.json, with the user agent breakage-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 (with If-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_repository reads 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 in BREAKAGE_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_dependencies turns 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 test

No 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 tools
check_dependenciesDated breaks for a dependency listA
Read-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 filesA
Read-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 repositoryA
Read-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 fullA
Read-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 breaksA
Read-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

    A4.1/5.0

    Scored across 5 tools

    Disambiguation4/5

    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).

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables 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
    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables 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 PyPI
      10
      MIT