Coderbuds

Find Delivery Bottleneck Tool

find-delivery-bottleneck-tool

Read-onlyIdempotent

Where does a change spend its waiting time — in the backlog, being written, before review, in review, or after merge? Splits the path from "somebody asked for this" to "shipped to production" into six stages — sitting in the backlog, being written on a branch, waiting for a first review, in review, merged and waiting for a deploy, and the deploy itself running — times each one across recently merged pull requests, and names the single slowest stage with the pull requests that prove it and one intervention to try.

Use this to answer "why is our delivery slow" with one stage instead of five dashboards. The interventions differ completely by stage: chasing reviewers does nothing when the wait is after merge.

A stage is only named as the bottleneck when it was measurable on enough of the window's work. A stage that could barely be seen is still reported, with the reason it is ineligible — so missing deployment tracking reads as missing deployment tracking rather than as a fast deploy. Bot pull requests are excluded. Review history is pruned after 90 days, so the window is clamped there.

The backlog stage is measured and reported but never named as the bottleneck: it is the gap before anybody started rather than a change waiting to move, it dwarfs the delivery stages wherever a tracker is connected, and it answers to prioritisation instead. It is timed from the linked Jira or Linear issue.

The two deploy stages are scored only against repositories that have ever recorded a production deployment, because a package or a docs site never deploys and counting its merged work as untracked buries the repositories that do. Each stage carries its own analysed count for that reason; the repositories left out are named in the blind spots.

A stage that is blank because nothing is connected to time it carries an unlock string — a tracker for the backlog, a named production environment or deploy reporting for the two deploy stages — with the full ask in its note. Relay that as something to connect and what it would reveal, never as a stage with no wait in it: the changes did reach production, and how long that took is the part nothing can see.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`window_days`	No	How many days of merged pull requests to time. Defaults to 30, clamped to 1–90 because review history is pruned after 90 days.
`repositories`	No	Optional "owner/name" repository slugs to scope to. Leave empty for every active repository the team ships to. Scoping to one representative repository makes the result easier to interpret with a team.

Output Schema

TableJSON Schema

Name	Required	Description
`team`	Yes	Team name.
`period`	Yes	The window actually measured: ISO start, ISO end, and its span in days.
`stages`	Yes	All six stages — waiting_to_start, writing_the_change, waiting_for_review, in_review, waiting_to_deploy, deploy_running — each with median/p75 hours, sample size, the count it was scored against (`analysed`, which for the two deploy stages counts only repositories that deploy), coverage, whether it is eligible to be ranked, whether it competes for the bottleneck at all (`ranked`, false for waiting_to_start), what would have to be connected to see it (`unlock`), and a note saying why it cannot or will not be ranked.
`headline`	Yes	One-line answer to lead with when relaying this result.
`bottleneck`	No	The single slowest eligible stage: median and p75 hours, sample size, coverage, one intervention to try, and the three slowest pull requests as evidence. Null when no stage was measurable on enough of the window — read the stage notes for what is missing.
`blind_spots`	Yes	What these numbers cannot see. Relay these alongside the finding; the failure mode of this diagnostic is a confident reading of a gap in the data.
`repositories`	Yes	Repository slugs included in the result.
`contributing_factors`	Yes	Patterns that make the slowest stage slower — review concentration, oversized changes, current queue pressure, work merging without a recorded review. Reported, never ranked.
`pull_requests_analysed`	Yes	Human-authored pull requests merged in the window.
`unmatched_repositories`	Yes	Requested slugs that did not match an active team repository — either not tracked, or archived.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 12, 2026

changedOutput schema / properties / stages / description

Previous value: -"All four stages — waiting_for_review, in_review, waiting_to_deploy, deploy_running — each with median/p75 hours, sample size, the count it was scored against (`analysed`, which for the two deploy stages counts only repositories that deploy), coverage, whether it is eligible to be ranked, and a note saying why not when it is not."New value: +"All six stages — waiting_to_start, writing_the_change, waiting_for_review, in_review, waiting_to_deploy, deploy_running — each with median/p75 hours, sample size, the count it was scored against (`analysed`, which for the two deploy stages counts only repositories that deploy), coverage, whether it is eligible to be ranked, whether it competes for the bottleneck at all (`ranked`, false for waiting_to_start), what would have to be connected to see it (`unlock`), and a note saying why it cannot or will not be ranked."

Changed1 schema field changedSep 12, 2026

changedOutput schema / properties / stages / description

Previous value: -"All four stages — waiting_for_review, in_review, waiting_to_deploy, deploy_running — each with median/p75 hours, sample size, coverage, whether it is eligible to be ranked, and a note saying why not when it is not."New value: +"All four stages — waiting_for_review, in_review, waiting_to_deploy, deploy_running — each with median/p75 hours, sample size, the count it was scored against (`analysed`, which for the two deploy stages counts only repositories that deploy), coverage, whether it is eligible to be ranked, and a note saying why not when it is not."

AddedSep 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent; the description adds substantial behavior beyond them: bot PRs excluded, review history pruned at 90 days, backlog measured but never named, deploy stages scored only against repos with recorded production deployments, per-stage analysed counts, and unlock strings for unmeasurable stages.

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-loads the core question and the six-stage framing, then orders caveats logically. It is unusually long for two parameters, and some caveat prose could be tightened, but nearly every paragraph carries an operational rule an agent needs.

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?

With an output schema present, the description need not explain return values, and it instead covers the interpretive edge cases an agent would otherwise get wrong: excluded bots, clamped window, never-bottleneck backlog stage, deploy-stage eligibility, and how to relay unlock notes.

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 both parameters are already documented, including the 1-90 clamp rationale. The description restates the pruning-driven clamp and the blind-spot logic but adds no new syntax or format meaning beyond the schema, so the baseline of 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?

Names a specific analytical verb sequence (split into six stages, time each, name the slowest) over a specific resource (recently merged pull requests). An agent can distinguish this from get-dora-metrics-tool or get-pull-request-metrics-tool because the description pins the output to a single named bottleneck stage.

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?

Clearly states when to reach for it ('why is our delivery slow' with one stage instead of five dashboards) and when an intervention is stage-dependent. It does not name a sibling tool as the alternative, so it falls short of an explicit routing rule, but the context is unambiguous.

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?