Which integrations are available for this server?

Provides tools for accessing, comparing, and analyzing GitHub repository releases, including fetching release details, comparing versions, and listing releases with filtering options.

How do I use GitHub Releases MCP Server?

1. Click on "Install 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., "@GitHub Releases MCP Server list releases for tailwindlabs/tailwindcss" 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.

GitHub Releases MCP Server

by SLineroDev

Overview Schema Related Servers Score Discussions

JavaScript

Remote

GitHub Releases MCP Server

A powerful Model Context Protocol (MCP) toolkit for GitHub releases management. This server provides comprehensive tools for accessing, comparing, and analyzing GitHub repository releases with rich formatting and detailed information.

Features

🔍 Detailed Release Information: Get comprehensive details about specific releases
📊 Version Comparison: Compare changes between any two versions
📋 Release Listing: Get formatted lists of releases with filtering options
🏷️ Semantic Version Support: Handles various version formats (v1.0.0, @1.0.0, 1.0.0)
🎯 Pre-release Filtering: Option to include or exclude pre-releases
📝 Rich Formatting: Emoji-enhanced output for better readability
🔄 Pagination Support: Handles repositories with many releases
🔒 Authentication: Optional GitHub token support for private repositories and extended rate limit

Related MCP server: GitHub MCP Server

Configuration

The server accepts the following optional environment variables:

GITHUB_PERSONAL_ACCESS_TOKEN: GitHub Personal Access Token (optional). If provided, it will be used to authenticate API requests, allowing for higher rate limits and access to private repositories.

Quick Start

You can run this MCP server using npx:

# Using environment variables
GITHUB_PERSONAL_ACCESS_TOKEN=your_token npx @slinerodev/github-releases-mcp

# Or using a .env file
echo "GITHUB_PERSONAL_ACCESS_TOKEN=your_token" > .env
npx @slinerodev/github-releases-mcp

Client Configuration

The server can be used with various MCP clients. Add the following configuration to your client's config file:

Cursor: ~/.cursor/mcp.json
VS Code: .vscode/settings.json (use mcp.servers instead of mcpServers)
Claude Desktop: claude_desktop_config.json
Windsurf: windsurf_config.json

Using Published Version

{
  "mcpServers": {
    "github-releases": {
      "command": "npx",
      "args": [
        "-y",
        "@slinerodev/github-releases-mcp"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"
      }
    }
  }
}

Using Local Development Version

{
  "mcpServers": {
    "github-releases": {
      "command": "npx",
      "args": [
        "-y",
        "tsx",
        "${workspaceRoot}/main.ts"
      ]
    }
  }
}

Note:

For VS Code, replace mcpServers with mcp.servers in the configuration.
Replace your_token_here with your GitHub Personal Access Token if you want to access private repositories or need higher rate limits.

Available Tools

The server provides three specialized tools for working with GitHub releases:

1. github_release_info

Get detailed information about a specific release version.

const result = await mcp.invoke("github_release_info", {
  owner: "owner-name",
  repo: "repo-name",
  version: "1.0.0" // Supports v1.0.0, @1.0.0, 1.0.0
});

Perfect for:

Understanding what changed in a specific version
Documentation purposes
Release note retrieval

2. github_releases_compare

Compare changes between two versions.

const result = await mcp.invoke("github_releases_compare", {
  owner: "owner-name",
  repo: "repo-name",
  fromVersion: "1.0.0",
  toVersion: "2.0.0"
});

Perfect for:

Generating changelogs
Understanding feature evolution
Migration guides
Breaking change analysis

3. github_releases_list

List all releases with filtering options.

const result = await mcp.invoke("github_releases_list", {
  owner: "owner-name",
  repo: "repo-name",
  limit: 10, // Optional: limit number of releases
  includePreReleases: false // Optional: include pre-releases
});

Perfect for:

Project release history overview
Finding latest versions
Release frequency monitoring
Pre-release tracking

Example Response Format

All tools return responses in a consistent, emoji-enhanced format:

🔖 v1.0.0 (First stable release)
🗓️ 2024-03-15T10:30:00Z
📝 This is the release description...

---

🔖 v0.9.0 (Beta) (Pre-release)
🗓️ 2024-03-01T08:15:00Z
📝 Beta version with new features...

Error Handling

The tools handle various error cases gracefully:

Invalid repository names
Non-existent versions
Invalid version formats
API rate limits
Network issues
Authentication errors

Each error returns a clear message explaining what went wrong.

Development

Install dependencies:
```
pnpm install
```
Run the server:
```
pnpm start
```

Contributing

Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

License

ISC

Author

Sergio Linero

Available Tools

5 tools

github_org_packagesA

List all packages for a GitHub organization. Returns detailed information about each package including its name, type, visibility, and repository details. Perfect for discovering available packages and their metadata in an organization.

ParametersJSON Schema

