Allows agents to list and download GitHub release assets, including downloading one asset by name or several by glob pattern, with multi-mirror parallel ranged downloads and sha256 verification using GitHub's asset digest when available.
Click on "Deploy 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., "@gh-release-mcp Download the latest ripgrep release asset matching x86_64-pc-windows into ./downloads"
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.
An MCP server that lets an agent list and download GitHub release assets — with multi-mirror parallel ranged download and sha256 verification. Zero external binaries (pure Python standard library: no
aria2,curl,gh,jq). By embedai.com.cn.
Built for restricted networks: it probes which mirrors support HTTP Range (206), splits a file across mirrors and downloads segments in parallel, then verifies sha256 from GitHub's own asset digest.
Tool | What it does |
| List a release's assets (name, size, url). |
| Download one asset (by |
Related MCP server: github-mcp-connector
# run instantly (no install)
uvx gh-release-mcp
# or via pip
pip install gh-release-mcp
gh-release-mcpIt speaks MCP over stdio.
opencode (opencode.json):
{
"mcp": {
"gh-release": {
"type": "local",
"command": ["uvx", "gh-release-mcp"]
}
}
}Claude Desktop / Cursor (mcpServers):
{
"mcpServers": {
"gh-release": { "command": "uvx", "args": ["gh-release-mcp"] }
}
}download_release_asset arguments:
arg | meaning |
| e.g. |
| release tag; omit or |
| exact asset name (optional) |
| glob, e.g. |
| destination directory (default: cwd) |
| mirror prefixes (must support Range); default |
| segments per file (default 8) |
Env vars: GITHUB_TOKEN (optional, raises API limits / private repos).
"Using gh-release, list the assets of BurntSushi/ripgrep latest."
"Download NationalSecurityAgency/ghidra Ghidra_12.1.4_build matching *PUBLIC*.zip into ./ghidra."
CLI tool (no MCP): gh-download · PyPI gh-download-embedai
Blog: https://embedai.com.cn
MIT
Download release asset(s) with parallel ranged requests across mirrors. Pick one asset by exact name, or several via a glob pattern. Verifies sha256 when GitHub exposes a digest.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Release tag; omit or 'latest'. | |
| dest | No | Destination directory (default: current dir). | |
| name | No | Exact asset name (optional). | |
| repo | Yes | ||
| owner | Yes | ||
| mirrors | No | Mirror prefixes (must support HTTP Range). Default: ['https://ghproxy.net', 'https://ghfast.top'] | |
| pattern | No | Glob, e.g. '*PUBLIC*.zip' (optional). | |
| connections | No | Parallel segments per file (default 8). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses parallel ranged requests, mirror fallback across defaults, and sha256 verification when a digest exists. It omits overwrite behavior for existing files and auth requirements for private repos, which would matter for a mutating download.
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?
Three tight sentences, front-loaded with the action and mechanism, then the selection rule, then the integrity guarantee. No filler; every sentence informs.
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 an 8-parameter tool with no annotations and no output schema, the description adequately conveys mechanism, target selection, and verification. It leaves unaddressed where files land beyond the dest schema field and whether existing files are overwritten, but is otherwise self-sufficient.
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 75%, so the schema already documents tag, dest, mirrors, connections, and the name/pattern descriptors. The description adds genuine meaning by framing name and pattern as mutually exclusive alternatives (one asset vs several), beyond what the schema states individually. The undocumented owner/repo remain the gap.
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?
States a specific verb and resource (download release asset) and describes mechanism (parallel ranged requests across mirrors). It differs clearly from the sibling list_release_assets, which discovers assets rather than fetching them.
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?
Explains how to select targets (exact name vs glob pattern), which is useful, but never states when to use this tool versus list_release_assets or any prerequisites (e.g., discovering names first). Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the downloadable assets of a GitHub release (name, size, url).
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Release tag; omit or 'latest' for the latest release. | |
| repo | Yes | Repo name, e.g. ghidra | |
| owner | Yes | Repo owner, e.g. NationalSecurityAgency |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full behavioral burden; 'List' implies a read-only operation and the parenthetical discloses the returned fields, which is genuinely useful. However, it omits pagination behavior, auth/token requirements, rate limits, and what happens when the release or its assets do not exist.
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?
A single front-loaded sentence that identifies the resource and the return payload with zero filler. Nothing could be trimmed without losing information.
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?
The description partially compensates for the absent output schema by naming the returned fields, and parameters are fully covered by the schema. It is still thin for a GitHub API tool with no annotations, leaving auth requirements, pagination, and empty/error outcomes unaddressed.
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%, including the 'omit or latest' convention for tag, so the schema fully documents all three parameters. The description adds no parameter-level meaning beyond what the schema already provides, making the baseline 3 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?
States a specific verb ('List') and resource ('downloadable assets of a GitHub release') and names the returned fields (name, size, url). It is clearly distinguishable from the sibling download_release_asset by verb, though it never explicitly contrasts the two.
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 scenario is implied by 'of a GitHub release,' but there is no explicit when-to-use guidance, no prerequisites (e.g., needing a valid release tag), and no routing to or away from download_release_asset. An agent must infer the boundary between listing and downloading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0download_release_assetlist_release_assetsScored across 2 tools
The two tools have clearly distinct purposes: one lists metadata about assets, the other downloads asset content. An agent can easily tell which to invoke based on whether it needs information or the file itself.
Both names follow a clean verb_noun pattern (list_release_assets, download_release_asset) with consistent snake_case and a shared 'release_asset' subject. There is no stylistic deviation.
Two tools is very thin for a server named gh-release-mcp, which implies release management rather than just asset handling. The surface feels like a narrow slice of the domain rather than a complete toolkit.
The server covers listing and downloading release assets but omits core release lifecycle operations: listing releases, creating/deleting releases, and uploading assets. Agents needing anything beyond download will hit dead ends.
Manage repositories, users, releases, and automate GitHub workflows
Get share links, publish and manage websites, artifacts and agents. No account needed.
Source-first URL clone, capture, rebuild, and fidelity verification tools.
Your agents' cloud for individuals and teams. Search, execute, packages, jobs, and credentials.
