Coderbuds

Get repository readiness

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

Name	Required	Description	Default
No arguments

Output 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.8/5.0

Behavior5/5

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

Goes well beyond readOnly/idempotent annotations by disclosing nuanced behavior: insufficient-data checks are excluded and never counted against a repo, Coderbuds opt-out behavior, BitBucket's GitHub-only API limitation, archived repository skipping, and dormant repository handling. These are material behavioral traits an agent could not infer from annotations or schema.

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 and dense, but it is front-loaded with the core question and structured around specific checks, edge cases, and exclusions. Most sentences earn their place, though the length could be trimmed slightly without losing essential meaning.

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?

Given a complex readiness evaluation with an output schema present, the description covers what is evaluated, how pass/fail/insufficient_data are treated, edge cases like opt-out, BitBucket, archived/dormant repos, and the team rollup. It is complete enough for correct invocation and interpretation.

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?

With zero parameters and 100% schema description coverage, there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and nothing in the description suggests otherwise.

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: judging repository readiness, not the change itself. It explicitly distinguishes itself from a sibling concept by saying it judges the repository 'a coding agent is dropped into — not the change it makes,' which helps differentiate it from assess-change-fit-tool.

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?

Directly advises when to call it: 'Call this to find what is holding a repo back before pointing an agent at it.' The framing around repository readiness versus change fit gives clear usage context without needing to infer alternatives.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?