Provides release intelligence from GitHub repositories, enabling comparison of Git refs, retrieval of merged pull requests and linked issues, and generation of release summaries with commit, file, and contributor statistics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@release-intel-mcp Build release evidence for owner/repo between v1.4.0 and v1.5.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.
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
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: GitHub Releases MCP Server
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: 1The 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.
Tool | What it returns |
| Commits enriched with merged pull request metadata and linked issues |
| Merged pull requests grouped as breaking, feature, fix, docs, chore, dependency, release, or other |
| 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.
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.0Use --json when another tool will consume the report:
release-intel-report owner/repository v1.4.0 v1.5.0 --jsonAttach 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.
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 --httpThe 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-mcpConnect an HTTP client to http://localhost:3000/mcp.
npm install
npm test
npm run build
GITHUB_TOKEN=your_read_only_token node dist/index.jsRequirements: Node.js 18 or newer.
See CONTRIBUTING.md for the development workflow.
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.
Get all commits between two git refs enriched with associated PR metadata, author information, and linked issues. Uses the GitHub compare API.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base ref (tag, branch, or commit SHA), the older point | |
| head | Yes | Head ref (tag, branch, or commit SHA), the newer point | |
| repo | Yes | GitHub repository name | |
| owner | Yes | GitHub repository owner (user or organization) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says the tool 'gets' commits and uses the GitHub compare API; it does not mention pagination, rate limits, auth requirements, potential response size, or any other operational behavior beyond the implied read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the main operation front-loaded and no filler. The mention of the GitHub compare API is brief and serves as useful context without bloating the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required and fully documented parameters, the description plus schema covers the core invocation. It also states what the response contains semantically. However, with no output schema and no annotations, it leaves response shape, pagination, and error/limit behavior unspecified, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The schema already documents owner, repo, base, and head, including that base is the older point and head is the newer point. The description's phrase 'between two git refs' adds little semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action: get all commits between two git refs, and specifies the enrichment (PR metadata, author information, linked issues). It does not explicitly contrast with sibling tools like get_pull_requests_in_range or get_release_summary, but the commit-focused wording makes the distinction mostly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the sibling tools. It names the GitHub compare API but does not explain when an agent should prefer this over get_pull_requests_in_range or get_release_summary, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base ref (tag, branch, or commit SHA), the older point | |
| head | Yes | Head ref (tag, branch, or commit SHA), the newer point | |
| repo | Yes | GitHub repository name | |
| owner | Yes | GitHub repository owner (user or organization) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It specifies that only merged PRs are returned, lists included metadata (labels, linked issues, review counts, files changed), and explains label categorization. It does not mention auth, pagination, or error behavior, but for a retrieval tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The key action and scope are front-loaded, and the category list adds useful detail without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read/list tool with all parameters documented in the schema, the description adequately covers what the tool returns and how results are categorized. It does not describe return format or pagination, but it is sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds no parameter-specific details beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Get' and the precise resource ('all merged pull requests between two refs'). It differentiates from the siblings by emphasizing PRs with labels, metadata, and categorization, which is distinct from get_changes_between_refs and get_release_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need merged PRs between two refs, with the additional distinction that only merged PRs are included. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repository name | |
| owner | Yes | GitHub repository owner (user or organization) | |
| to_tag | Yes | The new release tag or HEAD (head / newer ref) | |
| from_tag | Yes | The previous release tag (base / older ref) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently describes behavior by listing what data the tool combines and clarifying that the output is a structured object intended for synthesis. It does not discuss side effects, rate limits, or edge cases, but 'Generate' and the aggregation wording sufficiently signal a read-only, non-destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the core purpose and then efficiently enumerates the combined data sources, giving the agent maximum signal per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by naming the output type and its major components. The four required parameters are fully covered by the schema. Some detail about output shape or edge cases is absent, but the description is complete enough for an agent to select and invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds only the 'range between two tags' framing, which reinforces from_tag and to_tag semantics but does not meaningfully expand on what the schema already documents for owner, repo, from_tag, or to_tag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Generate'), a specific resource ('structured release context object'), and the scope ('range between two tags'). It also lists concrete contents (commit data, PR metadata, linked issues, contributors, aggregate statistics), which clearly distinguishes it from sibling tools focused on individual data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ready for AI synthesis into release notes' gives a clear context for when to use the tool. It does not explicitly name sibling alternatives or state when not to use them, but the 'Combines...' clause implies that this is the aggregate choice when multiple data sources are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct deliverable: raw commits with PR enrichment, PR metadata with categorization, and a ready-to-use summary. Descriptions clearly differentiate the level of aggregation, so an agent should have no trouble selecting the right one.
All tools follow a consistent get_ prefix followed by a descriptive noun phrase (changes_between_refs, pull_requests_in_range, release_summary). The pattern is uniform and predictable.
With three tools, the surface is tightly scoped to the release-intel domain. Each tool serves a distinct purpose and none feel redundant or missing, making the count ideal for this focused use case.
The trio covers the complete workflow for release note generation: raw commit data, detailed PR information, and an aggregated summary with statistics and contributor lists. There are no obvious dead ends or missing operations within the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate and publish changelogs, blog posts, release emails, and social posts from your commits.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Summarize repository changes for a release
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/actions-marketplace-validations/barissozudogru_release-intel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
