Breakage Calendar MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BREAKAGE_CALENDAR_ROOTS | No | Additional folders that check_repository may read, separated by ':' (';' on Windows). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Dated upstream breaks with tested fixes, from the CyberNative Breakage Calendar. Before upgrading, pinning or deploying a project, call check_repository (local folder) or check_dependencies / check_files, then show the user each date, what breaks and the fix link. list_upcoming_breaks and get_break read the calendar itself.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_dependenciesA | 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. |
| check_filesA | 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. |
| check_repositoryA | 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. |
| list_upcoming_breaksA | 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. |
| get_breakA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.