Coderbuds

Get Repo Readiness Tool

get-repo-readiness-tool

Read-onlyIdempotent

Is this repo ready for agents? Coderbuds Standards opinion #3 judges the repository a coding agent is dropped into — not the change it makes. For each connected repository it returns pass / fail / insufficient_data on: deploy automation configured, deployed recently, PR size discipline (share of merged PRs inside the Coderbuds line standard), review coverage, agent guidance present (CLAUDE.md / AGENTS.md), CI config present, a tests directory present, and whether the fit check is actually wired in. Each failing check comes with a plain-language gap and recommendation, plus a team rollup of how many repos are ready and the most common gaps.

Insufficient-data checks are always EXCLUDED, never counted against a repo — a repo is only "not ready" when a check genuinely fails. When the team has opted out of Coderbuds Standards the opinionated checks report insufficient_data. BitBucket repos report the content checks as insufficient_data (the API path is GitHub-only). Archived repositories are skipped, and dormant ones (nothing merged in the window, flagged dormant) never fail the wiring/deploy-recency checks and are excluded from the rollup's top_gaps — the headline reflects the repos actually shipping. Call this to find what is holding a repo back before pointing an agent at it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`team`	Yes	Team name.
`rollup`	Yes	Team rollup: repositories_assessed, repositories_ready, dormant_repositories, and top_gaps (the checks failing across the most ACTIVE repositories — dormant repos are excluded so idle test repos cannot bury the gaps that matter).
`window_days`	Yes	Look-back window (days) for the deploy and PR checks.
`repositories`	Yes	Per-repository readiness: repository slug, provider, ready flag, dormant flag (nothing merged in the window), each check as pass\|fail\|insufficient_data, and ranked gaps with recommendations. Active not-ready repos are listed first; archived repos are omitted.
`standards_enabled`	Yes	Whether Coderbuds Standards is on for this team; when off, the opinionated checks report insufficient_data.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, it discloses rich behavior: insufficient_data is always excluded and never counted against a repo, opt-out turns opinionated checks to insufficient_data, BitBucket repos get insufficient_data on content checks, archived repos are skipped, and dormant repos are exempted from wiring/deploy-recency checks and the rollup top_gaps.

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?

It front-loads the core question and the key differentiator before the detail, and the edge-case sentences each carry distinct behavioral rules. It is dense and somewhat long, but for a tool with this many exceptions every sentence is doing work.

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 complex zero-param tool with an output schema, the description covers what is judged, how results are classified (pass/fail/insufficient_data), what accompanies failures (plain-language gap and recommendation), the team rollup, and all the edge-case handling — leaving no significant gap for an agent to call it correctly.

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?

The tool takes no parameters, so the 4 baseline applies. The description adds contextual scope (per connected repository, plus a team rollup) but there are no parameter semantics to elaborate.

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?

The description states a specific question it answers ('Is this repo ready for agents?') and enumerates exactly what it judges: deploy automation, deploy recency, PR size discipline, review coverage, agent guidance, CI config, tests directory, and fit-check wiring. It explicitly distinguishes itself from the change-level sibling by noting it judges 'the repository a coding agent is dropped into — not the change it makes.'

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?

It gives a clear use context ('Call this to find what is holding a repo back before pointing an agent at it') and implicitly contrasts with change-fit assessment, but it never names the sibling tool (assess-change-fit-tool) or states explicit exclusions for when not to call it.

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?