Coderbuds

Get created pull requests

get-created-pull-requests-tool

Read-onlyIdempotent

Count pull requests OPENED over a recent window (default 1 day), broken down per repository and per author, with a human-vs-bot/dependabot split. Use this whenever the question is how many pull requests were created, opened or raised — today, this week, on a repo, or across the team — and especially when someone asks to see it "per repo" or "by repository".

Prefer this over a per-person activity breakdown for any total. It counts from the team's repositories rather than its member list, so it includes authors who have no Coderbuds account (reported as authors_without_member and created_by_non_members) and excludes a member's work in repositories this team does not ship. A member-first count gets both of those wrong.

The result carries its own denominator: repositories is exactly the list the numbers came from, so you can answer "which repos is this based on" from the same call. Slugs that match no team repository come back in unmatched_repositories instead of quietly counting zero.

Opened is counted by the time the provider recorded the pull request being opened. That is a different set from merged in the window — use get-merged-pull-requests for merges, and never present the two as reconciling.

Input Schema

Name	Required	Description
`days`	No	Look-back window in days, trailing from now. Defaults to 1 — note that is the last 24 hours, not today's calendar day.
`include_bots`	No	Whether to include bot/dependabot PRs in the totals. Defaults to true; the result always reports the human-vs-bot split regardless.
`repositories`	No	Optional list of "owner/name" repository slugs to scope to (e.g. ["patchstack/saas"]). A bare repo name like "saas" also matches. Omit to include every repository on the team.

Output Schema

Name	Required	Description
`days`	Yes	Look-back window used, in days.
`team`	Yes	Team name.
`since`	Yes	ISO-8601 start of the window.
`until`	Yes	ISO-8601 end of the window.
`authors`	Yes	Per-author counts with is_bot and is_member flags.
`counted_as`	Yes	What "created" means in this result, to quote when reporting it.
`bot_created`	Yes	PRs opened by bots (any "[bot]" login).
`not_captured`	Yes	Limits of this result, to repeat when reporting the numbers.
`repositories`	Yes	Repository slugs the numbers came from — the denominator for the whole result.
`human_created`	Yes	PRs opened by humans.
`total_created`	Yes	Total PRs opened in the window (respects include_bots).
`dependabot_created`	Yes	PRs opened by dependabot specifically.
`authors_without_member`	Yes	Human authors with no Coderbuds membership on this team — people a per-person breakdown would have omitted entirely.
`created_by_non_members`	Yes	PRs those non-member humans opened.
`repositories_breakdown`	Yes	Per-repository totals with human/bot split, highest first.
`unmatched_repositories`	Yes	Requested slugs that did not match a team repository.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent, but the description adds real behavioral context: counting is based on team repositories rather than member list, non-member authors surface as separate fields, unmatched slugs land in `unmatched_repositories` instead of silently returning zero, and opened-time is distinct from merge-time.

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?

Front-loaded with the core action and the denominator caveat, and every paragraph carries distinct information. Slightly long — the quoted 'per repo' / 'by repository' phrasing and the 'today, this week, on a repo, or across the team' list are a touch redundant, but nothing is wasted enough to hurt.

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?

For a read-only counting tool with an output schema and full param coverage, the description supplies everything an agent needs: window semantics, inclusion rules for bots, repository scoping behavior, and the mismatch/edge-case handling. No gaps remain that would cause a wrong call.

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 coverage is 100%, so the schema already documents all three parameters including the 24-hour-vs-calendar-day caveat and the bare-name matching rule. The description adds no parameter detail beyond what the schema states, so the baseline 3 applies.

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 and resource ('Count pull requests OPENED'), plus the scope (recent window, default 1 day) and the breakdowns produced (per repository, per author, human vs bot). It explicitly separates itself from get-merged-pull-requests and from a per-person activity breakdown, so an agent can route 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering questions ('how many PRs were created/opened/raised — today, this week, on a repo, across the team') and an explicit preference rule over a sibling: 'Prefer this over a per-person activity breakdown for any total.' It also names the alternative for merges and warns against reconciling the two.

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

All Coderbuds tools Inspect

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

Need Help?