SHPBL: Repository Audit & Repair

Repair a repository

fix_repo

Read-onlyIdempotent

The repair: verbatim source of the files you name — or the repository's spine when you name none — paginated for your context window, with the remediation protocol your model writes the diffs against. Free to run with no key: every file you name, paginated, plus the ordered remediation protocol — repair of what is already there. A free repair stops before either library is searched, so it proposes no composed capability, no candidates and no reuse. A Practitioner key (7-day free trial) crosses that boundary and makes the repair persist — write_to_repo opens the branch and the pull request.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	No	Your SHPBL key (shpbl_mcp_…), if you have one. Optional — without it the repair returns one file at the free depth. Also read from the `Authorization: Bearer …` header.
`part`	No	Which page of source to return. Page 1 reports the total and carries the protocol.
`repo`	Yes	A GitHub repository: `owner/repo` or a URL.
`brief`	No	Skip the remediation protocol preamble and return source with a one-line reminder instead. Use it once you already hold the method — `method_protocol` (free) returns it whenever you need it again.
`paths`	No	Paths to read, from the evaluation. Omit to read the repository's spine.
`own_library`	No	Your own previously harvested capabilities, read out of your repository's `.shpbl/` library and passed back in. Optional. When present, this run checks your concerns against your own library first and tells you which ones you already solved. It is held in memory for this call only — never stored, never added to SHPBL's library.
`github_token`	No	Optional GitHub token (Contents: read) for a private repository. Not needed if the SHPBL GitHub App is connected to this key.
`protocol_ack`	No	Set true to say you already hold the SHPBL protocol — the discipline, the ten meta capabilities, the hands-off list and the return shape are then not reprinted on page 1. Same effect as `brief` for the preamble, and the honest default for a session that has already called `method_protocol` or run an earlier stage.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 1, 2026

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, and the description adds useful context: pagination for the context window, a free repair stopping before library search, no candidates/reuse, and the key crossing into persistence. But the free-tier claim conflicts with the schema's key description, and 'makes the repair persist' is ambiguous about which tool actually performs the write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is repetitive: 'every file you name, paginated, plus the ordered remediation protocol' appears twice in slightly different wording. It front-loads a decent purpose statement, but the promotional '7-day free trial' phrasing and redundant clarifications add little for an agent selecting or invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 8 parameters and no output schema, so the description needs to reliably convey the return shape and boundary conditions. It covers pagination, remediation protocol, and key tiers, but it omits exact output structure and contains the free-depth contradiction, leaving an agent unable to confidently predict a no-key call.

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

Parameters2/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds misleading parameter-level semantics: it claims that with no key every named file is returned paginated, while the schema's key field says no key returns one file at the free depth. It references 'files you name' for paths and keys for tier, but the contradiction cancels the added value.

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 states a concrete service: return verbatim source for named files (or the repository spine) plus a remediation protocol. It also distinguishes itself from the write/repo-mutating sibling by framing this as the read-and-protocol stage. It is slightly muddy because 'repair' is used as a noun and the free-tier wording overclaims, but the core purpose is identifiable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

It gives tier-based conditions (free without a key vs Practitioner key) and points to write_to_repo for the persist step. However, it never says when to choose this tool over evaluate_repo, harvest_repo, or library_search, and the free-tier guidance ('every file you name') directly contradicts the key parameter schema ('returns one file at the free depth'), making the guidance unreliable.

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

All SHPBL: Repository Audit & Repair tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/5

Most tools have distinct roles, but the capability-discovery cluster is genuinely confusable: compose_capability calls itself 'the harvest lane' while harvest_repo is 'the harvest,' and evaluate_repo with a key also identifies candidates and composes — an agent must read long descriptions carefully to pick correctly. The free/key mode-switching also makes each tool's effective behavior conditional, raising misselection risk.

Naming Consistency4/5

The dominant pattern is verb_noun (build_intent, evaluate_repo, fix_repo, harvest_repo, list_repos, pin_source, run_contract, run_gauntlet, write_to_repo), and the library_document/library_index/library_search trio follows a deliberate resource-prefix convention. A few outliers break the pattern — welcome (bare verb), selfcheck_mcp, and subscription_status — but they are a small minority and still readable.

Tool Count4/5

At 17 tools the set is slightly past the ideal 3-15 range, but the domain genuinely spans an audit pipeline, a capability library, run orchestration, repo write-back, and billing/onboarding meta-tools. Roughly a third are lightweight informational endpoints (welcome, method_protocol, run_contract, library_index, subscription_status, selfcheck_mcp), which adds surface area, but each has a distinct job and none is redundant.

Completeness4/5

The lifecycle is well covered: pin_source → evaluate_repo → fix_repo → harvest_repo → compose_capability → write_to_repo, with run_gauntlet orchestrating the whole path and run_contract/method_protocol providing gates and discipline. Minor gaps exist — write_to_repo is create-only with no PR update/merge/close, and past run state is only resumable via ledger_digest — but there are no dead ends.

Resources

Need Help?