A small, generic MCP server for combining GitHub/GitLab/Gitea releases into product release notes
MCPpedia last refreshed this data
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"io-github-vaggeliskls-release-notes-mcp-2": {
"args": [
"release-notes-mcp"
],
"command": "uvx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
A small, generic MCP server that combines GitHub releases from several repositories into a single product release note. The server just fetches and bundles raw data; the LLM synthesizes the final notes.
Run this in your terminal to verify the server starts. Then let us know if it worked — your result helps other developers.
uvx 'release-notes-mcp' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
Checked release-notes-mcp against OSV.dev.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in other
Compress tool outputs, logs, files, and RAG chunks before they reach the LLM. 60-95% fewer tokens, same answers. Library, proxy, MCP server.
Pi Coding Agent extension (CLI-first) — routes bash/read/grep/find/ls through lean-ctx CLI for strong token savings. Optional MCP bridge can register advanced tools.
97% token reduction for AI coding sessions — zero deps, 21 languages, MCP server
One local source for the MCP servers, tools, and memory your AI coding agents share, synced into each tool's native config with a review gate and a receipt for every change. No daemon, no lock-in.
MCP Security Weekly
Get CVE alerts and security updates for io.github.vaggeliskls/release-notes-mcp and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
A small, generic MCP server that combines GitHub releases from several repositories into a single product release note. The server just fetches and bundles raw data; the LLM synthesizes the final notes.
Nothing is architecture-specific:
provider — which forge to read releases from: github (default),
gitlab, or gitea/Forgejo. Release fetching goes through a small adapter,
so adding a forge means normalizing its release JSON — a contained change.repos — the repos the server is allowed to read releases from.contextSources — arbitrary URLs loaded as background context (a style
guide, a versions file, feature names — anything). The server assigns no
meaning; what each source is is decided by what you put behind the URL.Config holds no secrets — only the repo set and context. Provider and auth come from the environment.
// config.json — non-sensitive (required; the server errors if it's missing)
{
"repos": [
"myorg/auth-service",
"myorg/web"
],
"contextSources": [
{
"name": "release-info",
"url": "https://example.github.io/whatever/release.json",
"description": "Extra context to consult when assembling release notes"
}
]
}
Environment (provider-agnostic, set in .env or your shell):
| Var | Purpose | Default |
|---|---|---|
TOKEN | Auth token for the provider — never in config | (empty; ok for public repos) |
PROVIDER | github | gitlab | gitea (overrides config) | github |
BASE_URL | API base — only for self-hosted GitLab / Gitea | provider default |
format on a context source is optional — auto-detected from
Content-Type / URL extension / content sniffing. Override only when wrong.The server only ever reads releases (GET /repos/{owner}/{repo}/releases…),
so give TOKEN the minimum read scope — never write access.
| Provider | Public repos | Private repos |
|---|---|---|
| GitHub — fine-grained PAT | no token needed | Contents: Read-only (releases live under Contents), for each repo you list |
| GitHub — classic PAT | no token needed (or public_repo) | repo scope |
| GitLab | no token needed | read_api scope |
| Gitea / Forgejo | no token needed | read:repository scope |
For GitHub, a fine-grained PAT scoped to just the repos in config.json with
Contents → Read-only is the tightest setup and is all this server requires.
The config (repos + contextSources) must come from one of two places — the server errors on startup if neither is set:
| Source | Use it for |
|---|---|
RELEASE_MCP_CONFIG_JSON | The config as inline JSON. No file needed — ideal for uvx / MCP hubs where everything is an env var. |
RELEASE_MCP_CONFIG | Path to a config.json file (default ./config.json). Used by the container, which mounts a real file. |
Inline JSON wins when both are set. Copy config.example.json to get started
with the file approach.
| Tool | Purpose |
|---|---|
list_repos() | The configured repos |
list_releases(repo, limit) | Recent releases for one repo |
get_latest_version(repo) | Newest release for one repo |
get_release(repo, tag) | Full notes for one tag |
compare_releases(repo, from_tag, to_tag) | All releases between two versions |
gather_release_notes(selections[]) | Bundle raw notes from N (repo, tag) pairs (concurrent) |
get_context(name?) | Load configured context URLs (auto-detected format) |
Selection is dynamic — you (or Claude) pass the (repo, tag) pairs to
combine. The server's instructions tell Claude to call get_context() first.
The server runs in a container over HTTP transport on localhost:8000.
First create the config and env files (both runs need them):