github-fetcher

GitHub releases

github_releases

Read-onlyIdempotent

List GitHub repository releases in reverse chronological order with tags, names, prerelease/draft flags, and dates; omit note bodies to keep responses small.

Instructions

List releases newest first with tag, name, prerelease/draft flags, and dates. Release note bodies are omitted to keep responses small; use github_release for a single release's notes. With include_prereleases=false the page is filtered client-side, so has_more reflects the unfiltered Link header.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>"
    },
    "name": "github_releases"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number, starting at 1
`repo`	Yes	Repository in owner/name form
`fresh`	No	Bypass the local cache
`per_page`	No	Items per page, default 20
`include_prereleases`	No	Include prerelease and draft releases, default true

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely non-obvious behavior: note bodies are dropped to keep responses small, and include_prereleases=false applies a client-side filter so has_more reflects the unfiltered Link header. That pagination caveat is exactly the kind of trap an agent would otherwise fall into.

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 tight clauses: what it returns, what it omits plus the alternative, then the pagination gotcha. The most consequential information (missing bodies, filtered has_more) is front-loaded and nothing is padded.

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 usefully sketches the returned fields and the notable omission, plus the pagination semantics. Caching (fresh) and page-size behavior are left to the schema, which documents them adequately.

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 coverage is 100%, so the baseline is 3; the description earns above that by explaining what include_prereleases=false actually does (client-side filtering with misaligned has_more) rather than restating the schema. It leaves fresh/cache behavior and per_page entirely to 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 opens with a specific verb and resource ('List releases newest first') and enumerates the fields returned (tag, name, prerelease/draft flags, dates). It explicitly distinguishes itself from the singular sibling github_release, so an agent can tell the two apart without reading either schema.

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?

It gives explicit routing advice: use github_release when a single release's notes are needed, because bodies are omitted here. That is clear context for the main ambiguity, though it doesn't address other alternatives (e.g. commits, tags) or when to use this tool at all versus searching.

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