Which integrations are available for this server?

Fetches release notes from GitHub releases when a package has no changelog file or when the changelog only covers the newest major version. Provides release notes and changelog data for npm packages, including breaking changes, removals, deprecations, security fixes, and raised requirements between versions. Provides release notes and changelog data for NuGet packages, including breaking changes, removals, deprecations, security fixes, and raised requirements between versions. Provides release notes and changelog data for Packagist packages, including breaking changes, removals, deprecations, security fixes, and raised requirements between versions. Provides release notes and changelog data for PyPI packages, including breaking changes, removals, deprecations, security fixes, and raised requirements between versions. Provides release notes and changelog data for RubyGems packages, including breaking changes, removals, deprecations, security fixes, and raised requirements between versions.

How do I use release-notes?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@release-notes What breaks if I upgrade express from 4.21.2 to 5.0.0?" 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.

release-notes

by arhancanli

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Release Notes

npm downloads OpenSSF Scorecard License: MIT

What breaks if I upgrade? Coding agents answer upgrade questions from memory, and memory is where "express 5 removed req.param() in 5.0.0" (it was 5.0.0-alpha.2) and "requests 2.32 is a drop-in update" (it dropped Python 3.7) come from. Release Notes answers from the package's own changelog:

Before an upgrade, changes_between lists the breaking changes, removals, deprecations, security fixes and raised requirements (Node.js, Python...) between two versions, each tagged with its version, and says which major versions you cross. Pre-release notes count toward the release they lead to, which is where most breaking changes are written down.
When did it change? search_changelog finds every version whose notes mention an API or option, oldest first, with the section it was listed under ("remove", "deprecations").
One version's notes, cleaned of commit hashes and pull-request noise.

Notes come from the CHANGELOG file (a monorepo package's own first; Markdown, underlined and reStructuredText formats), or from GitHub releases when there is no file, or the file covers only the newest major. npm, PyPI, crates.io, Go, Maven and NuGet. No key needed; a GITHUB_TOKEN raises GitHub's limit of 60 anonymous API requests an hour.

Built and maintained by Arhan Canli.

Install

Install in Cursor Install in VS Code Install in Goose

Needs Node.js 20 or newer. No account or key.

Claude Code

claude mcp add release-notes -- npx -y release-notes-mcp

Claude Desktop: download release-notes-mcp-<version>.mcpb from the latest release and open it. The bundle is signed; verify it with gh attestation verify <file> --repo arhancanli/release-notes-mcp.

Any other client (Windsurf, Zed, Cline, Continue and others), in its MCP config file:

{
  "mcpServers": {
    "release-notes": {
      "command": "npx",
      "args": [
        "-y",
        "release-notes-mcp"
      ]
    }
  }
}

Docker

docker build -t release-notes-mcp https://github.com/arhancanli/release-notes-mcp.git && docker run -i --rm release-notes-mcp

Hosted (Streamable HTTP): node src/server.mjs --http serves stateless MCP at POST /mcp (port from PORT, default 3000).

Related MCP server: Modelmeter

Example

An agent calls changes_between with:

{
  "ecosystem": "npm",
  "package": "express",
  "from": "4.21.2",
  "to": "5.0.0"
}

and gets back (recorded from the live server on 2026-09-26):

{
  "versions": 5,
  "major_upgrades": [
    "5.x"
  ],
  "from_date": "2024-12-05",
  "to_date": "2024-09-10",
  "breaking": [
    "5.0.0: `res.status()` accepts only integers, and input must be greater than 99 and less than 1000",
    "5.0.0: will throw a `RangeError: Invalid status code: ${code}. Status code must be greater than 99 and less than 1000.` for inputs outside this range",
    "5.0.0: will throw a `TypeError: Invalid status code: ${code}. Status code must be an integer.` for non integer inputs"
  ],
  "removed": [
    "5.0.0: `path-is-absolute` dependency - use `path.isAbsolute` instead",
    "5.0.0-beta.1: Named matching groups no longer available by position in `req.params`",
    "5.0.0-beta.1: Remove `debug` dependency",
    "5.0.0-beta.1: Remove `hidden` option; use `dotfiles` option instead",
    "5.0.0-beta.1: Remove `express.static.mime` export; use `mime-types` package instead",
    "5.0.0-alpha.7: `path-to-regexp` dependency",
    "5.0.0-alpha.7: Remove `DEBUG_FD` environment variable support",
    "5.0.0-alpha.6: `res.redirect(url, status)` signature - use `res.redirect(status, url)`",
    "5.0.0-alpha.6: `res.send(status, body)` signature - use `res.status(status).send(body)`",
    "5.0.0-alpha.4: Remove Express 3.x middleware error stubs",
    "5.0.0-alpha.3: `res.json(status, obj)` signature - use `res.status(status).json(obj)`",
    "5.0.0-alpha.3: `res.jsonp(status, obj)` signature - use `res.status(status).jsonp(obj)`",
    "5.0.0-alpha.3: `res.vary()` (no arguments) -- provide a field name as an argument",
    "5.0.0-alpha.2: `app.param(fn)`",
    "5.0.0-alpha.2: `req.param()` -- use `req.params`, `req.body`, or `req.query` instead",
    "5.0.0-alpha.1: `app.del` - use `app.delete`",
    "5.0.0-alpha.1: `req.acceptsCharset` - use `req.acceptsCharsets`",
    "5.0.0-alpha.1: `req.acceptsEncoding` - use `req.acceptsEncodings`",
    "5.0.0-alpha.1: `req.acceptsLanguage` - use `req.acceptsLanguages`",
    "5.0.0-alpha.1: `res.json(obj, status)` signature - use `res.json(status, obj)`",
    "5.0.0-alpha.1: `res.jsonp(obj, status)` signature - use `res.jsonp(status, obj)`",
    "5.0.0-alpha.1: `res.send(body, status)` signature - use `res.send(status, body)`",
    "5.0.0-alpha.1: `res.send(status)` signature - use `res.sendStatus(status)`",
    "5.0.0-alpha.1: `res.sendfile` - use `res.sendFile` instead",
    "5.0.0-alpha.1: `express.query` middleware"
  ],
  "requirements": [
    "5.0.0-beta.1: Requires Node.js 4+"
  ],
  "source": "https://github.com/expressjs/express/blob/HEAD/History.md",
  "without_notes": "4.22.0, 4.22.1, 4.22.2, 4.22.3",
  "package": "express",
  "from": "4.21.2",
  "to": "5.0.0"
}

Tools

Tool	What it does
`changes_between`	Before an upgrade: breaking changes, removals, deprecations, security fixes and raised requirements (Node, Python...) between two versions of a package, from its changelog or GitHub releases, each tagged with its version. to defaults to the latest.
`release_notes`	The release notes of one version of a package (default the latest) from its changelog or GitHub release, with the release date and link. Short lines, commit and pull-request noise removed.
`search_changelog`	Finds the versions whose release notes mention a term (an API name, an option, 'deprecated', a CVE): each matching line with its version and date, oldest first, so you can see when something was added, deprecated or removed.

How it behaves

Read-only: no tool changes anything outside this process. Package names go to deps.dev, the npm registry and GitHub; nothing about your project is sent.
Network: HTTPS only, to the hosts listed in package.json under factory.allowHosts, with a deadline, a size cap and bounded retries. Nothing else is contacted, and nothing is logged except unexpected failures (to stderr, without your inputs).
Changelogs and release lists are cached for 30 minutes.
Classification is by the notes' own words and section labels. A change a project did not write down as breaking is not flagged; major_upgrades names the major versions crossed regardless.
Results are compact JSON with a matching output schema. Lists say how many items were left out.

Benchmark

Measured 2026-09-26 with gpt-5.4-mini, 9 fixed tasks graded by fixed checks (bench/tasks.json, raw results in bench/results/).

Server	Correct	Input tokens	Output tokens	Tool calls	Median time
This server	9/9	18046	675	16	4.8 s
mcp-server-fetch reading changelogs (no changelog server exists; this is what agents use today)	6/9	145935	1792	42	11.4 s

Performance

Measured 2026-09-26 from Dubai, home connection against the live upstream, Node 24.19.0 (bench/perf.json, scripts/perf.mjs in the factory).

Call	First call	Repeat	Result size
changes_between: express 4.21.2 to 5.0.0 (History.md)	1973 ms	1.6 ms	2,465 chars
changes_between: requests 2.31.0 to 2.32.3 (HISTORY.md)	2337 ms	0.9 ms	1,652 chars
changes_between: serde 1.0.150 to 1.0.200 (GitHub releases)	4497 ms	1.3 ms	253 chars
search_changelog: express, req.param	1756 ms	5.3 ms	650 chars
release_notes: react 18.0.0	3603 ms	8.1 ms	1,673 chars
search_changelog: react, useId	3533 ms	13.4 ms	1,209 chars

First call: a fresh server process, including the TLS connection and the upstream's own time. Repeat: the same call again, answered from the in-process cache, so it shows this server's own overhead.

Tool definitions the model reads on every turn (name, description, input schema): 1,792 characters, against 1,105 for mcp-server-fetch reading changelogs (no changelog server exists; this is what agents use today). The full tool list, with the output schemas and annotations clients use to validate results, is 2,732 characters (1,104 for the alternative).

Data sources

deps.dev (Open Source Insights) for versions, publish dates and repositories, and the npm registry for monorepo directories.
The package's GitHub repository: its CHANGELOG file and GitHub releases.

More MCP servers by Arhan Canli

Actions Check: Checks GitHub Actions workflows: outdated actions, old Node runtimes, retired runners, injection.
Cron Check: Explains cron expressions, lists next run times in any time zone, converts between cron dialects.
Domain Health: Email and domain checks: SPF lookup limits, DKIM keys, DMARC, DNS records, registration expiry.
End of Life: Is this version still supported? EOL dates, latest patch and upgrade target for 470+ products.
Internet Standards: RFC sections, status, obsoleted-by chains, errata and IANA registries for coding agents.
License Check: Open source license answers: SPDX ids, copyleft, and whether a dependency's license fits yours.
Package Truth: Checks packages exist before install: version, deprecation, vulnerabilities, licence. 7 ecosystems.
Citation Check: Verifies citations: finds fabricated or mismatched references and retractions, returns clean BibTeX.
The whole collection, 7 more

License

Available Tools

3 tools

changes_betweenWhat changed between two versionsA

Read-onlyIdempotent

Before an upgrade: breaking changes, removals, deprecations, security fixes and raised requirements (Node, Python...) between two versions of a package, from its changelog or GitHub releases, each tagged with its version. to defaults to the latest.

ParametersJSON Schema

Name	Required	Description
`to`	No
`from`	Yes	current version
`package`	Yes
`ecosystem`	Yes	npm, pypi, cargo, go, maven, nuget
`prereleases`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	Yes
`from`	Yes
`package`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds behavioral context by specifying the data source ('from its changelog or GitHub releases') and the output format ('each tagged with its version'), which is not present in annotations. It also imparts the constraint that 'to defaults to the latest,' which is a subtle but important behavior for parameter handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, putting the purpose ('Before an upgrade') first, which immediately signals when to use the tool. Every sentence earns its place: the first clarifies the use case and content, the second adds the version tags and default behavior. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, output schema present, and multiple sibling tools), the description is largely complete. It covers the main purpose, the parameters' roles (from, to, defaults), and the output structure. However, it lacks explicit guidance on the 'prereleases' parameter and does not elaborate on the output schema's structure beyond mentioning tags, which could be inferred. Despite these minor gaps, the description is sufficient for an agent to make a correct call in most scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 40%, and only ecosystem and from have descriptions in the schema. The description adds context for 'to' by stating it defaults to latest, and clarifies the meaning of 'from' as the current version, which partially compensates for the low schema coverage. However, it does not explain the 'prereleases' parameter or the 'package' parameter beyond the schema's basic type, leaving room for ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to list breaking changes, removals, deprecations, security fixes, and raised requirements between two versions of a package. It specifies the resource (package) and the scope (between two versions), and the mention of 'changelog or GitHub releases' differentiates it from simply listing raw release notes. This distinguishes it from siblings like release_notes and search_changelog, which likely focus on a single version or searching within changelogs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description opens with 'Before an upgrade,' which sets a clear context for when to use this tool: when planning an upgrade. It explicitly lists the types of changes covered, which helps clarify what information the tool provides. However, it does not explicitly state when NOT to use this tool or name alternative tools, leaving the agent to infer that release_notes or search_changelog might be used for other purposes, such as viewing full release notes or searching for specific terms.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

release_notesNotes for one versionA

Read-onlyIdempotent

The release notes of one version of a package (default the latest) from its changelog or GitHub release, with the release date and link. Short lines, commit and pull-request noise removed.

ParametersJSON Schema

Name	Required	Description
`package`	Yes
`version`	No
`ecosystem`	Yes	npm, pypi, cargo, go, maven, nuget
`max_chars`	No	default 6000

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`package`	Yes
`version`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: the source is a changelog or GitHub release, the version defaults to latest, and output includes the release date and link while filtering out commit/PR noise. This goes beyond what annotations state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with no filler. The core behavior is stated first (one version, default latest), followed by sources and output characteristics, and then the filtering detail. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with a rich output schema and safety annotations, the description is sufficient: it names inputs implicitly, clarifies defaults, and describes return content. The only notable gap is the lack of explicit usage guidance versus sibling tools, which was already penalized under usage guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema-level descriptions cover ecosystem and max_chars, but package and version have none. The description partially compensates by clarifying that the tool fetches notes for 'a package' and 'one version', making those parameters understandable. It doesn't add much detail for max_chars or ecosystem, so it only partially fills the 50% coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action: retrieving release notes for one version of a package, with the default being the latest. The phrase 'one version' clearly distinguishes this tool from the sibling tools changes_between and search_changelog, which obviously cover diffs or search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for a single version's notes via 'one version' and 'default the latest', giving clear context. However, it never explicitly names the sibling tools or explains when to use those instead, so the agent is left to infer the routing logic.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_changelogFind when something changedA

