Skip to main content
Glama

SHPBL: Repository Audit & Repair

Open a pull request (Practitioner)

write_to_repo

Land finished work in a repository as a pull request: pass the files you wrote (full new contents, not diffs) and this opens a branch and a PR for the human to review and merge. Nothing is ever pushed to the default branch. Requires a SHPBL Practitioner key and the SHPBL GitHub App installed on that repository (or a one-off github_token). The caller chooses the repository — ask which one, or call list_repos first; never assume. Where things go: Harvest output belongs under .shpbl/ in the caller's own repository — the person who asked for the run — and never in the repository that was harvested. Those are frequently not the same repository: a run may read a public open-source project, or a repository the caller merely has access to, and writing a harvest back into a source repository would be putting our output into somebody else's software. Sources a run may read: public repositories that carry a proper open-source license, the caller's own repositories, or private repositories the caller has access to. The server never reads a repository the caller has no right to read, and it never absorbs customer harvests back into the public library.

  • .shpbl/README.md — the index of their capability library (this tool scaffolds it when it is absent).

  • .shpbl/<run-seal>/LEDGER.md — the folded ledger for one run.

  • .shpbl/<run-seal>/REPORT.html — the branded report, if one was produced.

  • .shpbl/<capability-name>/ — a capability kept as source, one folder each.

  • .shpbl/COMPOSITES.md — your own composites: capabilities this run invented for your repository by fusing parts that did nothing alone. Record each as - <name> — <what it fuses> — <why neither part sufficed>. These are yours and stay private; SHPBL's global composites ledger is fed only by Governor-keyed published runs, so never send yours anywhere and never expect them to appear there. If the harvested repository is not the caller's own, the harvest still lands in the caller's .shpbl/ and the source is named in provenance. Ask the person which of their repositories is the home for their library if it is not obvious, and stop for that answer rather than guessing. Give each kept capability a one-line contract in .shpbl/README.md, in the form - <name> — <path> — <contract>. That index is what makes the library reusable: on the next run, read it and pass those entries as own_library to evaluate_repo, fix_repo or run_gauntlet, and the run will tell you which concerns you already solved before citing anything new. Those entries stay yours — they are held for the call and never stored by SHPBL. Repairs are the exception: write the repaired file at its own path, never under .shpbl/.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoYour SHPBL subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header.
kindNoWhat this pull request lands. `harvest` means kept capabilities and a ledger: write them under `.shpbl/` and this scaffolds `.shpbl/README.md` as the index of their own capability library when it is missing. `foundry` means built software and its tests, landing under `.shpbl/` beside the index the same way a harvest does — only ever an artifact whose Build Intent `build_intent` authorised. `repair` means fixed files at their own paths, and nothing is scaffolded.
repoYesThe GitHub repository to write to: `owner/repo` or a URL.
filesYesComplete file contents to commit. For a repair, the whole fixed file — not a diff.
titleYesPull request title — say what the change does.
branchNoBranch to write on. Defaults to one derived from `run_id`, or `shpbl/<date>-<n>`; reusing a name appends to that PR.
run_idNoA stable id for this piece of work (a harvest run seal, a repair order id). Retrying with the same run_id lands on the same branch and updates the same pull request instead of opening a second one. Prefer this over `branch`.
summaryYesPull request body: the repair order, or the run seal and coverage of a harvest. Markdown.
base_refNoBranch to open against. Defaults to the repository's default branch.
github_tokenNoOne-off GitHub token with Contents and Pull requests write. Used for this call only and never stored. Omit it if the SHPBL GitHub App is installed.
build_authorizationNoThe signed build authorizations `build_intent` returned, one per artifact this pull request lands. Required when `kind` is `foundry`: the server verifies each against its own Build Intent ledger and refuses to land an artifact it never gated.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description substantially discloses behavior beyond the annotations: it opens a branch/PR, never pushes to the default branch, requires specific authentication, and states that per-call tokens and library entries are never stored. It also clarifies that the server never reads repositories the caller has no right to read, all consistent with the openWorldHint=true and readOnlyHint=false annotations.

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

Conciseness3/5

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

The description is well-organized with clear sections and the main action is front-loaded, but it is very long and contains some repetition around repository choice and whether to ask the caller. Much of the content is useful, but it could be tighter without losing its strong operational guidance.

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 11 parameters, nuanced repository-policy rules, kind-specific behavior, and no output schema, the description is thorough enough for an agent to select the tool and invoke it correctly. It covers authentication, repository selection, file placement, branch/PR behavior, and the one exception for repairs.

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?

Schema description coverage is 100%, so the schema already documents all parameters. The description still adds meaningful semantics: the kind parameter determines where files land and whether scaffolding occurs, files must be complete contents rather than diffs, reusing run_id updates the same PR, and build_authorization is required and verified for foundry PRs.

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 verb and resource: it lands finished work by opening a branch and a pull request for a human to review and merge. It also clearly distinguishes itself from read/evaluate siblings by emphasizing that nothing is ever pushed to the default branch and that full file contents are passed.

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?

The description gives explicit when-to-use guidance: call it to land finished work, pass full new contents rather than diffs, ask which repository or call list_repos first, and never assume the target repo. It also explains the exception for repairs, requiring repaired files to be written at their own paths rather than under .shpbl/, which prevents misuse.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources