Release Notes Mcp

io.github.vaggelisklsPublished by GitHub account vaggelisklsv1.0.1Updated Oct 24, 2026

A small, generic MCP server for combining GitHub/GitLab/Gitea releases into product release notes

VerifiedSTDIODesktop onlyProductivity & WorkflowDeveloper Tools

Overview

AI-generated overview

A local MCP server that reads GitHub, GitLab or Gitea releases and combines them into product release notes.

What you can do
Read releases from GitHub, GitLab or Gitea repositories configured for the session, using a provider setting that defaults to GitHub and an optional base URL for self-hosted instances. Combine releases from several configured repositories into product release notes. Pull in extra context from configured context sources alongside the release data. Repository and context-source configuration is supplied either as an inline JSON value or as a path to a config file.
When to use it
Useful when you keep release notes for a product spread across several repositories on GitHub, GitLab or Gitea and want an assistant to gather the releases and draft combined notes, including on self-hosted forges.
Requirements
Runs locally as a Python package launched with uvx over stdio. Requires either the RELEASE_MCP_CONFIG_JSON inline JSON or the RELEASE_MCP_CONFIG absolute path to a config file, listing repositories and context sources. The PROVIDER variable selects github, gitlab or gitea (default github); BASE_URL is needed only for self-hosted GitLab or Gitea. A TOKEN is optional for public repositories. Network access to the forge is required.
Before you install
The TOKEN secret is a GitHub personal access token or GitLab/Gitea token; scope it narrowly and prefer read-only access, since it is optional for public repositories. Configuration is passed through environment variables, so avoid exposing repository lists or tokens in shared shell history or logs. The server reads release data from third-party forges.

Installation

In SourceWeft

  1. Open Release Notes Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

release-notes-mcp

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.

Configuration

Config holds no secrets — only the repo set and context. Provider and auth come from the environment.

jsonc
// 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):

VarPurposeDefault
TOKENAuth token for the provider — never in config(empty; ok for public repos)
PROVIDERgithub | gitlab | gitea (overrides config)github
BASE_URLAPI base — only for self-hosted GitLab / Giteaprovider default
  • format on a context source is optional — auto-detected from Content-Type / URL extension / content sniffing. Override only when wrong.

Token permissions

The server only ever reads releases (GET /repos/{owner}/{repo}/releases…), so give TOKEN the minimum read scope — never write access.

ProviderPublic reposPrivate repos
GitHub — fine-grained PATno token neededContents: Read-only (releases live under Contents), for each repo you list
GitHub — classic PATno token needed (or public_repo)repo scope
GitLabno token neededread_api scope
Gitea / Forgejono token neededread: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:

SourceUse it for
RELEASE_MCP_CONFIG_JSONThe config as inline JSON. No file needed — ideal for uvx / MCP hubs where everything is an env var.
RELEASE_MCP_CONFIGPath 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.

Tools

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

Run

The server runs in a container over HTTP transport on localhost:8000. First create the config and env files (both runs need them):

bash
cp config.example.json config.json   # edit repos + contextSources (no secrets)cp .env.example .env                  # set TOKEN (+ PROVIDER / BASE_URL if needed)

Normal run

bash
docker compose up -d

Local development — docker compose watch

For local dev, docker compose watch keeps the server live while you edit:

bash
docker compose watch
ChangeAction
server.pysync + restart — copied into the container, process restarts
requirements.txt, Dockerfilerebuild — image is rebuilt automatically
config.jsonbind-mounted (live); run docker compose restart to reload it

Run with uvx (no clone, no container)

The server is published to PyPI, so a client can launch it on demand with uvx — no checkout and no Docker:

bash
uvx release-notes-mcp

uvx talks to the server over stdio (the default transport). Since there's no file to mount, pass the config inline as JSON via RELEASE_MCP_CONFIG_JSON (everything is env-only — ideal for MCP hubs):

bash
RELEASE_MCP_CONFIG_JSON='{"repos":["myorg/web"],"contextSources":[]}' \  TOKEN=ghp_... uvx release-notes-mcp

Prefer a file? Point RELEASE_MCP_CONFIG at an absolute path instead (uvx runs from an unknown working directory, so a relative path won't resolve):

bash
RELEASE_MCP_CONFIG=/abs/path/config.json TOKEN=ghp_... uvx release-notes-mcp

Register with Claude Code

HTTP (container) — point Claude Code at the running server by its URL:

bash
claude mcp add --transport http release-notes http://localhost:8000/mcp

stdio (uvx) — let Claude Code launch the server as a subprocess:

bash
claude mcp add release-notes \  --env RELEASE_MCP_CONFIG=/abs/path/config.json \  --env TOKEN=ghp_... \  -- uvx release-notes-mcp

Then ask Claude: "Combine the latest releases of auth-service and web into a product release note."

Source: README.md at commit 09fa6c5

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v1.0.1LatestSep 16, 2026

Score

40% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

    Declare a license in the repository or the registry entry.