release-notes-mcp

get_latest_version

Get the published release version for a GitHub repository by name. Provides release details for assembling product release notes.

Instructions

Get the latest published release for one repo.

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": "get_latest_version"
  }
}

Input Schema

Name	Required	Description	Default
`repo`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states the core behavior (returns the latest published release) but does not disclose repo format expectations, error handling, or whether drafts/prereleases are excluded. Minimal disclosure beyond the obvious operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that earns its place by stating the tool's action, resource, and scope. No wasted words, though it could benefit from a bit more detail without becoming verbose.

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?

An output schema exists, so return values are presumably defined there. The operation is simple with one parameter, but the description leaves a gap around the repo parameter's format. Overall adequate for a basic get tool but not fully complete.

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

Parameters2/5

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

The schema has one parameter 'repo' with 0% description coverage, and the description only adds 'for one repo'. It does not clarify the expected format (e.g., 'owner/repo') or any constraints, leaving the parameter semantics largely undocumented.

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 uses a specific verb 'Get' with a precise resource 'latest published release' and scope 'for one repo'. It clearly distinguishes from sibling tools like list_releases (all releases) and get_release (a specific release).

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?

Context implies the tool is for fetching the most recent release for a single repo, but it does not explicitly say when to use it over get_release or list_releases, nor does it mention alternatives. No exclusions or applicable scenarios are given.

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

Deploy Server