Name	Required	Description
`org`	Yes	The organization name
`visibility`	No	Filter packages by their visibility
`package_type`	No	The type of package to filter for (e.g. npm, maven, docker, container)

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, but description explains return data includes name, type, visibility, and repository details. However, it omits behavioral traits like pagination, sorting, or rate limits.

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 concise, front-loaded sentences with no filler. Every sentence adds value.

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?

Adequate for a straightforward list tool. Describes output details, but lacks pagination info. With no output schema, slightly more detail would help, but overall sufficient.

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 coverage is 100%, so description adds minimal param info. It does not elaborate on the meaning or constraints beyond what the schema provides.

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 'List all packages for a GitHub organization' with a specific verb and resource. It distinguishes well from sibling tools which focus on releases and repos.

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

Usage Guidelines2/5

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

No guidance on when to use this versus alternatives. Lacks context about when not to use or prerequisites.

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

github_release_infoA

Get detailed information about a specific GitHub release version. Supports semantic versioning formats (v1.0.0, @1.0.0, 1.0.0) and returns comprehensive release details including tag name, release title, publication date, and full release notes. Perfect for understanding what changed in a specific version or for documentation purposes.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner
`package`	No	Package name to filter releases for (e.g. 'astro', '@astrojs/vue'). If not provided, will match against all packages.
`version`	Yes	The specific version to get information about (supports formats: v1.0.0, @1.0.0, 1.0.0)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It lists return fields (tag name, title, date, release notes) implying read-only access. However, it does not explicitly state side-effect-free operation, error conditions, or rate limit considerations, which are important for a tool with no annotation safety net.

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?

Three sentences, all front-loaded: verb+resource in first, return fields in second, use case in third. No redundancy or filler. Every sentence adds value.

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?

With no output schema, the description adequately explains return fields (tag name, title, date, release notes). It covers the main aspects of a single-release lookup. Minor omissions: no mention of errors, status codes, or that the 'package' parameter is optional. Overall, reasonably complete for a simple info tool.

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 100%, so the baseline is 3. The description only reiterates version format support already present in the schema (e.g., 'v1.0.0, @1.0.0, 1.0.0'). It adds no new meaning beyond what the parameter descriptions 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 clearly states the tool's purpose: 'Get detailed information about a specific GitHub release version.' It includes the verb 'get' and the resource 'release version', and differentiates from siblings like github_releases_list (list all) and github_releases_compare (compare) by emphasizing 'specific'.

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 provides a use case ('Perfect for understanding what changed...'), but does not explicitly advise when not to use this tool or name alternatives. An agent would benefit from knowing to use github_releases_list for browsing or github_releases_compare for diffs.

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

github_releases_compareA

Compare changes between two GitHub release versions. Ideal for understanding what changed between versions, generating changelogs, or migration guides. Returns a chronological list of all releases between the two versions with their full release notes, making it perfect for analyzing the evolution of features, bug fixes, and breaking changes. Supports semantic versioning formats (v1.0.0, @1.0.0, 1.0.0).

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner
`package`	No	Package name to filter releases for (e.g. 'astro', '@astrojs/vue'). If not provided, will match against all packages.
`toVersion`	Yes	The target version to compare to (supports formats: v1.0.0, @1.0.0, 1.0.0)
`fromVersion`	Yes	The base version to compare from (supports formats: v1.0.0, @1.0.0, 1.0.0)

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description must disclose behavior. It states the output format and version format support, but does not cover error conditions, rate limits, or whether the range is inclusive/exclusive.

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 sentences, front-loaded with purpose, no fluff. Every sentence adds value.

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

Completeness3/5

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

Covers use case, output, and version formats but lacks details on error handling, pagination, or inclusivity of versions. With no output schema, more context could be beneficial.

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 coverage is 100% so parameters are well-documented. The description adds context on output and version formats but does not significantly expand on individual parameter meaning beyond the schema.

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 compares two GitHub release versions, specifies the output (chronological list with full release notes), and distinguishes it from siblings like github_release_info (single release) and github_releases_list (list all).

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 gives explicit use cases (changelogs, migration guides) and when it's ideal, but does not explicitly mention when not to use or provide alternatives beyond implicit differentiation.

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

github_releases_listA

List all GitHub releases for a repository with rich formatting and comprehensive details. Returns releases in chronological order with emojis for better readability (🔖 for versions, 🗓️ for dates, 📝 for descriptions). Perfect for getting an overview of a project's release history, finding the latest version, or monitoring release frequency. Supports pagination and filtering of pre-releases.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`limit`	No	Maximum number of releases to return (default: all)
`owner`	Yes	GitHub repository owner
`package`	No	Package name to filter releases for (e.g. 'astro', '@astrojs/vue'). If not provided, will match against all packages.
`includePreReleases`	No	Whether to include pre-releases in the results (default: false)

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It mentions read-only behavior implicitly (listing releases) and describes output formatting and pagination. However, it does not disclose authentication requirements, rate limits, or potential side effects, which are typical for a listing tool.

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 (a few sentences) and front-loaded with the main action. Every sentence adds value: purpose, key features, use cases. No unnecessary words.

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

