Audit and repair any public GitHub repo. Free survey; paid source, unified diffs and a pull request.
Scored across 17 tools
Several tools overlap heavily: evaluate_repo, run_gauntlet, and harvest_repo all perform audits/harvests of repositories; compose_capability and harvest_repo both fuse host affordances with SHPBL primitives. Descriptions add nuance but an agent could easily misselect, especially between the full gauntlet and its individual steps.
Most names follow a verb_noun pattern (evaluate_repo, fix_repo, harvest_repo, list_repos, pin_source, write_to_repo, run_gauntlet, run_contract, selfcheck_mcp, method_protocol). A few deviate (build_intent, welcome, subscription_status), but these are still snake_case and readable.
17 tools is borderline heavy for a repository audit and repair server. While each tool has a distinct role, the set includes meta-tools (welcome, selfcheck_mcp, subscription_status, method_protocol, library_index, library_document) that could be consolidated, making it slightly over-scoped.
The surface covers the full audit lifecycle: discovery (list_repos), evaluation (evaluate_repo), repair (fix_repo), harvest (harvest_repo), write-back (write_to_repo), plus supporting library, contract, and checkpoint tools. Minor gaps exist, such as no explicit tool for deleting or updating existing capabilities in the library, but overall it is comprehensive.
The gate between discovery and creation, and the human checkpoint in front of it. Register one Build Intent — what you found in the host, what SHPBL already possesses, what new software becomes possible, why neither parent does it alone, and the tests that would prove it — and this returns the mechanical verdict: the invariants it passed, whether it rests on SHPBL's licensed reusable capability, whether this caller may execute the foundry, the terminal state to report, and where an authorised artifact may come to rest. THE CHECKPOINT BLOCKS: without human_decision carrying an attributed decision from the person, this returns the proposal in the words to say to them and nothing else — no verdict, no read, no record — and you end your turn and wait. No answer yet is NOT_YET_ASKED, never DECLINED. A decision attributed to you, to a model, to a policy or to a default is refused where the server can recognise it as such; any other name is recorded and attributed, not verified, and the authorization says which — account when the name matches the key's account holder, attested otherwise. DECLINED and NEEDS_EXPLANATION are successful outcomes: record them, build the approved siblings, and do not report a declined proposal as a failed step. Free to call at every level. Every COMPOSE, SPECIALIZE and CREATE must pass through this before any source is written; never assume authority and never write a refused artifact yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL Practitioner key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` header. | |
| intent | Yes | The Build Intent record; every field it asks for is part of the evidence, and each field carries its own description in this schema. Required: `build_intent_id`, `proposed_artifact_id`, `proposed_name`, `display_name`, `what_it_gives_you`, `why_this_repo`, `proposed_type`, `host_repository`, `host_source_paths`, `host_behavior`, `host_problem`, `new_behavior`, `novelty_statement`, `planned_interface`. `display_name`, `what_it_gives_you` and `why_this_repo` are quality gates, not presentation: if you cannot name the software and say what new ability it gives this repository and why this repository, the proposal is refused. Tests are mandatory in effect: at least one entry across `planned_unit_tests`, `planned_behavior_tests` and `planned_integration_tests` (the aliases `planned_tests`, `unit_tests`, `behavior_tests` and `integration_tests` are folded into those three). Every path in `host_source_paths` is resolved against the real tree before anything is authorised — a path that is not there refuses the intent. | |
| cml_license | No | The licence key from a purchased Complete Master Library. Perpetual rights to that release count as execution authority on their own — no subscription needed. | |
| github_token | No | Optional GitHub token (Contents: read) so the gate can read the host tree and prove the cited paths exist. Not needed if you pass `host_source_manifest`. | |
| governor_key | No | Governor authority. Only a Governor-resolved call may stage an artifact for SHPBL's global corpus. | |
| human_decision | No | The person's decision on this proposal. Step 9 is a blocking checkpoint: without an attributed human decision this tool returns the words to say and nothing else, and you end your turn there. Do not send a decision the person did not make. | |
| host_source_manifest | No | The `HOST-SOURCE-MANIFEST.json` from `pin_source` or `tools/source-manifest.mjs`, as JSON text or an object. Offline runs must send this: the gate recomputes its digest and resolves every cited path against its entries. An edited or invented digest is refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses critical behavioral traits: the blocking checkpoint without human_decision, attribution rules (refusing model/policy/default names), the treatment of DECLINED and NEEDS_EXPLANATION as successful outcomes, and the requirement to record and build approved siblings. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and uses poetic metaphor ('gate between discovery and creation') that could be trimmed. However, it is well-structured, covering purpose, behavioral rules, and constraints in a logical flow. There is no wasted redundancy, but it could be more concise without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of an output schema, and the richness of parameters, the description is remarkably complete. It explains what the tool returns, when it blocks, how to handle decisions, and the expected follow-up actions. An agent has enough context to call this correctly without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context for parameters like human_decision (blocking behavior, decision values) and intent (required fields as quality gates, test foldings), which the schema descriptions do not fully convey. It elevates the semantics slightly, but the schema already carries most parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool's purpose: register a Build Intent and resolve its licence, returning a mechanical verdict. It distinguishes itself from siblings by declaring itself as the mandatory gate before COMPOSE, SPECIALIZE, and CREATE operations, and names the 'human checkpoint' role explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Every COMPOSE, SPECIALIZE and CREATE must pass through this before any source is written'), when not to use it ('never assume authority and never write a refused artifact yourself'), and details the blocking checkpoint behavior without a human_decision, including ending the turn and waiting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The harvest lane: read what a repository can already do, then offer codeless capability nominations that fuse those affordances with owned SHPBL primitive capabilities — DREAM, EVOLUTION, MEMORY, DEFENSE, BRAIN and the rest of the canonical forty, plus the S-Tier artifacts. Each nomination names host evidence, proposed capability bodies, Capability Contract slots, a test plan, and honest limits. It contains no implementation; approved materialization belongs to harvest_repo. Free calls return host affordances, then stop before library correlation; nominations require a Practitioner key (7-day free trial).
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL Practitioner subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header. | |
| repo | Yes | A GitHub repository: `owner/repo` or a URL. | |
| pages | No | How many source pages to read for affordance evidence, 1 to 12 (about 90,000 characters each). More pages means more of the tree is read; the grants are cut from whatever was read. | |
| grants | No | How many codeless capability nominations to return, 1 to 200. Ranked by measured fit and capability standing. | |
| include | No | Optional path filter — only paths containing this text are read for affordances. | |
| github_token | No | Optional GitHub token (Contents: read) for a private repository. | |
| per_affordance | No | How many nominations one affordance may produce, 1 to 200. Raise it to see alternative leads for the same host capability. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower. The description adds genuine behavioral context the annotations don't: the free-tier truncation point, the requirement of a key for full output, and that no implementation is produced. These are real additions an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear lane label, but it is dense with branded jargon ('SHPBL', 'DREAM, EVOLUTION, MEMORY, DEFENSE, BRAIN and the rest of the canonical forty', 'S-Tier artifacts') that consumes space without helping the agent decide or call. The routing and gating sentences do earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey return shape, and it does: each nomination names host evidence, capability bodies, contract slots, a test plan, and honest limits, plus the distinction between free affordance output and paid nominations. Fairly complete, though the free-tier return shape could be described more concretely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 seven parameters including defaults and ranges. The description adds no per-parameter meaning (e.g., how pages interacts with grants), so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compose/offer nominations) and resource (repository capabilities), and explicitly distinguishes itself from harvest_repo: 'It contains no implementation; approved materialization belongs to `harvest_repo`.' The jargon ('harvest lane', 'canonical forty') adds opacity, but the core action and its boundary are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative (harvest_repo) and states the gating condition: free calls return affordances and stop before library correlation, while nominations require a Practitioner key. It clearly sets a context for use. It doesn't compare against other plausible siblings like evaluate_repo or build_intent, so it falls short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
The harvest shortcut: point it at a repository you hold a licence to reuse — one you do not own and will never open a pull request against — and it goes straight to the capabilities. It reads what that repository can already do, fuses those affordances with the owned SHPBL capability library, ranks and names the results as proposals a person can read, stops for your decision on each one, and then emits the seed modules for exactly the ones you approved into your own .shpbl/ library. That is the gauntlet's steps 8, 9 and 10 without the audit, the repair plan or the pull request. It never writes to the target repository. Pass approve with approved_by and host_license to collect the approved grants; pass mode: "walk" for the older batched ledger walk of the whole tree (estimate, part, ledger_digest, budget belong to that mode). Free calls report what the repository can do and what is offerable against it, then stop at the composition boundary; grants need a Practitioner key (7-day free trial).
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL Practitioner subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header. | |
| mode | No | `harvest` (the default when nothing else in the call implies a walk) is the shortcut: proposals, your decision, then the seed modules for what you approved. `walk` is the older batched ledger walk of the whole tree, which reads and classifies but composes nothing. Send it explicitly whenever you also send `part`, `ledger_digest`, `budget` or `brief`. | |
| part | No | Walk mode only: which batch to return, 1 to 2000. Batch 1 carries the protocol and the manifest; walk them all in order. | |
| repo | Yes | A GitHub repository: `owner/repo` or a URL. | |
| brief | No | Walk mode only: skip the harvest protocol preamble on batch 1 and spend the payload on source. Use it once you already hold the method — `method_protocol` (free) returns it verbatim. | |
| pages | No | Harvest mode: how many source pages to read for evidence, 1 to 12 (about 90,000 characters each). Proposals are cut only from what was actually read. | |
| budget | No | Characters per batch — a whole number from 10,000 to 120,000. Defaults to 90000; lower it for a smaller context window, raise it only if the client can carry it. Out-of-range values are refused in plain words, not silently clamped. | |
| grants | No | Harvest mode: how many capability proposals to rank, 1 to 200. There is no fixed shallow ceiling any more — a sophisticated repository can support far more than a couple of dozen higher-order compositions, and the safeguard against a weak proposal is the approval and the Capability Contract, not a small number here. | |
| approve | No | Harvest mode: the grant ids the person approved. Only these are emitted. Omit it on the first call — the proposals have to be put to them first. An id nobody proposed refuses the whole set rather than emitting the rest. | |
| decline | No | Harvest mode: the grant ids the person explicitly said no to. Only these are recorded as declined; anything they were not asked about stays open and is re-offered, never written down as a refusal. | |
| include | No | Optional path filter — only paths containing this text are harvested. | |
| estimate | No | Return the size of the walk only — batch count, total characters, largest batch, split files — with no source. | |
| approved_by | No | The name of the person who approved them. Required with `approve`. An agent, a model, a vendor, a policy or a default is refused, not recorded. | |
| cml_license | No | Your perpetual copy's licence key, if you hold one. It changes retention, never depth. | |
| github_token | No | Optional GitHub token (Contents: read) for a private repository. Not needed if the SHPBL GitHub App is connected to this key. | |
| governor_key | No | Operator passphrase for SHPBL's own copy. Resolved by the server; it changes only where the harvest is staged, never what is proposed. | |
| host_license | No | What the target repository's licence permits for this reuse, and any obligation it attaches — for example `MIT, attribution required`. Required with `approve`; SHPBL records your declaration and does not verify it. | |
| ledger_digest | No | The ledger folded so far, handed back by a previous session so this batch continues the same run instead of starting over. | |
| quality_floor | No | Harvest mode: drop proposals scoring below this, 0 to 1. The score is a discovery aid for ordering what to read first — it is never evidence that a capability deserves to exist. | |
| per_affordance | No | Harvest mode: how many proposals one host affordance may produce, 1 to 200. | |
| reuse_permitted | No | Required with `approve`: the person's explicit statement that reuse of this upstream project is permitted for this composition. Absence is never a yes, and SHPBL does not infer permission from a detected licence file. Recording your declaration is not legal verification and nothing here is legal advice. | |
| upstream_project | No | The upstream project the reuse is declared against. Defaults to the repository being harvested. | |
| novelty_threshold | No | Harvest mode: how different a proposal must be from the higher-ranked ones already chosen, 0 to 1, measured on bound capabilities and title vocabulary. 0 suppresses only exact duplicates; 0.4 is firm de-duplication of near-identical variants. | |
| reuse_obligations | No | The obligations the licence attaches that must be preserved in the artifact — attribution, notice retention, share-alike, and so on. Recorded against every emitted artifact and carried into its manifest. | |
| carry_notice_files | No | Licence or notice files from the host that must be copied into the artifact. Detected candidates are reported to you if you omit this. | |
| suppress_duplicates | No | Harvest mode: drop proposals whose proposed composition is identical to a higher-ranked one. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly/openWorld/idempotent, but the description adds substantial behavioral context the annotations cannot: the approval gate ('stops for your decision on each one'), the write boundary ('never writes to the target repository'; 'emits into your own .shpbl/'), the auth model (Practitioner key, 7-day trial), and the free vs. paid boundary. It does not describe output shape, but annotations already carry the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core behavior, but sentences are dense and the walk-mode parenthetical ('estimate, part, ledger_digest, budget belong to that mode') is buried mid-paragraph and partially redundant with schema descriptions. It is longer than necessary for a definition whose parameters are fully documented elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 26-parameter, no-output-schema tool, the description covers the mental model (harvest vs. walk, approval flow, license/permission semantics, key requirement) that an agent needs. The individual parameter semantics live in the schema, which is acceptable given 100% coverage, though the two modes' parameter sets could be delineated more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented in the schema. The description reinforces mode/walk semantics and the approve/approved_by/host_license requirement, but adds little syntax or format beyond the schema. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('harvest capability') and resource ('repository'), and distinguishes itself from siblings by naming what it omits — 'the gauntlet's steps 8, 9 and 10 without the audit, the repair plan or the pull request.' An agent can tell this apart from run_gauntlet and compose_capability without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ('a repository you hold a licence to reuse — one you do not own and will never open a pull request against') and an explicit mode fork ('pass mode: walk for the older batched ledger walk'). It doesn't name sibling alternatives (run_gauntlet, compose_capability) by name, but the gauntlet-relative framing effectively routes the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one long SHPBL document, paged for a context window: volume (the complete text of a volume of The Strategic Master Library), catalog_outline (the Collective catalog's parts, component classes, agent-kit steps and verification axes), report_template (the branded audit report HTML to fill in), or standing_order (the prompt that governs a run). Requires a Practitioner key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header. | |
| part | No | 1-based page of the document, up to 60. | |
| volume | No | Required for `document: volume` — the volume slug or its number, 1 through 7. | |
| section | No | For `document: catalog_outline` — only parts or sections whose name contains this text. | |
| document | Yes | Which document to read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavior beyond that: the tool pages long documents for a context window and requires a Practitioner key. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main purpose is front-loaded, and the parenthetical enumerations are compact and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with full schema coverage and read-only/idempotent annotations, the description covers document variants, paging, and auth. It does not spell out the exact return page structure, but 'paged for a context window' plus the `part` parameter is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaningful semantics for the document enum: volume, catalog_outline, report_template, and standing_order are each explained. It also explains the key requirement, which the schema presents as optional under certain conditions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Read') on a concrete resource ('one long SHPBL document') and enumerates the four document types with brief definitions. This makes it easy to distinguish from sibling tools like library_index and library_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool: when a full named document is needed, paged for a context window. It also notes the Practitioner key requirement. It does not explicitly contrast with library_index or library_search, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything published on shpbl.com in one read: the editions and their prices and licences, the seven volumes of The Strategic Master Library with their seals and read links, the public downloads with byte sizes, and the case studies of real audit runs with each verdict, and pools — the canonical reconciliation of every count this server quotes, so two totals are never mistaken for a contradiction and never added together. Scope it with sections, or pass volume (slug or 1-7) or case_study (slug) for one record in full. Free — no key, no allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | One volume in full, by slug or by number 1-7. Its complete text is a `library_document` call. | |
| sections | No | Which sections to return. Omit for all of them: facts, volumes, editions, downloads, case_studies, pools. `pools` is the canonical reconciliation of every count this server quotes — read it before comparing two totals. | |
| case_study | No | One case study in full, by slug — what the run got right and what it learned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine value beyond that: 'Free — no key, no allowance' discloses auth and rate-allowance behavior, and the pools explanation ('canonical reconciliation of every count this server quotes, so two totals are never mistaken for a contradiction and never added together') is a real behavioral caveat about how returned numbers relate to each other. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The scope is front-loaded ('Everything published on shpbl.com in one read') and the enumerated contents each earn their place by telling the agent what data to expect. The closing 'Free — no key, no allowance' is a compact, high-value statement. The first sentence is a long run-on held together by colons and commas, which is the only structural downside.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does so well by enumerating the data shapes for editions, volumes, downloads, case studies, and pools. All three optional parameters are explained, and the read-only/idempotent annotations complete the picture. The one gap is the 'facts' section in the sections enum, which is never explained in either the description or the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 — the schema already explains volume, sections (including the pools reconciliation note), and case_study fully. The description adds only color about what each section contains (prices and licences, seals and read links, byte sizes, verdicts), which is mildly helpful but does not materially compensate for or clarify anything the schema misses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('everything published on shpbl.com') and frames the tool as a single-read index of editions, volumes, downloads, case studies, and pools. It is clear the tool is a compound catalog/read operation, and the schema note that a volume's complete text is a `library_document` call helps separate it from that sibling. It stops short of a crisp imperative verb like 'list' or 'return the index of', which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage paths: 'Scope it with `sections`, or pass `volume` (slug or 1-7) or `case_study` (slug) for one record in full.' It also gives a concrete when-to-use rule for pools ('read it before comparing two totals') and states no key or allowance is needed. It does not explicitly state when to prefer a sibling like library_search, so exclusions/alternatives are only implied rather than named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Collective Master Library for a capability in plain words, before writing new code. scope: "catalog" (Practitioner) searches the engineered components — class, what each does, API surface, line counts, verification marks. scope: "composites" searches capabilities earlier runs invented for one host by fusing library parts, each citing its sealed report. Pass ids for whole rows by component ID, with siblings and declared twins. Multi-word queries match term by term and rank; with no exact hit you get the closest rows, labelled as such.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Up to 20 component IDs (e.g. `STIER-S-84`, `BLD-ENG-303`) returned in full instead of a search. | |
| key | No | Your SHPBL subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header. | |
| pack | No | Vault only: restrict to one vertical pack, e.g. `fintech-v1`. Substring match. | |
| page | No | 1-based page of results. A page past the end is refused, never returned empty. | |
| limit | No | Alias for `page_size`, 1 to 50. Given both, `page_size` wins. | |
| query | No | Plain-words capability, name, ID or API symbol. Omit to page the whole pool. | |
| scope | No | `catalog` — engineered components (Practitioner). `crown-jewels` — the S-Tier Vault of standalone lab-curated artifacts. `composites` — capabilities past runs invented for one host. (`vault` is no longer available; asking for it returns a pointer to these scopes.) | catalog |
| page_size | No | Rows per page, 1 to 50. Defaults to 20. | |
| certified_only | No | Crown jewels only: return only rows whose body the certification harness executed and read clean (CERTIFIED or PROVISIONAL). This withholds the INCONCLUSIVE rows — bodies the harness could not exercise, which still exist and still ship. Leave this off (the default) to see them too; the withheld figure is reported as `certification.withheldInconclusive`. | |
| component_class | No | Catalog only: restrict to one component class, e.g. `CrownJewel/S-Tier`, `Block/Engine`. Substring match. | |
| include_siblings | No | With `ids`: also list up to 12 other component IDs in the same class, for comparison. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral detail: multi-word queries match term by term, rank results, and return closest rows labelled as such when there is no exact hit. It also clarifies that composites cite a sealed report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, and each sentence earns its place by explaining either search intent, scope behavior, ids, or matching semantics. It is dense but not bloated, with only minor brand-specific jargon like 'Collective Master Library'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema tool with 11 parameters, the description covers the most decision-relevant behavior: when to search, which scope to choose, and how no-exact-hit results are labelled. It does not spell out the full result row shape or crown-jewels specifics, but the rich schema and annotations fill most remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter; the baseline is 3. The description adds genuine semantic value by explaining plain-words matching, ids returning whole rows with siblings and declared twins, and the meaning of the catalog/composites scopes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb-resource pair ('Search the Collective Master Library for a capability in plain words, before writing new code') and the rest of the description explains distinct scope variants. This clearly separates it from the build/compose siblings and from library_document/library_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to search before writing new code and explains when to pass ids versus a plain-word query, plus what each scope returns. It does not name alternative tools explicitly, but the context is strong enough to route an agent to the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists real repository names so a run never starts on a guessed one, and answers whether a repository can be written to. Pass github_token to see everything that token can see, or owner to list a public account's repositories; with neither, it lists the repositories the SHPBL GitHub App is installed on for this key — the same ones a pull request can be opened on. Pass repo: "owner/name" to ask about one target instead of reading the whole list. Free — costs no allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL key (shpbl_mcp_…), only needed to list App-connected repositories. Optional if sent as the Authorization header. | |
| page | No | Which page of the connected-repository list to return, 1-based. Use this rather than a higher `limit` past 100; the response names the next page when there is one. | |
| repo | No | Ask about one target, `owner/repo`: whether this key may open a pull request on it. Call this before offering to write. | |
| limit | No | How many repositories to return (default 30, max 100). | |
| owner | No | A GitHub user or organisation to list the public repositories of, when no token is available. | |
| github_token | No | A GitHub token (PAT or fine-grained) to list with. Never stored, never logged — used for this call only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety bar is low. The description adds genuine context beyond that: the App-installed scope tied to the key, the write-eligibility answer, and the cost note ('Free — costs no allowance'). It is fully consistent with the annotations — no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and every subsequent clause earns its place — invocation modes, single-target navigation, and the free/allowance note. It is a dense single paragraph rather than tight bullets, but nothing is wasted relative to the information density needed for a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only discovery tool whose safety profile is fully covered by annotations and whose parameters are all documented, the description is nearly complete: coverage of all three listing modes, the single-target path, and cost. The main absence is the response shape (no output schema exists), but for a 'list names + next-page' tool this is a minor gap, especially given the sibling ecosystem positions it as a pre-flight read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the behavioral difference between github_token mode ('everything that token can see'), owner mode, and no-argument mode (App-installed repos), and positions repo as a targeted check. This enriches the six documented parameters without repeating their schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair ('Lists real repository names') plus a second capability (answers write-permission questions), and grounds it in a concrete problem: 'so a run never starts on a guessed one.' It clearly distinguishes from the write-side sibling (write_to_repo) by framing itself as the read/discovery half. An agent cannot mistake what this does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly maps three invocation modes to their conditions: with github_token, with owner, and with neither (App-installed repos, 'the same ones a pull request can be opened on'). It also tells when to use repo for a single-target check. It doesn't explicitly contrast with siblings by name or say what not to use it for, which keeps it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the SHPBL disciplines verbatim — evaluation, remediation and harvest — plus the component classes' verification axes and the reporting style. Free and unmetered. Fetch it once, then call fix_repo or harvest_repo with brief: true so their payload is source rather than repeated instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | One stage only: `evaluate`, `fix` or `harvest`. Omit for all three. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds useful context: the operation is free, unmetered, returns content verbatim, and is intended to be fetched once and reused. This aligns with the annotations and enriches them without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-ordered: purpose first, then cost/behavior, then practical usage. Every sentence earns its place, and the backticked tool references make the intended workflow clear without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only reference tool with one optional parameter and no output schema, the description is largely complete: it states what is returned, that it is free and unmetered, and how to use it with downstream tools. It does not specify the exact output format, but the source-reuse instruction mitigates that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single optional parameter fully, including the enum values and the note that omitting it returns all three stages. The description mentions evaluation, remediation, and harvest but does not add meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it returns the SHPBL disciplines verbatim, plus verification axes and reporting style. It is specific and unambiguous, but it does not explicitly distinguish itself from sibling tools like library_document or library_index, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage guidance: fetch once and then call fix_repo or harvest_repo with brief: true so the payload is source rather than repeated instructions. It provides clear context and names related tools, though it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build HOST-SOURCE-MANIFEST.json for canonical step 1 from a GitHub repository, online, with no clone and no download: every file's Git blob identity, the byte length, the head commit, and the SHPBL-SOURCE-DIGEST/1 digest over the pinned tree. Write the returned JSON to your run folder as HOST-SOURCE-MANIFEST.json and step 1 passes the gate. Free and unmetered. If the run is offline instead, do not call this — run node tools/source-manifest.mjs <repo-dir|repo.zip> from the edition, which produces the same manifest from a directory or straight out of the repository ZIP. Never invent the digest or the commit.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL key, if you have one. Optional — this tool is free; a key only helps reach a private repository through a connected GitHub App install. | |
| repo | Yes | A GitHub repository: `owner/repo`, a github.com URL, or `owner/repo#branch`. | |
| label | No | What to call the target in the manifest. Defaults to `owner/repo@branch`. | |
| github_token | No | Optional GitHub token (Contents: read) for a private repository. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description adds key behavioral facts: no clone or download occurs, the returned JSON must be written to the run folder, the operation is free and unmetered, and the digest/commit must never be invented. These details meaningfully shape how an agent should use and trust the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but purposeful: it front-loads the core action and output, then covers offline alternatives and a critical integrity warning. No sentence is wasted; each clause adds operational guidance the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description compensates well by outlining the manifest's contents, the required agent action (write to run folder), the offline fallback, and the prohibition on inventing values. The annotations cover safety and idempotency, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for all four parameters, so the tool description does not need to re-explain them. The description adds contextual constraints like 'online' and 'no clone/no download', but no new parameter-specific semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb ('Build'), a concrete output artifact ('HOST-SOURCE-MANIFEST.json'), a specific source ('a GitHub repository'), and a clear workflow context ('canonical step 1'). It also lists exactly what the manifest contains, making the tool's purpose unmistakable and distinguishing it from sibling repo tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('online'), when not to call it ('If the run is offline instead, do not call this'), and provides the exact alternative command and inputs. It also warns against fabricating output values, giving an important boundary for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the canonical twelve-step run contract, or check a run bundle against it. Call it with no files to get the contract itself: every step's id, the artifacts it must produce, the exact condition that closes it, the terminal word to report when it does not, the instruction-precedence order, the retention rule and the two legal ends of step 12. Call it with files — a map of run-folder paths to their text — to get the machine verdict: which step blocked, which predicate refused and why. This is the identical implementation the offline tools/run-gate.mjs in every edition is bundled from, so the two cannot disagree about whether a bundle satisfies the contract. What they do not share is evidence: the offline gate checks the bundle you hand it, while a connected run can also confirm against the real repository tree that the files cited exist and say what the bundle claims. Same rules, one with a witness. Free, unmetered, read-only, stateless. Never infer a step, reorder one, or declare a run finished on your own reading — run the gate and report its word.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | The run bundle as `path: text`, relative to the run folder (for example `STEP-LEDGER.json`). Send the canonical outputs you have; the gate says what is missing. Bounded: at most 400 entries and 8 MB of text in one call, and identical diagnostics are collapsed to one line with a count rather than repeated per entry. Omit this to read the contract without evaluating anything. | |
| through_step | No | Evaluate gates through this step only. Defaults to 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description reinforces this with 'read-only, stateless' and adds context beyond them: the implementation is identical to the offline gate so they cannot disagree, and a connected run can additionally confirm files against the real repository tree ('Same rules, one with a witness'). It also discloses bounded-input behavior and deterministic verdicts without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the primary action, and its clauses are purposeful: contract contents, verdict contents, offline/online relationship, and final directive. It is longer than minimal, but for a canonical gate with no output schema, every sentence adds useful rules or context; a minor structural improvement would be bulleted mode breakdowns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying the return shapes for both modes: the contract's step ids, artifacts, closing conditions, terminal words, precedence, retention, and the verdict's blocking step, refused predicate, and reason. Combined with the safety/cost hints (free, unmetered, read-only) and explicit comparison to the offline gate, an agent has enough to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema description coverage is 100%, so the baseline is 3: both `files` and `through_step` are already fully documented, including bounds, omission behavior, and default. The description adds operational flavor ('the gate says what is missing') and maps `files` to the verdict mode, but it does not materially expand parameter meaning beyond the schema; `through_step` is only covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-phrase, 'Read the canonical twelve-step run contract, or check a run bundle against it,' naming the resource and the dual execution modes. It goes on to list exactly what each call returns, making the tool distinguishable from sibling tools like evaluate_repo, fix_repo, and run_gauntlet without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call it with no files to get the contract itself' and 'Call it with files ... to get the machine verdict,' prescribing the exact invocation for each purpose. It also contrasts the connected MCP tool with the offline 'tools/run-gate.mjs' and closes with a strong when-not-to-instruct: 'Never infer a step, reorder one, or declare a run finished on your own reading — run the gate and report its word.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One runner for an entire SHPBL repository audit and repair: survey, opening library comparison, evaluation, repair, the batched harvest, closing library comparison, the branded HTML report, and the write-back path. STRICT SEQUENCE: call it once with no step for the run card, then step: 1, step: 2, one step per turn, in order. Do the returned step, report one line to the person, then call the next. Never call two steps in one turn, never attempt the whole run at once, and never infer a finding you were not handed. From step: 2 on you must pass ledger_digest; every 3 steps (adjustable with checkpoint_interval, max 10, only when the person asks for fewer pauses) the run pauses and you must ask the person before continuing, then pass continue_ack: "continue". The final step hands over the report template and the write-back path. Your own model does all reading and writing. This full conductor requires a Practitioner key (7-day free trial). The free lane provides repository evaluation, not a partial or full gauntlet.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL Practitioner subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header. | |
| repo | Yes | A GitHub repository: `owner/repo`, a URL, or `owner/repo#branch`. | |
| step | No | 0 to 2000. 0 (default) returns the run card and the plan with no source. 1…N walk the harvest batches, one per turn and in order. N+1 closes the run with the report template and the write-back path. Do not skip ahead. | |
| budget | No | Characters per harvest step — a whole number from 10,000 to 120,000. Defaults to a moderate 45,000 so each step stays readable and cheap; raise it toward 90,000 only if the person asks for fewer, heavier steps. | |
| include | No | Optional path filter — only paths containing this text are in scope for the whole run. | |
| fold_token | No | The `fold_token` returned by the previous step, passed back verbatim. Required from `step: 2` onward: it is signed by this server and carries the previous step's number and the hash of the ledger you held then, so a step cannot be skipped and a ledger cannot be truncated or replaced. Never edit it, never write one yourself. | |
| 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. | |
| personality | No | How the person wants to be spoken to for this run: technical, professional, friendly, light, coach, deadpan. Ask them once before step 0 and pass what they choose; it rides the run and changes wording only, never a finding, a state or a gate. Defaults to professional when they have no preference. Pass `none` to switch the voice off entirely — bare wording, no openers, no asides — which is the right setting for an automated reviewer reading the run as evidence. | |
| continue_ack | No | The person's approval to continue past a checkpoint. Every 3 harvest steps this run pauses: report to the person, ask whether to continue, and only when they say yes call the next step with `continue_ack: "continue"`. Never send it without asking. | |
| 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 this session already holds the SHPBL protocol. The discipline, the ten meta capabilities, the hands-off list and the return shapes are then not printed on step 0 or step 1 — they are unchanged and they still bind the run. Use it when you have already called `method_protocol` or run a staged tool in this session; it saves tens of thousands of characters of repetition. | |
| ledger_digest | No | The ledger folded so far, one line per capability, **each line carrying the file path it came from** (for example `src/lib/queue.ts — retry with backoff`). Required from `step: 2` onward — it is the proof that you actually folded the previous step — and required on the closing step so the closing library comparison runs against what you harvested. The server checks shape as well as length: a ledger that names no paths, or is padded out around one, is refused (and not charged). | |
| checkpoint_interval | No | How many harvest steps between check-ins with the person. Defaults to 3; raise it (up to 10) only when the person has asked for fewer pauses. Never set it silently — the check-ins are how the person stays in the loop. Once set it rides inside the run's `fold_token`, so passing it again on later steps is not required; if you ever start a fresh chain, set it again or the run returns to 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already carrying readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context beyond them: the server signs fold_token to prevent step skipping or ledger replacement, checkpoints halt the run pending human approval, the server validates and refuses malformed ledgers ("and not charged"), and own_library is held in memory for this call only. The clause "Your own model does all reading and writing" resolves the apparent tension between readOnlyHint and the repair/write-back mention — no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, every sentence carries a distinct operational rule for a genuinely complex 13-parameter, multi-turn conductor. It is front-loaded with purpose and the step sequence, uses caps judiciously for hard prohibitions, and orders sections logically: purpose, sequence, gates, credential caveat. This density is justified by the tool's complexity rather than being padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema, the description is remarkably complete: it covers the full call protocol across turns, per-step parameter requirements, checkpoint gates and human-in-the-loop behavior, auth thresholds and billing nuance, sibling differentiation, and what the final step hands over. The schema covers the run-card return value ("0 returns the run card and the plan with no source"), so nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already documents each parameter in detail. The description adds genuine lifecycle semantics the schema cannot express: ledger_digest and fold_token become mandatory from step 2 onward, checkpoint_interval "rides inside the run's fold_token" and persists across steps, and personality is to be asked once before step 0. This temporal inter-parameter guidance meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — "One runner for an entire SHPBL repository audit and repair" — and enumerates the full phase list (survey, opening library comparison, evaluation, repair, batched harvest, closing comparison, HTML report, write-back). It distinguishes itself from its siblings by being the full-sequence conductor, noting that the free lane provides "repository evaluation, not a partial or full gauntlet," which cleanly separates it from evaluate_repo, fix_repo, and harvest_repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit, imperative usage rules: call once with no step for the run card, then step: 1, step: 2, one step per turn in order; explicit prohibitions ("Never call two steps in one turn, never attempt the whole run at once"); and conditional rules stipulating when ledger_digest and continue_ack are required. It also states the when-not: the Practitioner key requirement and the free lane's limitation to evaluation only, so an agent knows not to invoke the full conductor without the key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs SHPBL's own audit against the running server and returns one pass/fail/unavailable line per verification axis: the registered tool surface against the priced tier table, version agreement across the published files, subscription-register reachability, catalog reachability, repository-write authority, and billing wiring. Free, unmetered, read-only — nothing is written and no model is called. Use it to prove the server is live and consistent before starting a run, or when a tool answered in a way that looks wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include the full tool-to-tier table and the axis definitions in the answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'nothing is written and no model is called', fully disclosing side-effect-free and compute-light behavior. Consistent with readOnly and idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and not overly long, but some redundancy exists between the axis list and the later examples. Minor trimming could tighten it without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description fully specifies the output shape (one line per axis, pass/fail/unavailable), enumerates the axes, and explains the verbose flag. Enough for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single boolean parameter is covered by the schema, and the description adds concrete meaning: including the full table and axis definitions in the output. Slight room for explaining the default false behavior, but schema already covers type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs an audit and returns pass/fail/unavailable lines per verification axis. The list of axes and the specific use cases make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use it: before starting a run or when a tool answer looks wrong. Also clarifies it is free and unmetered, removing cost concerns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the tiers of this MCP server and — from the key argument or the same Authorization header the gated tools read — that key's tier, status and month-to-date usage. This is the authoritative answer to "am I connected, and what do I have".
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Optional SHPBL subscription key. Omit it if your client sends the key as a request header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent. The description adds important behavioral context beyond that: it reads from the optional `key` argument or the same `Authorization` header used by gated tools, and reports month-to-date usage. This clarifies the tool's data source without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and every clause adds information: what is reported, how the key is resolved, and what question the tool answers. No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description covers the operation, the inputs, and the kind of output. There is no output schema, so a bit more detail about the exact response shape would help, but the stated scope is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the `key` parameter at 100% coverage, so the baseline is 3. The description adds value by explaining that the key is optional and can be omitted when the client sends the key as a request header, which clarifies when and how the parameter should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Report the tiers of this MCP server' and the calling key's 'tier, status and month-to-date usage.' It also frames itself as 'the authoritative answer' to connection and entitlement questions, making its role unmistakable even among unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to call this tool: whenever the agent needs to determine 'am I connected, and what do I have.' It does not explicitly name alternatives or exclusions, but no sibling tool serves the same subscription-status purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this first, once, when a person connects. Returns the welcome, the full tool menu with one line per tool, the exact sentences a person can say to start a run, the support address, and the link to the user's manual. Free, unmetered, no key. Read it to the person in your own words — warmly and briefly — then ask what they would like to point it at.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The person's first name, if you know it, so the greeting can use it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent; the description adds valuable behavioral context beyond that: it is free, unmetered, requires no key, and should be read aloud warmly and briefly. This fully discloses what the agent can expect when invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. The first sentence delivers the critical call-first instruction, the second enumerates return contents, and the third gives the interaction directive. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explicitly listing what the tool returns: welcome, full tool menu, exact example sentences, support address, and manual link. It also covers access characteristics (free, unmetered, no key) and the expected post-call behavior, making it fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter `name` is fully described in the input schema ('The person's first name, if you know it, so the greeting can use it'). The tool description itself adds no parameter-specific semantics, but the schema coverage is 100%, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Call this first') and names the exact resource: a welcome message with the full tool menu, example start sentences, support address, and manual link. This clearly separates it from the sibling tools, which are all subsequent action-oriented tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call the tool ('first, once, when a person connects') and what to do after (ask what they would like to point it at). This gives an unambiguous trigger and flow, even without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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/.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Your SHPBL subscription key (shpbl_mcp_…). Optional if your client sends it as the `Authorization: Bearer …` request header. | |
| kind | No | What 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. | |
| repo | Yes | The GitHub repository to write to: `owner/repo` or a URL. | |
| files | Yes | Complete file contents to commit. For a repair, the whole fixed file — not a diff. | |
| title | Yes | Pull request title — say what the change does. | |
| branch | No | Branch to write on. Defaults to one derived from `run_id`, or `shpbl/<date>-<n>`; reusing a name appends to that PR. | |
| run_id | No | A 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`. | |
| summary | Yes | Pull request body: the repair order, or the run seal and coverage of a harvest. Markdown. | |
| base_ref | No | Branch to open against. Defaults to the repository's default branch. | |
| github_token | No | One-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_authorization | No | The 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compose_capability2 fields changedInput schema / properties / grants / descriptionPrevious value: -"How many Capability Grants to return, 1 to 24. Ranked by measured fit and capability standing."New value: +"How many codeless capability nominations to return, 1 to 200. Ranked by measured fit and capability standing."Input schema / properties / per_affordance / descriptionPrevious value: -"How many grants one affordance may produce, 1 to 4. Raise it to see alternative leads for the same host capability."New value: +"How many nominations one affordance may produce, 1 to 200. Raise it to see alternative leads for the same host capability."harvest_repo2 fields changedInput schema / properties / per_affordance / descriptionPrevious value: -"Harvest mode: how many proposals one host affordance may produce, 1 to 4."New value: +"Harvest mode: how many proposals one host affordance may produce, 1 to 200."Input schema / properties / suppress_duplicates / descriptionPrevious value: -"Harvest mode: drop proposals whose emitted body is byte-identical to a higher-ranked one. Default true."New value: +"Harvest mode: drop proposals whose proposed composition is identical to a higher-ranked one. Default true."build_intent2 fields changedInput schema / properties / intent / properties / capability_contractAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "approval_id": {
+ "default": "",
+ "maxLength": 160,
+ "type": "string"
+ },
+ "approved_by": {
+ "default": "",
+ "maxLength": 160,
+ "type": "string"
+ },
+ "artifact_id": {
+ "maxLength": 160,
+ "minLength": 3,
+ "type": "string"
+ },
+ "behavioral_promise": {
+ "description": "The whole promise, complete. If the promise names six lifecycle stages, all six are in scope for green.",
+ "maxLength": 4000,
+ "minLength": 40,
+ "type": "string"
+ },
+ "capability_name": {
+ "description": "What a person calls it.",
+ "maxLength": 160,
+ "minLength": 3,
+ "type": "string"
+ },
+ "claims": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "claim_id": {
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+ },
+ "host_evidence": {
+ "default": [],
+ "items": {
+ "maxLength": 400,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 60,
+ "type": "array"
+ },
+ "kinds": {
+ "items": {
+ "enum": [
+ "happy-path",
+ "failure-path",
+ "boundary",
+ "lifecycle",
+ "provenance",
+ "integration"
+ ],
+ "type": "string"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ },
+ "lifecycle_stage": {
+ "default": "",
+ "maxLength": 120,
+ "type": "string"
+ },
+ "observable_acceptance": {
+ "description": "How anyone else would tell whether this claim holds. Not 'it works' — the observation that decides it.",
+ "maxLength": 2000,
+ "minLength": 10,
+ "type": "string"
+ },
+ "owned_capabilities": {
+ "default": [],
+ "items": {
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 60,
+ "type": "array"
+ },
+ "requirement": {
+ "default": "required",
+ "description": "Optional claims may remain incomplete without blocking green — but only if they were marked optional before the build began.",
+ "enum": [
+ "required",
+ "optional"
+ ],
+ "type": "string"
+ },
+ "statement": {
+ "description": "What the capability does, stated so it can be observed.",
+ "maxLength": 2000,
+ "minLength": 10,
+ "type": "string"
+ }
+ },
+ "required": [
+ "claim_id",
+ "statement",
+ "kinds",
+ "observable_acceptance"
+ ],
+ "type": "object"
+ },
+ "maxItems": 200,
+ "minItems": 1,
+ "type": "array"
+ },
+ "contract_version": {
+ "const": "SHPBL-CAPABILITY-CONTRACT/1.0.0",
+ "default": "SHPBL-CAPABILITY-CONTRACT/1.0.0",
+ "type": "string"
+ },
+ "failure_behavior": {
+ "description": "What it does when it cannot do what it promised. Silence is not failure behaviour.",
+ "maxLength": 4000,
+ "minLength": 10,
+ "type": "string"
+ },
+ "host_behaviors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "behavior": {
+ "description": "What the host repository already does, in behavioural terms.",
+ "maxLength": 2000,
+ "minLength": 10,
+ "type": "string"
+ },
+ "must_preserve": {
+ "default": "",
+ "description": "The mechanics of this host behaviour the artifact must actually reconstruct, not merely reference.",
+ "maxLength": 2000,
+ "type": "string"
+ },
+ "source_lines": {
+ "default": [],
+ "items": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "maxItems": 60,
+ "type": "array"
+ },
+ "source_paths": {
+ "description": "The host files this behaviour was read from. A behaviour with no cited path is prose, not evidence.",
+ "items": {
+ "maxLength": 400,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 60,
+ "minItems": 1,
+ "type": "array"
+ },
+ "source_symbols": {
+ "default": [],
+ "description": "The functions, classes or exports inside those files, where you can name them.",
+ "items": {
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 60,
+ "type": "array"
+ }
+ },
+ "required": [
+ "behavior",
+ "source_paths"
+ ],
+ "type": "object"
+ },
+ "maxItems": 60,
+ "minItems": 1,
+ "type": "array"
+ },
+ "host_repository": {
+ "maxLength": 300,
+ "minLength": 3,
+ "type": "string"
+ },
+ "inputs": {
+ "items": {
+ "maxLength": 400,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 80,
+ "minItems": 1,
+ "type": "array"
+ },
+ "lifecycle_stages": {
+ "default": [],
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "entered_from": {
+ "default": "",
+ "maxLength": 120,
+ "type": "string"
+ },
+ "stage": {
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+ },
+ "what_happens": {
+ "maxLength": 1000,
+ "minLength": 5,
+ "type": "string"
+ }
+ },
+ "required": [
+ "stage",
+ "what_happens"
+ ],
+ "type": "object"
+ },
+ "maxItems": 40,
+ "type": "array"
+ },
+ "optional_enhancements": {
+ "default": [],
+ "description": "Declared before the build. An enhancement invented afterwards to explain a gap is not optional, it is missing.",
+ "items": {
+ "maxLength": 600,
+ "minLength": 3,
+ "type": "string"
+ },
+ "maxItems": 60,
+ "type": "array"
+ },
+ "outputs": {
+ "items": {
+ "maxLength": 400,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 80,
+ "minItems": 1,
+ "type": "array"
+ },
+ "owned_capabilities": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "capability_id": {
+ "maxLength": 200,
+ "minLength": 2,
+ "type": "string"
+ },
+ "primitive": {
+ "default": "",
+ "maxLength": 80,
+ "type": "string"
+ },
+ "role": {
+ "default": "support",
+ "enum": [
+ "lead",
+ "support"
+ ],
+ "type": "string"
+ },
+ "unit_class": {
+ "default": "UNKNOWN",
+ "enum": [
+ "PURE",
+ "SEAMED",
+ "PORTED",
+ "UNKNOWN"
+ ],
+ "type": "string"
+ },
+ "what_it_contributes": {
+ "default": "",
+ "maxLength": 2000,
+ "type": "string"
+ }
+ },
+ "required": [
+ "capability_id"
+ ],
+ "type": "object"
+ },
+ "maxItems": 60,
+ "minItems": 1,
+ "type": "array"
+ },
+ "provenance_behavior": {
+ "description": "What lineage the artifact itself records at runtime, and what it can answer about where it came from.",
+ "maxLength": 4000,
+ "minLength": 10,
+ "type": "string"
+ },
+ "seams": {
+ "default": [],
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "enum": [
+ "state",
+ "io",
+ "model",
+ "randomness",
+ "network",
+ "filesystem",
+ "persistence",
+ "time",
+ "concurrency"
+ ],
+ "type": "string"
+ },
+ "port": {
+ "default": "",
+ "maxLength": 200,
+ "type": "string"
+ },
+ "test_strategy": {
+ "default": "recorded",
+ "enum": [
+ "real",
+ "recorded",
+ "injected-fake"
+ ],
+ "type": "string"
+ },
+ "what": {
+ "maxLength": 1000,
+ "minLength": 5,
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "what"
+ ],
+ "type": "object"
+ },
+ "maxItems": 40,
+ "type": "array"
+ }
+ },
+ "required": [
+ "artifact_id",
+ "capability_name",
+ "behavioral_promise",
+ "host_repository",
+ "host_behaviors",
+ "owned_capabilities",
+ "inputs",
+ "outputs",
+ "failure_behavior",
+ "provenance_behavior",
+ "claims"
+ ],
+ "type": "object"
+}Input schema / properties / intent / properties / reuse_declarationAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "carry_into_artifact": {
+ "default": [],
+ "description": "The licence and notice files copied into the artifact's `LICENSES/` folder.",
+ "items": {
+ "maxLength": 400,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 40,
+ "type": "array"
+ },
+ "declaration_version": {
+ "const": "SHPBL-REUSE-DECLARATION/1.0.0",
+ "default": "SHPBL-REUSE-DECLARATION/1.0.0",
+ "type": "string"
+ },
+ "declared_by": {
+ "description": "The person who made that declaration. A model, an agent, a policy or a default is refused.",
+ "maxLength": 160,
+ "minLength": 2,
+ "type": "string"
+ },
+ "license": {
+ "description": "The licence as detected in the tree or as stated by the upstream project — e.g. `MIT`, `Apache-2.0`, `AGPL-3.0`.",
+ "maxLength": 200,
+ "minLength": 2,
+ "type": "string"
+ },
+ "license_files": {
+ "default": [],
+ "description": "The licence and notice files found in the scoped tree.",
+ "items": {
+ "maxLength": 400,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 40,
+ "type": "array"
+ },
+ "note": {
+ "default": "",
+ "maxLength": 2000,
+ "type": "string"
+ },
+ "obligations": {
+ "default": [],
+ "description": "What must be preserved: attribution, notice retention, source disclosure, licence propagation.",
+ "items": {
+ "maxLength": 600,
+ "minLength": 2,
+ "type": "string"
+ },
+ "maxItems": 40,
+ "type": "array"
+ },
+ "reuse_permitted": {
+ "description": "The human declaration. False is a legal answer and stops the composition; absent is not an answer at all.",
+ "type": "boolean"
+ },
+ "upstream_project": {
+ "description": "The project the behaviour is being reused from, as `owner/repo` or its published name.",
+ "maxLength": 300,
+ "minLength": 3,
+ "type": "string"
+ }
+ },
+ "required": [
+ "upstream_project",
+ "license",
+ "reuse_permitted",
+ "declared_by"
+ ],
+ "type": "object"
+}harvest_repo10 fields changedInput schema / properties / approve / maxItemsPrevious value: -24New value: +200Input schema / properties / carry_notice_filesAdded value: +{
+ "description": "Licence or notice files from the host that must be copied into the artifact. Detected candidates are reported to you if you omit this.",
+ "items": {
+ "maxLength": 300,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 40,
+ "type": "array"
+}Input schema / properties / decline / maxItemsPrevious value: -24New value: +200Input schema / properties / grants / descriptionPrevious value: -"Harvest mode: how many capability proposals to rank, 1 to 24."New value: +"Harvest mode: how many capability proposals to rank, 1 to 200. There is no fixed shallow ceiling any more — a sophisticated repository can support far more than a couple of dozen higher-order compositions, and the safeguard against a weak proposal is the approval and the Capability Contract, not a small number here."Input schema / properties / novelty_thresholdAdded value: +{
+ "description": "Harvest mode: how different a proposal must be from the higher-ranked ones already chosen, 0 to 1, measured on bound capabilities and title vocabulary. 0 suppresses only exact duplicates; 0.4 is firm de-duplication of near-identical variants.",
+ "type": "number"
+}Input schema / properties / quality_floorAdded value: +{
+ "description": "Harvest mode: drop proposals scoring below this, 0 to 1. The score is a discovery aid for ordering what to read first — it is never evidence that a capability deserves to exist.",
+ "type": "number"
+}Input schema / properties / reuse_obligationsAdded value: +{
+ "description": "The obligations the licence attaches that must be preserved in the artifact — attribution, notice retention, share-alike, and so on. Recorded against every emitted artifact and carried into its manifest.",
+ "items": {
+ "maxLength": 300,
+ "minLength": 2,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+}Input schema / properties / reuse_permittedAdded value: +{
+ "description": "Required with `approve`: the person's explicit statement that reuse of this upstream project is permitted for this composition. Absence is never a yes, and SHPBL does not infer permission from a detected licence file. Recording your declaration is not legal verification and nothing here is legal advice.",
+ "type": "boolean"
+}Input schema / properties / suppress_duplicatesAdded value: +{
+ "description": "Harvest mode: drop proposals whose emitted body is byte-identical to a higher-ranked one. Default true.",
+ "type": "boolean"
+}Input schema / properties / upstream_projectAdded value: +{
+ "description": "The upstream project the reuse is declared against. Defaults to the repository being harvested.",
+ "maxLength": 200,
+ "minLength": 2,
+ "type": "string"
+}build_intent1 field changedInput schema / properties / intent / requiredRemoved value: -[
- "build_intent_id",
- "proposed_artifact_id",
- "proposed_name",
- "proposed_type",
- "display_name",
- "what_it_gives_you",
- "why_this_repo",
- "host_repository",
- "host_source_paths",
- "host_behavior",
- "host_problem",
- "new_behavior",
- "novelty_statement",
- "planned_interface"
-]harvest_repo7 fields changedInput schema / properties / approve / descriptionPrevious value: -"Harvest mode: the grant ids the person approved. Only these are emitted. Omit it on the first call — the proposals have to be put to them first."New value: +"Harvest mode: the grant ids the person approved. Only these are emitted. Omit it on the first call — the proposals have to be put to them first. An id nobody proposed refuses the whole set rather than emitting the rest."Input schema / properties / brief / defaultRemoved value: -falseInput schema / properties / declineAdded value: +{
+ "description": "Harvest mode: the grant ids the person explicitly said no to. Only these are recorded as declined; anything they were not asked about stays open and is re-offered, never written down as a refusal.",
+ "items": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 24,
+ "type": "array"
+}Input schema / properties / mode / defaultRemoved value: -"harvest"Input schema / properties / mode / descriptionPrevious value: -"`harvest` (default) is the shortcut: proposals, your decision, then the seed modules for what you approved. `walk` is the older batched ledger walk of the whole tree, which reads and classifies but composes nothing."New value: +"`harvest` (the default when nothing else in the call implies a walk) is the shortcut: proposals, your decision, then the seed modules for what you approved. `walk` is the older batched ledger walk of the whole tree, which reads and classifies but composes nothing. Send it explicitly whenever you also send `part`, `ledger_digest`, `budget` or `brief`."Input schema / properties / part / defaultRemoved value: -1Input schema / properties / part / descriptionPrevious value: -"Which batch to return, 1 to 2000. Batch 1 carries the protocol and the manifest; walk them all in order."New value: +"Walk mode only: which batch to return, 1 to 2000. Batch 1 carries the protocol and the manifest; walk them all in order."harvest_repo2 fields changedInput schema / properties / cml_licenseAdded value: +{
+ "description": "Your perpetual copy's licence key, if you hold one. It changes retention, never depth.",
+ "maxLength": 200,
+ "minLength": 4,
+ "type": "string"
+}Input schema / properties / governor_keyAdded value: +{
+ "description": "Operator passphrase for SHPBL's own copy. Resolved by the server; it changes only where the harvest is staged, never what is proposed.",
+ "maxLength": 300,
+ "minLength": 8,
+ "type": "string"
+}harvest_repo8 fields changedInput schema / properties / approveAdded value: +{
+ "description": "Harvest mode: the grant ids the person approved. Only these are emitted. Omit it on the first call — the proposals have to be put to them first.",
+ "items": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 24,
+ "type": "array"
+}Input schema / properties / approved_byAdded value: +{
+ "description": "The name of the person who approved them. Required with `approve`. An agent, a model, a vendor, a policy or a default is refused, not recorded.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / brief / descriptionPrevious value: -"Skip the harvest protocol preamble on batch 1 and spend the payload on source. Use it once you already hold the method — `method_protocol` (free) returns it verbatim."New value: +"Walk mode only: skip the harvest protocol preamble on batch 1 and spend the payload on source. Use it once you already hold the method — `method_protocol` (free) returns it verbatim."Input schema / properties / grantsAdded value: +{
+ "default": 8,
+ "description": "Harvest mode: how many capability proposals to rank, 1 to 24.",
+ "type": "number"
+}Input schema / properties / host_licenseAdded value: +{
+ "description": "What the target repository's licence permits for this reuse, and any obligation it attaches — for example `MIT, attribution required`. Required with `approve`; SHPBL records your declaration and does not verify it.",
+ "maxLength": 400,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / modeAdded value: +{
+ "default": "harvest",
+ "description": "`harvest` (default) is the shortcut: proposals, your decision, then the seed modules for what you approved. `walk` is the older batched ledger walk of the whole tree, which reads and classifies but composes nothing.",
+ "enum": [
+ "harvest",
+ "walk"
+ ],
+ "type": "string"
+}Input schema / properties / pagesAdded value: +{
+ "default": 4,
+ "description": "Harvest mode: how many source pages to read for evidence, 1 to 12 (about 90,000 characters each). Proposals are cut only from what was actually read.",
+ "type": "number"
+}Input schema / properties / per_affordanceAdded value: +{
+ "default": 2,
+ "description": "Harvest mode: how many proposals one host affordance may produce, 1 to 4.",
+ "type": "number"
+}library_search1 field changedInput schema / properties / scope / descriptionPrevious value: -"`catalog` — engineered components (Practitioner). `vault` — discovery-engine pipelines. `crown-jewels` — the S-Tier Vault of standalone lab-curated artifacts. `composites` — capabilities past runs invented for one host."New value: +"`catalog` — engineered components (Practitioner). `crown-jewels` — the S-Tier Vault of standalone lab-curated artifacts. `composites` — capabilities past runs invented for one host. (`vault` is no longer available; asking for it returns a pointer to these scopes.)"library_index2 fields changedInput schema / properties / sections / descriptionPrevious value: -"Which sections to return. Omit for all of them: facts, volumes, editions, downloads, case_studies."New value: +"Which sections to return. Omit for all of them: facts, volumes, editions, downloads, case_studies, pools. `pools` is the canonical reconciliation of every count this server quotes — read it before comparing two totals."Input schema / properties / sections / items / enumPrevious value: -[
- "facts",
- "volumes",
- "editions",
- "downloads",
- "case_studies"
-]New value: +[
+ "facts",
+ "volumes",
+ "editions",
+ "downloads",
+ "case_studies",
+ "pools"
+]run_gauntlet1 field changedInput schema / properties / personality / descriptionPrevious value: -"How the person wants to be spoken to for this run: technical, professional, friendly, light, coach, deadpan. Ask them once before step 0 and pass what they choose; it rides the run and changes wording only, never a finding, a state or a gate. Defaults to professional when they have no preference."New value: +"How the person wants to be spoken to for this run: technical, professional, friendly, light, coach, deadpan. Ask them once before step 0 and pass what they choose; it rides the run and changes wording only, never a finding, a state or a gate. Defaults to professional when they have no preference. Pass `none` to switch the voice off entirely — bare wording, no openers, no asides — which is the right setting for an automated reviewer reading the run as evidence."build_intent2 fields changedInput schema / properties / human_decisionAdded value: +{
+ "additionalProperties": false,
+ "description": "The person's decision on this proposal. Step 9 is a blocking checkpoint: without an attributed human decision this tool returns the words to say and nothing else, and you end your turn there. Do not send a decision the person did not make.",
+ "properties": {
+ "decided_by": {
+ "description": "The person who made this decision, as they identify themselves. An agent, a model, a policy or a default is not a person and is refused.",
+ "maxLength": 120,
+ "type": "string"
+ },
+ "decision": {
+ "description": "Exactly one of APPROVED, DECLINED, NEEDS_EXPLANATION, NOT_YET_ASKED or HUMAN_APPROVAL_DELEGATED. Use NOT_YET_ASKED while you have not put the proposal to the person — never DECLINED, which is their answer, not the absence of one.",
+ "maxLength": 40,
+ "minLength": 3,
+ "type": "string"
+ },
+ "delegation_scope": {
+ "description": "For HUMAN_APPROVAL_DELEGATED only: the authority the named person delegated for this run. Delegation without a scope is refused.",
+ "maxLength": 600,
+ "type": "string"
+ },
+ "reason": {
+ "description": "What they said, where they gave a reason. Recorded verbatim in BUILD-APPROVAL.json.",
+ "maxLength": 2000,
+ "type": "string"
+ }
+ },
+ "required": [
+ "decision"
+ ],
+ "type": "object"
+}Input schema / properties / intent / properties / opportunity_idAdded value: +{
+ "maxLength": 120,
+ "type": "string"
+}run_gauntlet1 field changedInput schema / properties / personalityAdded value: +{
+ "description": "How the person wants to be spoken to for this run: technical, professional, friendly, light, coach, deadpan. Ask them once before step 0 and pass what they choose; it rides the run and changes wording only, never a finding, a state or a gate. Defaults to professional when they have no preference.",
+ "maxLength": 40,
+ "type": "string"
+}build_intent5 fields changedInput schema / properties / intent / descriptionPrevious value: -"The Build Intent record; every field it asks for is part of the evidence, and each field carries its own description in this schema. Required: `build_intent_id`, `proposed_artifact_id`, `proposed_name`, `proposed_type`, `host_repository`, `host_source_paths`, `host_behavior`, `host_problem`, `new_behavior`, `novelty_statement`, `planned_interface`. Tests are mandatory in effect: at least one entry across `planned_unit_tests`, `planned_behavior_tests` and `planned_integration_tests` (the aliases `planned_tests`, `unit_tests`, `behavior_tests` and `integration_tests` are folded into those three). Every path in `host_source_paths` is resolved against the real tree before anything is authorised — a path that is not there refuses the intent."New value: +"The Build Intent record; every field it asks for is part of the evidence, and each field carries its own description in this schema. Required: `build_intent_id`, `proposed_artifact_id`, `proposed_name`, `display_name`, `what_it_gives_you`, `why_this_repo`, `proposed_type`, `host_repository`, `host_source_paths`, `host_behavior`, `host_problem`, `new_behavior`, `novelty_statement`, `planned_interface`. `display_name`, `what_it_gives_you` and `why_this_repo` are quality gates, not presentation: if you cannot name the software and say what new ability it gives this repository and why this repository, the proposal is refused. Tests are mandatory in effect: at least one entry across `planned_unit_tests`, `planned_behavior_tests` and `planned_integration_tests` (the aliases `planned_tests`, `unit_tests`, `behavior_tests` and `integration_tests` are folded into those three). Every path in `host_source_paths` is resolved against the real tree before anything is authorised — a path that is not there refuses the intent."Input schema / properties / intent / properties / display_nameAdded value: +{
+ "maxLength": 120,
+ "minLength": 3,
+ "type": "string"
+}Input schema / properties / intent / properties / what_it_gives_youAdded value: +{
+ "maxLength": 2000,
+ "minLength": 25,
+ "type": "string"
+}Input schema / properties / intent / properties / why_this_repoAdded value: +{
+ "maxLength": 2000,
+ "minLength": 25,
+ "type": "string"
+}Input schema / properties / intent / requiredPrevious value: -[
- "build_intent_id",
- "proposed_artifact_id",
- "proposed_name",
- "proposed_type",
- "host_repository",
- "host_source_paths",
- "host_behavior",
- "host_problem",
- "new_behavior",
- "novelty_statement",
- "planned_interface"
-]New value: +[
+ "build_intent_id",
+ "proposed_artifact_id",
+ "proposed_name",
+ "proposed_type",
+ "display_name",
+ "what_it_gives_you",
+ "why_this_repo",
+ "host_repository",
+ "host_source_paths",
+ "host_behavior",
+ "host_problem",
+ "new_behavior",
+ "novelty_statement",
+ "planned_interface"
+]evaluate_repo1 field changedInput schema / properties / sectionsAdded 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"
+}run_contract1 field changedInput schema / properties / files / descriptionPrevious value: -"The run bundle as `path: text`, relative to the run folder (for example `STEP-LEDGER.json`). Send the canonical outputs you have; the gate says what is missing. Omit this to read the contract without evaluating anything."New value: +"The run bundle as `path: text`, relative to the run folder (for example `STEP-LEDGER.json`). Send the canonical outputs you have; the gate says what is missing. Bounded: at most 400 entries and 8 MB of text in one call, and identical diagnostics are collapsed to one line with a count rather than repeated per entry. Omit this to read the contract without evaluating anything."build_intent3 fields changedInput schema / properties / github_tokenAdded value: +{
+ "description": "Optional GitHub token (Contents: read) so the gate can read the host tree and prove the cited paths exist. Not needed if you pass `host_source_manifest`.",
+ "maxLength": 300,
+ "minLength": 8,
+ "type": "string"
+}Input schema / properties / host_source_manifestAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 4000000,
+ "minLength": 2,
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "type": "object"
+ }
+ ],
+ "description": "The `HOST-SOURCE-MANIFEST.json` from `pin_source` or `tools/source-manifest.mjs`, as JSON text or an object. Offline runs must send this: the gate recomputes its digest and resolves every cited path against its entries. An edited or invented digest is refused."
+}Input schema / properties / intent / descriptionPrevious value: -"The Build Intent record; every field it asks for is part of the evidence, and each field carries its own description in this schema. Required: `build_intent_id`, `proposed_artifact_id`, `proposed_name`, `proposed_type`, `host_repository`, `host_source_paths`, `host_behavior`, `host_problem`, `new_behavior`, `novelty_statement`, `planned_interface`. Tests are mandatory in effect: at least one entry across `planned_unit_tests`, `planned_behavior_tests` and `planned_integration_tests` (the aliases `planned_tests`, `unit_tests`, `behavior_tests` and `integration_tests` are folded into those three)."New value: +"The Build Intent record; every field it asks for is part of the evidence, and each field carries its own description in this schema. Required: `build_intent_id`, `proposed_artifact_id`, `proposed_name`, `proposed_type`, `host_repository`, `host_source_paths`, `host_behavior`, `host_problem`, `new_behavior`, `novelty_statement`, `planned_interface`. Tests are mandatory in effect: at least one entry across `planned_unit_tests`, `planned_behavior_tests` and `planned_integration_tests` (the aliases `planned_tests`, `unit_tests`, `behavior_tests` and `integration_tests` are folded into those three). Every path in `host_source_paths` is resolved against the real tree before anything is authorised — a path that is not there refuses the intent."library_search2 fields changedInput schema / properties / page_size / defaultRemoved value: -20Input schema / properties / page_size / descriptionPrevious value: -"Rows per page, 1 to 50."New value: +"Rows per page, 1 to 50. Defaults to 20."run_contractAudit GitHub repos for malicious and supply-chain code before you depend on them.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Security + bug + perf + refactor audit for Python. Returns 0-10 score + MD report.
Free deterministic security scan of public git repos: OSV.dev vulnerable deps, secrets, config lint.
Add one secure layer between your agents and this server.
