Audit and repair any public GitHub repo. Free survey; paid source, unified diffs and a pull request.
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. 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?
The description is unusually rich about the human-decision block, valid terminal states, attribution requirements, and successful DECLINED/NEEDS_EXPLANATION outcomes. However, it says 'Register one Build Intent', instructs the agent to 'record them', and the human_decision.reason schema says the reason is 'Recorded verbatim in BUILD-APPROVAL.json' — while the annotations declare readOnlyHint=true. This is a direct annotation contradiction, so per the rubric the score is 1.
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 information-packed with little filler, but it is delivered as a long run-on paragraph with a very long noun-list sentence and all-caps directives. It is front-loaded with the core purpose, but bullet structure would have made the blocking and success-state behaviors far easier for an agent to parse.
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 complex gate tool with no output schema, the description covers the mechanical verdict fields (invariants passed, license basis, execution authority, terminal state, artifact destination) and the no-human-decision blocked response. Combined with the fully described input schema, the agent has almost everything needed to invoke 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic framing beyond the schema: it groups intent fields as evidence (what was found, what SHPBL already has, what new capability appears, why neither parent alone, what tests would prove it) and stresses the quality-gate and path-resolution behaviors. It still leaves exact field syntax to the schema, which 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+resource: 'Register one Build Intent', and positions it as 'the gate between discovery and creation'. It is explicitly distinguished from creation/compilation siblings by the rule that every COMPOSE, SPECIALIZE and CREATE must pass through this tool first.
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 clearly states when this tool is mandatory: before any source is written, and before every COMPOSE, SPECIALIZE or CREATE. It also gives the blocking checkpoint behavior and when to stop and wait for a human. It does not explicitly name the alternative tool to call after approval, so it stops short of full when-not/alternative routing.
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 Capability Grants 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 grant names the host evidence it mounts on, the exact capability bodies bound into it (with class PURE, SEAMED or PORTED and every declared port), a seed module containing those harvested bodies, the wiring and verification the caller's own agent must complete, and the honest limits. This is not repair and not a defect scan; no grant is finished application code. Deterministic: the same tree yields the same grants and the same seal. Free calls return the affordances read and the offerable census, then stop at the composition boundary; grants 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 Capability Grants to return, 1 to 24. 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 grants one affordance may produce, 1 to 4. 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 supply readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavior beyond those: deterministic output ('the same tree yields the same grants and the same seal'), the free-call stopping point, and the Practitioner key requirement. It also clarifies that nothing written is finished application code, which is consistent with readOnlyHint.
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 information-dense and mostly purposeful, with useful details on grants, determinism, and authorization. However, it is jargon-heavy — 'harvest lane,' 'canonical forty,' 'S-Tier artifacts' — and is not front-loaded around the primary action. It earns a 3 for structure.
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?
There is no output schema, so the description carries the burden of explaining return behavior, and it does: free calls return affordances and the offerable census, while paid calls return grants with host evidence, bound capability bodies, seed modules, wiring, verification steps, and limits. It is adequate for a complex tool, though the exact output shape remains somewhat fuzzy.
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 input schema already documents all seven parameters. The description adds flavor like grants being 'cut from whatever was read,' but it does not add parameter-specific semantic detail beyond the schema. 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 states a specific workflow: read repository affordances and offer Capability Grants that fuse them with SHPBL primitives. It also explicitly says it is not repair and not a defect scan, which differentiates it from fix/evaluate siblings. However, the 'compose into a repository' title and 'harvest lane' jargon make the core action slightly less crisp than it could be.
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 clear when-not-to-use signals: 'This is not repair and not a defect scan; no grant is finished application code.' It also explains the free-vs-paid boundary: free calls stop at the composition boundary, while grants require a Practitioner key. It does not name a specific sibling to use instead, but the exclusions are actionable.
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.
Stage three of a SHPBL repository audit — the harvest: walk an entire repository in batches under a hard character ceiling and fold it into a sealed capability ledger. Batch 1 carries the protocol and the full path-to-batch manifest; later batches carry source only. Pass estimate: true to size a scope before walking it, and ledger_digest to resume a walk in a fresh session. Your own model composes the ledger. Free runs walk the whole tree and seal the ledger of the repository's own capabilities, then stop at the composition boundary — no library search, no candidates, no dispositions. Composition and write-back 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. | |
| part | No | 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 | 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. | |
| 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. | |
| 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. | |
| github_token | No | Optional GitHub token (Contents: read) for a private repository. Not needed if the SHPBL GitHub App is connected to this key. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral detail beyond those: batch 1 carries the protocol and manifest while later batches are source-only; there is a hard character ceiling with plain refusal of out-of-range budgets; `ledger_digest` resumes a prior walk; composition and write-back require a Practitioner key; and free runs stop at the composition boundary. This is rich, non-obvious behavior that an agent needs to know before invoking 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 longer than average but each sentence carries information: stage context, batch composition, estimate behavior, resume behavior, free-tier limits, and authentication. It is front-loaded with the core purpose and then builds outward. Minor redundancy exists around the 'character ceiling' and 'budget' concepts, but overall it is dense without being bloated.
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 9-parameter tool with no output schema, the description covers what an agent needs: what a run returns (protocol, manifest, source batches), how to size a scope first, how to resume across sessions, what free runs do, what requires a key, and how budget limits are enforced. The workflow sequence from estimate to walk to composition/write-back is fully described, so an agent can invoke the tool correctly with minimal guesswork.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining how parameters fit together in the workflow: `estimate` sizes a scope before walking, `ledger_digest` resumes a session, `brief` skips the protocol once the method is already held, and `budget` has a nuanced default/clamping behavior. This goes beyond the individual schema descriptions and helps an agent decide parameter values in context.
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 — 'Stage three of a SHPBL repository audit — the harvest: walk an entire repository in batches ... and fold it into a sealed capability ledger.' This clearly distinguishes harvest_repo from sibling tools like library_search, evaluate_repo, and write_to_repo. It also explains the batch structure and the eventual ledger output, leaving no ambiguity about what the tool 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 establishes a clear workflow context: stage three of a multi-stage audit, with `estimate: true` for sizing a scope and `ledger_digest` for resuming a walk. It explicitly states what free runs do and what they stop at ('no library search, no candidates, no dispositions'), implicitly contrasting it with related siblings. It does not name an explicit alternative tool for when to use something else, but the workflow placement and boundary statements provide strong usage guidance.
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. 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. | |
| 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 declare read-only and idempotent behavior; the description adds that the call returns everything in one read unless scoped, and that it is free with no key or allowance. This is meaningful operational context beyond the structured annotations. No contradiction with 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?
Three short sentences handle purpose, usage, and access with no filler. The first sentence front-loads the resource and scope, the second explains filtering, and the third closes with authorization requirements.
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 index with no output schema, the description covers return content categories, filtering modes, and auth requirements. The full-text routing to library_document appears in the schema's volume parameter, rounding out the agent-facing picture.
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 covers all three parameters at 100%, so the baseline is 3. The description adds output-level semantics tied to sections—prices and licences, seals and read links, byte sizes, and verdicts—which enriches what each section will contain without repeating 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 names a specific action ('in one read') and a concrete resource ('everything published on shpbl.com'), then enumerates the exact content categories. The 'one read' framing clearly distinguishes it from the full-text/search siblings, even without naming them.
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 clearly explains how to scope the tool via sections, volume, or case_study, which implies the main use cases. However, it does not explicitly say when to prefer library_search or library_document, so alternative selection is left mostly to inference.
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: "vault" searches the discovery-engine index of build-checked syntheses. 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). `vault` — discovery-engine pipelines. `crown-jewels` — the S-Tier Vault of standalone lab-curated artifacts. `composites` — capabilities past runs invented for one host. | 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?
Beyond the read-only, idempotent, and open-world annotations, the description discloses real search behavior: multi-word queries are matched term by term and ranked, near-misses return closest rows labeled as such, and ids return whole rows with sibling/twin relationships. It also characterizes each scope's provenance without contradicting 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 description is compact and front-loaded: the first sentence gives purpose and timing, and the following sentences systematically cover scopes, id lookup, and matching behavior. Every sentence contributes distinct information, and the length is appropriate for a tool with four scopes and 11 parameters.
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 search tool with no output schema, the description provides enough context to invoke it correctly: how queries behave, what ids does, and what each scope represents. The well-described schema covers pagination, auth, and scope-specific filters, leaving no critical invocation gap. The only minor ambiguity, what 'declared twins' means, is acceptable given the rest of the context.
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 documents all 11 parameters thoroughly, so the baseline is 3. The description adds value by clarifying query semantics ('match term by term and rank', closest-row fallback) and by explaining that ids returns full rows with siblings and declared twins. These details go beyond the schema notes without needing to repeat every field.
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 and resource: 'Search the Collective Master Library for a capability in plain words, before writing new code,' and enumerates the catalog, vault, and composites scopes. It is clearly a search/lookup operation rather than a construction or mutation tool, but it never explicitly contrasts itself with related siblings such as library_document or 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?
The first sentence gives a concrete trigger: search the library before writing new code. The scope descriptions further tell the agent which library segment each enum value addresses, and the ids mode gives an alternative lookup path. It lacks explicit 'when not to use' guidance or named alternatives such as 'use library_index instead.'
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 a connected run and an offline run cannot disagree about whether a run is finished. 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?
The description goes well beyond the annotations by explaining that the tool is stateless, unmetered, bounded in input size, and collapses identical diagnostics. It also reveals the consistency guarantee with the offline `tools/run-gate.mjs`, which is important behavioral information an agent could not derive from annotations or schema alone.
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 longer than average but each sentence adds meaningful information: modes, output semantics, limits, consistency, and usage directive. It is front-loaded with the core purpose, though a few phrases could be tightened without loss.
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 adequately explains what the agent will receive in both modes: the contract details when no files are passed, and the blocking step, refused predicate, and reason when files are passed. It also covers input bounds, statelessness, and the correct agent behavior, making it complete for reliable invocation.
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 reiterates that `files` is a map of run-folder paths to text and that omitting it reads the contract, but it does not add substantial new parameter semantics beyond what the schema already provides.
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: 'Read the canonical twelve-step run contract, or check a run bundle against it.' It also distinguishes the two main modes of the tool. It does not explicitly differentiate from sibling tools such as run_gauntlet, so it falls just short of 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 provides clear usage context: call with no `files` to read the contract, call with `files` to evaluate a run bundle. It also gives a strong directive: 'Never infer a step, reorder one, or declare a run finished on your own reading — run the gate and report its word.' It does not mention alternatives or exclusions explicitly, so it is not a 5.
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. | |
| 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?
Adds substantial behavior beyond the annotations: no skipping steps, no inferring findings, mandatory ledger_digest from step 2, fold-token integrity, check-ins every 3 steps, and Practitioner-key gating. It also clarifies that the tool itself does not write; the calling model performs reading and writing, which keeps the readOnlyHint honest.
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 every sentence carries operational weight; the strict sequence is front-loaded and called out in caps. It could be slightly better structured with bullets, but there is no filler.
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 orchestration tool with no output schema, the description covers the full calling protocol: auth, step progression, checkpoint gates, token/ledger integrity, human-approval requirements, and the final handoff. Nothing an agent needs to drive the gauntlet correctly appears to be 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 coverage is already 100%, but the description adds dynamic ordering semantics the schema cannot express: no step returns the run card, ledger_digest becomes mandatory at step 2, continue_ack is required only after checkpoint approval, and checkpoint_interval should only be raised on request. These procedural rules materially increase correct invocation.
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 and resource: a single runner for an entire SHPBL repository audit and repair, with an explicit phase list. It also distinguishes itself from the free evaluation lane, so an agent can tell it apart from the targeted 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?
Provides strong usage context: Practitioner key required, the free lane only offers repository evaluation, strict one-step-per-turn sequencing, and checkpoints requiring human approval. It does not explicitly name a sibling tool as the alternative, but the routing condition is clear enough.
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 and discovery-vault 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?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the operation is free, unmetered, writes nothing, and calls no model. It also specifies exactly what is checked: tool surface vs. tier table, version agreement, subscription-register reachability, catalog/discovery reachability, repository-write authority, and billing wiring.
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 front-loaded with the core purpose and output shape, then lists the verification axes, then states side-effect guarantees, then gives usage guidance. Every sentence carries distinct useful information, and the structure is easy for an agent to parse.
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 adequately explains the return shape: one pass/fail/unavailable line per verification axis, with the axis list enumerated. It also covers side effects, cost, model usage, and recommended invocation contexts. An agent has enough information to select and call this 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?
The single optional verbose parameter is already fully described in the input schema with its default and effect. The main description adds context about the per-axis output, which indirectly clarifies what verbose would expand, but it does not need to repeat the schema's parameter documentation. Baseline 3 is appropriate because schema coverage is 100%.
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 runs SHPBL's own audit against the running server and returns per-axis pass/fail/unavailable lines. It is unmistakably distinct from the sibling repo, library, subscription, and mutation tools because it is a diagnostic read-only audit of the server surface itself.
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: 'prove the server is live and consistent before starting a run, or when a tool answered in a way that looks wrong.' It does not list when-not-to-use or alternatives, but the sibling tools are clearly different operations, so the intended context is well established.
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. 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.
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?
Annotations only supply hints; the description carries the behavioral burden and does so thoroughly. It discloses that nothing is pushed to the default branch, that auth can be a SHPBL key plus GitHub App or a one-off token, that the server never reads repos the caller has no right to read, that composites stay private, and that build artifacts are only landed with signed authorization. This far exceeds the annotation hints.
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 long but well structured: the core action is front-loaded, followed by auth, then file placement, then the library index contract, then the repair exception. It earns most of its length given 11 parameters and complex privacy/build rules, though some points are reiterated from the schema, such as full contents rather than diffs.
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?
The description covers the operational essentials: auth, repository selection, branch/run_id behavior, file placement, privacy boundaries, and build authorization. With no output schema, it could have named the return value, such as the PR URL or number, but for a complex write tool the description is otherwise comprehensive.
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 baseline is 3, but the description adds real semantic value beyond the schema: it clarifies that files must be full new contents rather than diffs, that run_id/branch reuse updates the same PR, that repository choice must never be assumed, and that repairs write outside .shpbl/. It does not individually elaborate every parameter, but it complements the schema meaningfully.
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 action and resource: "Land finished work in a repository as a pull request" and explains that passing full file contents opens a branch and PR. It clearly distinguishes this write/PR-creation tool from read-oriented siblings such as evaluate_repo or list_repos by emphasizing the PR outcome and the 'nothing pushed to default branch' guarantee.
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 clear usage context: use it to land finished work via a PR, pass full new contents rather than diffs, and let a human review and merge. It also provides concrete guidance such as 'ask which one, or call list_repos first; never assume' and 'Repairs are the exception'. It does not explicitly enumerate when not to use this tool versus each sibling, but the operational context is strong.
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. Dates show when Glama detected each change.
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_contractcompose_capabilitypin_sourcebuild_intent9 fields changedInput schema / properties / intent / descriptionPrevious value: -"The Build Intent record. Every field it asks for is part of the evidence."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)."Input schema / properties / intent / properties / behavior_testsAdded value: +{
+ "description": "Alias for `planned_behavior_tests`.",
+ "items": {
+ "maxLength": 400,
+ "type": "string"
+ },
+ "maxItems": 100,
+ "type": "array"
+}Input schema / properties / intent / properties / behaviour_testsAdded value: +{
+ "description": "Alias for `planned_behavior_tests`.",
+ "items": {
+ "maxLength": 400,
+ "type": "string"
+ },
+ "maxItems": 100,
+ "type": "array"
+}Input schema / properties / intent / properties / integration_testsAdded value: +{
+ "description": "Alias for `planned_integration_tests`.",
+ "items": {
+ "maxLength": 400,
+ "type": "string"
+ },
+ "maxItems": 100,
+ "type": "array"
+}Input schema / properties / intent / properties / planned_behavior_tests / descriptionAdded value: +"The behaviour tests that would prove it."Input schema / properties / intent / properties / planned_integration_tests / descriptionAdded value: +"The integration tests that would prove it."Input schema / properties / intent / properties / planned_testsAdded value: +{
+ "description": "Alias. An unclassified list of planned tests: each entry is filed as unit, behaviour or integration from its own wording, and counts towards the test invariant.",
+ "items": {
+ "maxLength": 400,
+ "type": "string"
+ },
+ "maxItems": 300,
+ "type": "array"
+}Input schema / properties / intent / properties / planned_unit_tests / descriptionAdded value: +"The unit tests that would prove it. One of the three planned-test arrays must be non-empty or the gate fails."Input schema / properties / intent / properties / unit_testsAdded value: +{
+ "description": "Alias for `planned_unit_tests`.",
+ "items": {
+ "maxLength": 400,
+ "type": "string"
+ },
+ "maxItems": 100,
+ "type": "array"
+}library_search1 field changedInput schema / properties / certified_only / descriptionPrevious value: -"Crown jewels only: return only rows whose body the certification harness executed and read clean (CERTIFIED or PROVISIONAL). Declared, uncertified and failed rows are withheld."New value: +"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`."library_search1 field changedInput schema / properties / limitAdded value: +{
+ "description": "Alias for `page_size`, 1 to 50. Given both, `page_size` wins.",
+ "type": "number"
+}build_intentevaluate_repofix_repoharvest_repolibrary_documentlibrary_indexlibrary_searchlist_reposmethod_protocolrun_gauntletselfcheck_mcpsubscription_statuswelcomewrite_to_repoClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Audit 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.
Most tools have distinct roles, but the capability-discovery cluster is genuinely confusable: compose_capability calls itself 'the harvest lane' while harvest_repo is 'the harvest,' and evaluate_repo with a key also identifies candidates and composes — an agent must read long descriptions carefully to pick correctly. The free/key mode-switching also makes each tool's effective behavior conditional, raising misselection risk.
The dominant pattern is verb_noun (build_intent, evaluate_repo, fix_repo, harvest_repo, list_repos, pin_source, run_contract, run_gauntlet, write_to_repo), and the library_document/library_index/library_search trio follows a deliberate resource-prefix convention. A few outliers break the pattern — welcome (bare verb), selfcheck_mcp, and subscription_status — but they are a small minority and still readable.
At 17 tools the set is slightly past the ideal 3-15 range, but the domain genuinely spans an audit pipeline, a capability library, run orchestration, repo write-back, and billing/onboarding meta-tools. Roughly a third are lightweight informational endpoints (welcome, method_protocol, run_contract, library_index, subscription_status, selfcheck_mcp), which adds surface area, but each has a distinct job and none is redundant.
The lifecycle is well covered: pin_source → evaluate_repo → fix_repo → harvest_repo → compose_capability → write_to_repo, with run_gauntlet orchestrating the whole path and run_contract/method_protocol providing gates and discipline. Minor gaps exist — write_to_repo is create-only with no PR update/merge/close, and past run state is only resumable via ledger_digest — but there are no dead ends.