Read-onlyIdempotent

Finds the versions whose release notes mention a term (an API name, an option, 'deprecated', a CVE): each matching line with its version and date, oldest first, so you can see when something was added, deprecated or removed.

ParametersJSON Schema

Name	Required	Description
`text`	Yes
`package`	Yes
`ecosystem`	Yes	npm, pypi, cargo, go, maven, nuget

Output Schema

ParametersJSON Schema

Name	Required	Description
`hits`	Yes
`total`	Yes
`package`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, safe, idempotent behavior. The description adds useful behavioral details beyond annotations: results include each matching line with version and date, ordered oldest first. No contradiction with the annotations is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that front-loads the core purpose, then efficiently adds matching behavior, output shape, ordering, and representative search terms. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations and the existence of an output schema, the description covers the essential information an agent needs: what is searched, what the output looks like, and the ordering. Minor gaps such as empty-result behavior or case sensitivity are not critical enough to lower the score further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, so the description must compensate. It clarifies that 'text' is a search term with examples like API name, option, 'deprecated', or CVE, but it does not explain the 'package' and 'ecosystem' parameters beyond what their names and the schema's ecosystem enum already convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Finds') and resource ('versions whose release notes mention a term'), making the tool's function immediately clear. It also adds concrete examples and output details that distinguish it from sibling tools like changes_between and release_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a clear use case: search release notes by term to see when something was added, deprecated, or removed. However, it does not explicitly state when to prefer this tool over changes_between or release_notes, nor does it mention exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Sep 26, 2026
- First observedchanges_between
- First observedrelease_notes
- First observedsearch_changelog

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-26 17:50 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: changes_between compares two versions, release_notes fetches a single version's notes, and search_changelog finds versions by term. There is no meaningful overlap or ambiguity in their intended use.

Naming Consistency3/5

All names use lowercase snake_case, but the pattern is mixed: changes_between and release_notes are noun phrases while search_changelog is verb-first. The naming is readable and predictable enough, but it does not follow a single consistent verb_noun convention.

Tool Count5/5

Three tools is a well-scoped set for a release-notes domain. Each tool covers a distinct and essential operation without redundancy or unnecessary bloat.

Completeness5/5

The surface covers the core workflows: retrieving notes for a version, comparing versions for upgrade impact, and searching across versions. There are no obvious dead ends or missing operations for this read-only domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

FactReason A
io.github.factreason
Check exact npm/PyPI upgrades for evidence-backed breaking changes; query APIs and components.
Developer Tools Code Analysis AI & Machine Learning
111
What's New A
fyi.whatsnew
Changelogs for apps, games and operating systems. Ask what shipped since the version you run.
Search Documentation Access
51
ShipstarOAuth
ai.shipstar
Generate changelogs, release emails, help-center articles, banners, and social posts from commits.
Developer Tools CI/CD & DevOps Marketing
1
Releases A
sh.releases
An agent-friendly API for product changelogs. A unified registry via CLI, API, or MCP.
Product Management Developer Tools Documentation Access
1827

Related MCP Servers

breaking-changes-mcp
Developer Tools Coding Agents Documentation Access
Anicodeth
A
license
A
quality
C
maintenance
Provides accurate, source-grounded breaking-change briefings for npm packages by reading real GitHub release notes and CHANGELOGs, helping coding agents avoid hallucinated dependency migrations.
Updated 2 months ago (2026-07-13 11:11 UTC)
3
3 npm
MIT
Modelmeterofficial
AI & Machine Learning Developer Tools
modelmeters
A
license
Not graded
quality
C
maintenance
Enables AI agents to query model pricing, deprecations, and cost estimates via a machine-readable changelog of the AI stack.
Updated a month ago (2026-08-14 18:00 UTC)
1
MIT
driftwatch-mcp
Developer Tools Code Analysis
dhughes6071
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.
Updated 16 days ago (2026-09-11 00:44 UTC)
MIT
@octri/mcp
Documentation Access Developer Tools
OctriDev
A
license
A
quality
B
maintenance
Enables AI assistants to search API documentation, retrieve endpoint details, get SDK snippets, and check changelogs from an OpenAPI spec.
Updated 2 days ago (2026-09-25 17:19 UTC)
7
179 npm
MIT

Release Notes

Install

Example

Tools

How it behaves

Benchmark

Performance

Data sources

More MCP servers by Arhan Canli

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

breaking-changes-mcp

Modelmeterofficial

driftwatch-mcp

@octri/mcp