Skip to main content
Glama

Get open pull requests

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

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

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.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: grouping by author, bot authors collapsed by default, oversized PR thresholds and handling, status_freshness caveats, and exclusion of archived repositories. This is exactly the kind of operational detail an agent needs to interpret results correctly.

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?

The description is long but front-loaded: it begins with the core purpose and blocking signals before expanding into oversized PRs, bot handling, and freshness. Some sentences are dense and could be tightened, but every section contributes useful behavioral context. The structure supports scanning, though it is more verbose than strictly necessary.

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?

The tool is complex (author grouping, blocking signals, bot collapsing, oversized flags, freshness, archived exclusion), and the description covers all of these behavioral nuances. An output schema exists so return values need not be explained. With annotations covering safety and schema covering parameters, the description completes the picture for correct interpretation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both parameters, including detailed guidance for include_bot_details. The description repeats the same information about repositories scoping and include_bot_details without adding meaning beyond the schema (e.g., the ordering for bot details is already in the schema). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'List the team's open pull requests grouped by author' with blocking signals. It scopes to open PRs and explains the grouping, which distinguishes it from broad pull-request listing tools. However, it does not explicitly name sibling tools like get-merged-pull-requests-tool as alternatives, so it falls short of the highest clarity.

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?

The description gives clear usage context: 'Use this to nudge people to merge — lead with the headline' and tells when to set include_bot_details (dependency queue) versus leaving it off (summarising for people). It also advises checking status_freshness before quoting counts. It lacks explicit when-not-to-use rules or named alternatives, but the guidance is sufficient for correct invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources