SHPBL: Repository Audit & Repair

Audit a repository

evaluate_repo

Read-onlyIdempotent

Audit any GitHub repository and get back one complete result: a report (inventory, languages, spine files, risk signals), the capabilities found in it (name, signature, file and line, stated contract, dependencies), and how it stands against SHPBL's anonymous corpus of audited repositories. Works with no key: every caller gets the whole diagnosis of their own repository. A free run stops at the composition boundary — neither library is searched, so no library rows, candidates, parents or proposed architecture are returned — and nothing is retained (no pull request, no export, no recorded run). A Practitioner key (7-day free trial) continues past that boundary: both libraries searched, candidates identified and composed, and the result written back to your own repository. Whatever a run finds is yours. Follow with fix_repo for verbatim source and diffs, harvest_repo for the whole tree.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	No	Your SHPBL key (shpbl_mcp_…), if you have one. Optional — without it the audit runs at the free depth. Also read from the `Authorization: Bearer …` header.
`repo`	Yes	A GitHub repository: `owner/repo`, a github.com URL, or `owner/repo#branch`.
`brief`	No	Default true: keep the audit compact and do not include the full method protocol. Set false to include the protocol block.
`as_free`	No	Run at the free depth even when the key carries a paid tier, so you can see exactly what a caller without a subscription is handed. Costs no allowance and changes nothing else about the audit.
`sections`	No	Which sections to print, when you only need some of them. Omit it and the whole audit comes back, which is the right default on a first call. On a follow-up — re-reading the capability list after a repair, or checking the benchmark alone — name just what you need (for example `["capabilities"]`) rather than re-sending the whole audit into the conversation. Nothing is computed differently and nothing costs less; only the printed result is narrower, and the machine-readable payload is unchanged.
`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 owner connected the SHPBL GitHub App to this key at https://shpbl.com/mcp-access.
`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 even when `brief: false` — they are unchanged and they still bind the run.

Schema Changelog

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

Changed1 schema field changedSep 5, 2026

addedInput schema / properties / sections

Added value: +{
+  "description": "Which sections to print, when you only need some of them. Omit it and the whole audit comes back, which is the right default on a first call. On a follow-up — re-reading the capability list after a repair, or checking the benchmark alone — name just what you need (for example `[\"capabilities\"]`) rather than re-sending the whole audit into the conversation. Nothing is computed differently and nothing costs less; only the printed result is narrower, and the machine-readable payload is unchanged.",
+  "items": {
+    "enum": [
+      "report",
+      "capabilities",
+      "benchmark",
+      "meta",
+      "library",
+      "own_library"
+    ],
+    "type": "string"
+  },
+  "minItems": 1,
+  "type": "array"
+}

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description richly discloses behavior beyond the annotations: it explains the free-depth composition boundary, what is not returned, that nothing is retained, the Practitioner key continuation, and that findings are owned by the caller. This covers side effects, privacy, and tier-dependent behavior — significant value beyond the readOnlyHint/openWorldHint/idempotentHint annotations.

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

Conciseness5/5

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

The description is well-structured, front-loads the core purpose, then explains boundaries, tier behavior, and sibling routing. Every sentence adds substantive information about behavior, constraints, or next steps. No fluff.

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 the tool's complexity (3-part output, tier-dependent depth, 8 params) and the absence of an output schema, the description is remarkably complete. It explains the result format, free vs paid boundaries, retention, ownership, and follow-up tools. The schema covers parameter details, so nothing critical is missing.

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 the schema already documents all 8 parameters. The description focuses mostly on the return value and tier behavior, not per-parameter semantics. However, the `sections` and `own_library` descriptions in the schema are already excellent, and the tool description adds tier-related context. Baseline 3 is appropriate because the description doesn't compensate for gaps — there are no gaps.

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 clearly states the tool audits any GitHub repository and enumerates the three-part result: report, capabilities, and benchmark against the corpus. It distinguishes itself from siblings by explicitly naming follow-ups (`fix_repo` for source/diffs, `harvest_repo` for the whole tree).

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?

Provides extensive context on when to use this tool vs alternatives: it names `fix_repo` and `harvest_repo` as follow-ups, explains the free vs Practitioner tier difference, and the `sections` parameter guidance tells the agent when to narrow output on follow-up calls. This is explicit usage guidance beyond what the schema provides.

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?