Skip to main content
Glama

Coderbuds

by com.coderbuds
OverviewDiscussionsAdmin

Get Open Pull Requests Tool

get-open-pull-requests-tool
Read-onlyIdempotent

List the team's open pull requests grouped by author, with the signal that shows what is blocking each one: whether it is awaiting a reviewer, has changes requested, is approved and ready to merge, is still a draft, is failing CI checks, or is simply too large for anyone to review. Optionally scope to specific "owner/name" repositories (e.g. patchstack/hub). Use this to nudge people to merge — lead with the headline. Human authors include their oldest open PRs with age; bot authors (dependabot etc.) are collapsed into count-only summaries so a dependency backlog cannot drown out the PRs a person should act on.

total_oversized and the per-PR oversized flag mark pull requests past the hard review limits — over 100 files, over 5,000 added or deleted lines, or over 8,000 changed in total. These are the ones a reviewer cannot pick up at all, so they are named in the headline and sorted to the front of their author's list. Report them as blocked on being split, not as blocked on a reviewer. The threshold is deliberately the hard limit rather than the team's line target: an open PR gives no file list, so the test/docs discount assess-change-fit applies to a numstat cannot be applied here, and judging against the target would flag changes that check would have passed. size.category is unknown when the counts were never recorded — that is missing data, not a small pull request; do not describe it as small.

Set include_bot_details when you are working the dependency queue itself — merging dependabot PRs, chasing failing bumps — and each bot author gains the PR numbers, repositories, titles and URLs you need to act, ordered by what can be closed out first: ready to merge, then failing checks, then oldest.

Check status_freshness before quoting counts: it flags open PRs whose local status may be stale, and repositories that have not synced pull requests recently — whose PRs may be missing from these counts altogether. Archived (decommissioned) repositories are excluded — this is a review queue, and their PRs are nobody's to review.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repositoriesNoOptional list of "owner/name" repository slugs to scope to (e.g. ["patchstack/hub", "patchstack/saas"]). Omit to include every active repository on the team.
include_bot_detailsNoInclude the individual PRs for bot authors (dependabot etc.) instead of counts alone — numbers, repositories, titles and URLs, ordered ready-to-merge first, then failing checks, then oldest. Set this when you are working the dependency queue itself; leave it off when summarising a review queue for people.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
botsYesPer bot author: total, awaiting_review, ready_to_merge, failing_checks — plus pull_requests (capped, actionable first) and more_not_shown when include_bot_details was set.
teamYesTeam name.
authorsYesPer human author: totals plus awaiting_review, changes_requested, ready_to_merge, draft, failing_checks, oversized, their open PRs (capped, oversized first then oldest, each with opened_at/days_open, an oversized flag and a size block of additions/deletions/changed_files/category), and more_not_shown.
bot_openYesOpen PRs authored by bots (dependabot etc.).
headlineYesOne-line human/bot summary to lead with when relaying this result.
human_openYesOpen PRs authored by people.
total_openYesTotal open PRs across the included repositories, bots included.
repositoriesYesRepository slugs included in the result.
total_oversizedYesHuman-authored open PRs past the hard review limits (over 100 files, over 5,000 added or deleted lines, or over 8,000 changed). Blocked on being split, not on a reviewer.
status_freshnessYesHow wrong these counts could be, in both directions. possibly_stale counts open PRs with no status sync or activity in over 30 days (some may already be closed, so counts are an upper bound); repositories_awaiting_sync names active repositories whose PRs have not synced in that time (PRs there may be missing, so counts are a lower bound). note spells out whichever applies, and is null only when neither does.
total_awaiting_reviewYesTotal open PRs blocking on a reviewer, bots included.
unmatched_repositoriesYesRequested slugs that did not match an active team repository — either not tracked, or archived.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the readOnlyHint/idempotentHint annotations: bot authors are collapsed to counts while humans keep oldest PRs with age, archived repos are excluded, oversized PRs are sorted to front and framed as 'blocked on being split', size.category=unknown means missing data not small, and status_freshness flags stale/missing PRs. These are non-obvious behaviors an agent could not infer from structured fields.

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?

Purpose and the headline guidance are front-loaded, and the paragraphs are organized by concern (oversized rules, bot details, freshness). It is dense and somewhat long for a two-parameter read tool, but nearly every sentence carries actionable detail rather than filler.

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

Completeness5/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-shape explanation is unnecessary, and the description still ties its guidance to specific output fields (headline, total_oversized, size.category, status_freshness). Nothing an agent needs to call it correctly is missing.

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, but the description adds real value: it explains the rationale for repositories scoping (with owner/name example) and the ordering semantics behind include_bot_details (ready-to-merge, then failing checks, then oldest). This exceeds what the schema text alone conveys.

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?

States a specific verb+resource (list open pull requests grouped by author) plus the blocking signal it surfaces, and distinguishes itself from get-merged-pull-requests-tool by scope. An agent can route on this without opening the 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?

Explicitly scopes the tool's purpose ('use this to nudge people to merge — lead with the headline') and gives a clear condition for the include_bot_details switch (working the dependency queue vs summarising a review queue). It stops short of naming a sibling alternative for other query shapes, so it is strong but not textbook when/when-not.

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

All Coderbuds toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources