Skip to main content
Glama

release-intel-mcp

Build release context from repository evidence instead of a blank prompt. The server compares two Git refs and correlates commits, merged pull requests, linked issues, labels, changed files, and contributors into a structured release record.

Tool page · npm · Listed in the official MCP Registry

Start in one minute

Create a fine-grained GitHub token with read-only access to the repositories you want to inspect. Repository contents and pull requests are sufficient for the current tools. No write permission is needed.

{
  "mcpServers": {
    "release-intel": {
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "your_read_only_token"
      }
    }
  }
}

Then ask the client for a bounded range:

Use release-intel to build release evidence for owner/repository
from v1.4.0 to v1.5.0. Separate merged PRs from direct commits
and preserve links to the repository record.

The token stays in the local server process and is sent only to the GitHub API.

Related MCP server: MCP Releases Server

Proof on this repository

A verified run against the stable range v0.5.1...8a2f350 returned:

Repository:        barissozudogru/release-intel-mcp
Commits:           14
Merged PRs:        1
Files changed:     12
Lines added:       286
Lines deleted:     135
Contributors:      1

The response also includes commit SHAs, messages, authors, pull request categories, linked issues, and warnings when GitHub truncates or fails part of the evidence lookup.

If this saves you time, consider starring the repository. It helps other developers find it.

Tools

Tool

What it returns

get_changes_between_refs

Commits enriched with merged pull request metadata and linked issues

get_pull_requests_in_range

Merged pull requests grouped as breaking, feature, fix, docs, chore, dependency, release, or other

get_release_summary

A complete release evidence object with aggregate statistics and contributors

The categorization uses labels and conventional title signals. Repository labels, issue links, and pull request hygiene directly affect the result. The server provides evidence and structure; the final release narrative still needs review.

Release report command

The package includes a terminal command that produces Markdown by default:

GITHUB_TOKEN=your_read_only_token \
  npx --yes --package @barissozudogru/release-intel-mcp \
  release-intel-report owner/repository v1.4.0 v1.5.0

Use --json when another tool will consume the report:

release-intel-report owner/repository v1.4.0 v1.5.0 --json

GitHub Action

Attach the evidence report to the workflow summary before publishing a release:

name: Release evidence

on:
  workflow_dispatch:
    inputs:
      from_ref:
        required: true
      to_ref:
        required: true

jobs:
  evidence:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
    steps:
      - uses: barissozudogru/release-intel-mcp@v0.7.2
        with:
          from-ref: ${{ inputs.from_ref }}
          to-ref: ${{ inputs.to_ref }}
          token: ${{ secrets.GITHUB_TOKEN }}

This action reads repository data and writes Markdown to the job summary. It does not publish a release or modify repository content.

Client setup

Use the stdio configuration from the quickstart. The server entry is identical across these clients even when their config file locations differ.

Create .vscode/mcp.json:

{
  "servers": {
    "release-intel": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@barissozudogru/release-intel-mcp"],
      "env": {
        "GITHUB_TOKEN": "your_read_only_token"
      }
    }
  }
}
GITHUB_TOKEN=your_read_only_token \
  npx @barissozudogru/release-intel-mcp --http

The MCP endpoint is http://localhost:3000/mcp and the health endpoint is http://localhost:3000/health. Set PORT to change the port.

docker build -t release-intel-mcp .
docker run -p 3000:3000 \
  -e GITHUB_TOKEN=your_read_only_token \
  release-intel-mcp

Connect an HTTP client to http://localhost:3000/mcp.

Local development

npm install
npm test
npm run build
GITHUB_TOKEN=your_read_only_token node dist/index.js

Requirements: Node.js 18 or newer.

See CONTRIBUTING.md for the development workflow.

Security and limits

  • Use a fine-grained, read-only token restricted to the required repositories.

  • The server never needs permission to write releases, issues, or pull requests.

  • GitHub's compare endpoint limits very large ranges. The response reports truncation.

  • Unlinked direct commits remain visible but cannot inherit pull request metadata.

  • Release categories are evidence-backed heuristics, not editorial conclusions.

License

MIT

Available Tools

3 tools
get_changes_between_refsGet Changes Between RefsB

Get all commits between two git refs enriched with associated PR metadata, author information, and linked issues. Uses the GitHub compare API.

Inputs: base (required), head (required), repo (required), owner (required).

get_pull_requests_in_rangeGet Pull Requests in RangeA

Get all merged pull requests between two refs with full metadata including labels, linked issues, review counts, and files changed. PRs are categorized by label into: breaking, feature, fix, docs, chore, dependencies, other.

Inputs: base (required), head (required), repo (required), owner (required).

get_release_summaryGet Release SummaryA

Generate a structured release context object ready for AI synthesis into release notes. Combines commit data, PR metadata, linked issues, contributor list, and aggregate statistics for the range between two tags.

Inputs: repo (required), owner (required), to_tag (required), from_tag (required).

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 3 tools

    Disambiguation4/5

    The three tools are largely distinct: one fetches commits, one fetches PRs, and one combines both into a summary. However, get_changes_between_refs and get_pull_requests_in_range both retrieve PR-related data, which could cause slight confusion for an agent deciding between them. The descriptions provide enough clarity to mitigate overlap.

    Naming Consistency5/5

    All tool names follow a consistent 'get_' verb prefix followed by descriptive noun phrases in snake_case (changes_between_refs, pull_requests_in_range, release_summary). This pattern is predictable and aligns with common conventions.

    Tool Count4/5

    With only 3 tools, the server is lean but each tool serves a clear purpose in the release-intel workflow: retrieving commits, retrieving PRs, and generating a summary. The count is minimal yet sufficient for the stated domain, though it sits at the low end of the ideal range.

    Completeness3/5

    The server covers the core operations for generating release context: commits, PRs, and a combined summary. However, there is no tool to list available tags/refs, which would be a natural precursor to using the other tools, and no way to directly fetch issues outside of PRs. These gaps could require agents to work around them.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that provides GitHub release information through the Model Context Protocol. It features a tool to retrieve the latest stable release version of any specified GitHub repository.
      -
    • A
      license
      Not graded
      quality
      D
      maintenance
      A production-ready MCP server that provides AI assistants with comprehensive GitHub developer tooling including PR analysis, code review, changelog generation, dependency auditing, commit summarization, and refactoring suggestions.
      7 npm
      ISC