Problem
For a release window, teams often have a known list of merged PR numbers. Building a structured changelog today requires opening each PR or scripting against REST/GraphQL outside MCP. Agents would benefit from one MCP call that returns normalized metadata for many PRs.
Proposed solution (v1)
Add a tool that accepts:
owner, repo
pull_numbers: array of integers (bounded)
Returns (exact fields up to maintainers), per PR, for example:
number, title, html_url
merged_at, merge_commit_sha (when available)
labels (at least name)
author login
Output: JSON suitable for templating Markdown release notes in the client (prose stays in the agent or human editor).
Explicit non-goals (v1):
- Full combined diff across PRs (too heavy); linking to each PR is enough.
- Guessing “what shipped in this release” without an explicit PR list—the caller provides the list.
Why this matters
- Release engineering + agents: “Here are the PRs we shipped” → one call → table/sections for notes, Slack, or tickets.
- Composes with
search_pull_requests / list_pull_requests: caller selects PRs, tool hydrates details.
Relationship to existing requests
Related issues
Acceptance criteria (suggestion)
Note
We are happy to prototype a PR if maintainers agree on v1 scope.
Problem
For a release window, teams often have a known list of merged PR numbers. Building a structured changelog today requires opening each PR or scripting against REST/GraphQL outside MCP. Agents would benefit from one MCP call that returns normalized metadata for many PRs.
Proposed solution (v1)
Add a tool that accepts:
owner,repopull_numbers: array of integers (bounded)Returns (exact fields up to maintainers), per PR, for example:
number,title,html_urlmerged_at,merge_commit_sha(when available)labels(at leastname)authorloginOutput: JSON suitable for templating Markdown release notes in the client (prose stays in the agent or human editor).
Explicit non-goals (v1):
Why this matters
search_pull_requests/list_pull_requests: caller selects PRs, tool hydrates details.Relationship to existing requests
Related issues
Acceptance criteria (suggestion)
Note
We are happy to prototype a PR if maintainers agree on v1 scope.