Completeness3/5

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

Given 5 parameters and no output schema, the description covers main use cases but omits explanation of the 'package' parameter, which is present in the schema. It also doesn't explicitly state that 'owner' and 'repo' are required, though implied. This gap reduces completeness.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the 'rich formatting' (emojis) and the purpose of pagination and pre-release filtering, which reinforces but goes slightly beyond the schema details.

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 verb 'list' and resource 'releases' with a specific scope 'for a repository.' It highlights features like chronological order, emojis, pagination, and filtering, making it distinct from sibling tools like github_release_info (single release) and github_releases_compare (diff).

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 provides clear usage context: 'Perfect for getting an overview of a project's release history, finding the latest version, or monitoring release frequency.' However, it lacks explicit when-not-to-use guidance or direct alternatives, which would elevate it to a 5.

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

github_repo_readmeA

Fetch the README file for a GitHub repository and return its plain text content. Useful for discovering package names and documentation in monorepos.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses it returns plain text, but does not mention error cases (e.g., missing README) or rate limits. Adequate for a simple read tool.

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 sentences, front-loaded with action and value, no 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?

Simple tool with no output schema; description covers primary function and use case. Could mention error behavior but not critical.

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 coverage is 100%, so description adds no extra parameter details. Adds context about monorepo use but not beyond schema.

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?

Description uses specific verb 'Fetch' and resource 'README file for a GitHub repository', clearly distinguishes from siblings which deal with releases and packages.

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?

States it is useful for discovering package names and documentation in monorepos, providing clear context. Does not mention when not to use or alternative tools.

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. Dates show when Glama detected each change.

5 tool updatesv0.2.0Jul 30, 2026
- First observedgithub_org_packages
- First observedgithub_release_info
- First observedgithub_releases_compare
- First observedgithub_releases_list
- First observedgithub_repo_readme

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation2/5

The first three tools are clearly about GitHub releases, but the last two (github_org_packages and github_repo_readme) are for entirely different purposes, creating confusion about the server's scope. An agent could mistakenly use these unrelated tools when trying to perform release operations.

Naming Consistency2/5

The release tools follow a consistent 'github_release_*' pattern, but the other two tools break this pattern with 'github_org_packages' and 'github_repo_readme', leading to inconsistency in the naming scheme.

Tool Count3/5

With 5 tools, the count is reasonable, but the inclusion of two unrelated tools makes the set seem thin for a dedicated releases server. A releases-focused set would benefit from more release-specific operations.

Completeness2/5

The release tools cover info, compare, and list, but lack essential CRUD operations like create, update, or delete releases. Additionally, the org packages and README tools are unrelated and do not fill any obvious gaps in the release workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

github
com.mcparmory
Manage repositories, users, releases, and automate GitHub workflows
Version Control CI/CD & DevOps Developer Tools
2
smithery-ai-github
ai.smithery
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Version Control Developer Tools CI/CD & DevOps
295
ShipstarOAuth
ai.shipstar
Generate and publish changelogs, blog posts, release emails, and social posts from your commits.
Developer Tools CI/CD & DevOps Marketing
1
Open Source Intelligence MCP A
io.github.FoundryNet
GitHub project health, package dependency risk, trending repos, license & package comparison.
Version Control Code Analysis Security
2

Related MCP Servers

Release Notes MCP Server
Version Control Developer Tools
nickbaumann98
F
license
B
quality
D
maintenance
Generates comprehensive and formatted release notes from GitHub repositories, efficiently organizing commits by type and including detailed statistics using smart API usage.
Updated 2 years ago (2025-01-28 00:19 UTC)
3
3
-
GitHub MCP Server
Version Control Developer Tools
bugzy-ai
A
license
Not graded
quality
D
maintenance
Enables querying GitHub repositories for pull requests, commits, and comparisons to understand code changes.
Updated 8 months ago (2026-01-09 08:52 UTC)
15
Apache 2.0
GitHub Stats MCP Server
Version Control Developer Tools
6rz6
A
license
Not graded
quality
D
maintenance
Provides tools to access GitHub repository and user statistics, including repo info, user profiles, contributors, issues, and repository search.
Updated a year ago (2025-07-14 19:25 UTC)
MIT
release-announcer-mcp
Marketing Social Media Version Control
h-kazuki-pixel
A
license
A
quality
A
maintenance
Generates multi-platform release announcements (X, Reddit, GitHub profile, awesome-list, MCP directory) and a publish-readiness checklist for any public GitHub repository.
Updated a month ago (2026-08-07 22:52 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SLineroDev/github-releases-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server