The SSWP MCP (Sovereign Software Witness Protocol) server provides deterministic software attestation, supply-chain risk analysis, fleet registry management, and tamper-proof auditing for software repositories. It operates as an MCP server, allowing AI agents (Claude, VS Code Copilot, etc.) to interact with its tools natively.
sswp_witness — Full cryptographic witness on a single repository: scans the dependency graph, runs a 5-gate pipeline (GIT_INTEGRITY, LOCKFILE, DETERMINISTIC_BUILD, TEST_PASS, LINT), adversarially probes dependencies for typosquatting/version anomalies/missing integrity hashes, and seals results into a self-verifying SHA-256-backed .sswp.json attestation.
sswp_verify — Recompute the SHA-256 signature of an existing .sswp.json to detect tampering.
sswp_bulk_witness — Run the full witness pipeline sequentially across multiple repositories in one call — ideal for nightly audits or pre-release sweeps.
sswp_check_repo — Lightweight health check (.git, package.json, package-lock.json) without a full witness run, useful as a fast CI pre-check.
sswp_analyze_deps — Analyze a list of npm packages for supply-chain risk (typosquatting, version anomalies, missing metadata integrity hashes), with optional AI-powered deep reasoning.
sswp_registry_health — Fleet health dashboard showing all witnessed nodes with status, last run time, overall risk score, and adversarial risk score, ordered by risk.
sswp_ledger — Query the append-only SHA-256 hash-chained audit ledger recording every witness run, gate vote, and probe result for compliance or incident investigation.
sswp_node_search — Full-text search (FTS5) across the fleet registry by repository name, tag, or description keyword.
Integrates with Ollama to run Kimi K2 reasoning for deeper adversarial probing of dependencies.
SSWP records what configured software checks actually establish. Its MCP and CLI entry points share one implementation and a persistent SQLite registry.
Version 2.1 fixes false Git PASS results, missing execution timeouts, source/bundle divergence, incomplete nested hashes and inconsistent ledger timestamps. Witness execution requires a short-lived operator-policy receipt from Omega Brain. Caller-supplied approval strings are no longer accepted.
Use Node 22 or newer and pnpm 11. Install with pnpm install --frozen-lockfile, run pnpm build, then start node dist/sswp.cjs. pnpm check checks TypeScript. Build receipts contain source, lockfile and artifact hashes. Native SQLite and esbuild install scripts are explicitly allowed by the workspace configuration.
Configure an absolute SSWP_DB path and the same VERITAS_SHARED_DIR used by Brain and Stenographer. Add the server command to persistent user MCP configuration. sswp_check_repo is read-only; sswp_witness runs only explicitly configured project commands, checks the receipt, writes an attestation and durably queues an event for Brain.
PASS, FAIL, ERROR, INCONCLUSIVE and NOT_APPLICABLE remain distinct. BUILD_SUCCESS and REPRODUCIBLE_BUILD are separate gates. Reproducibility requires nonempty matching outputs from two fresh source copies. sswp_verify covers nested fields in v2 attestations and reports older formats as LEGACY_UNVERIFIED; a content hash does not authenticate an author.
sswp_registry_health reports the latest run per node, timestamps, current path availability, pending materializations and delivery status. Registry writes, gate rows, ledger events and outbox jobs commit together. Committed attestations can be materialized and delivered again after interruption. Historical records remain historical.
See current operating contract for exact permission boundaries, missing-evidence behavior, dependency coverage and recovery. Tests use local synthetic projects. pnpm test additionally exercises Python-to-Node receipts when an Omega Brain checkout and .venv are present as siblings, as arranged by CI.
Analyze a list of dependencies for supply-chain risk using Kimi K2 reasoning. Provide an array of {name, version} objects for any npm packages you want evaluated. The tool performs four analysis passes: typosquatting detection (matching names against known suspicious patterns like left-pad, event-stream), version anomaly scanning (flagging unpinned ranges like *, >=, ^0), metadata integrity checks (CRITICAL if a dependency lacks an integrity hash), and optional Kimi K2 deep reasoning (requires OLLAMA_CLOUD_API_KEY — returns INCONCLUSIVE without it). Returns a JSON object with per-probe results, overall risk score (0-1), and suspicious package counts. Use this for targeted supply-chain analysis on critical dependency trees. For generating full attestations that include probing, use sswp_witness.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | Array of dependency objects to analyze. Each must include the package name and version string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness. The description adds valuable context about the optional Kimi K2 deep reasoning pass requiring OLLAMA_CLOUD_API_KEY, and that it returns INCONCLUSIVE without it. No contradictions.
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 moderately long but each sentence is informative. It is well-structured: purpose, usage, analysis passes, API key note, return format, and sibling guidance. Could be slightly more front-loaded with the API key dependency, but overall effective.
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 describes the return (JSON with per-probe results, risk score, counts) and input requirements. It covers the API key dependency and the four analysis passes, making it sufficiently complete for an analysis tool.
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. The description adds guidance that version strings should be as they appear in package-lock.json and clarifies the object structure, providing additional context beyond 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 clearly states the tool analyzes dependencies for supply-chain risk, lists four specific analysis passes, and explicitly distinguishes it from sswp_witness for attestations. It uses a specific verb ('analyze') and resource ('list of dependencies'), meeting the highest standard.
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 explicit guidance: 'Use this for targeted supply-chain analysis on critical dependency trees' and contrasts with sswp_witness. It also specifies that the tool works for npm packages and requires an API key for deep reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run deterministic attestation on multiple repositories sequentially. For each repo path provided, runs the full SSWP witness pipeline (scan, 5-gate test, adversarial probe, SHA-256 seal) and auto-saves the .sswp.json attestation to the fleet registry. Reports per-repo PASS/FAIL status with risk percentages and a final summary of passed, failed, and skipped counts. Missing repos are skipped by default. Use this for nightly fleet audits, pre-release sweeps across the ecosystem, or any batch witnessing operation. For a single repo, prefer sswp_witness.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPaths | Yes | Array of absolute paths to project root directories to witness. Each path must contain a package.json and node_modules. | |
| skipMissing | No | If true (default), skip repos that don't exist on disk and continue processing remaining repos. If false, returns an error immediately on the first missing repo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses sequential processing, auto-saving to fleet registry, per-repo status reporting, and default skip of missing repos. Annotations already provide idempotentHint, but description adds valuable behavioral context.
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 concise, well-structured, and front-loaded with the primary purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, usage, behavior, and expected output (per-repo status, summary) adequately. No output schema exists, but the description sufficiently informs the agent.
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?
Parameters are fully described in the schema (100% coverage). The description reiterates the skipMissing default but adds no new semantic details beyond 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 clearly states the tool performs deterministic attestation on multiple repositories sequentially, outlines the pipeline steps, and explicitly differentiates from the sibling 'sswp_witness' for single-repo use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (nightly fleet audits, pre-release sweeps) and provides an alternative for single repos, plus describes behavior for missing repos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a lightweight repo health check without running the full witness pipeline. Verifies four conditions: the directory exists on disk, a .git directory is present (indicating a git repository), a package-lock.json exists (indicating locked dependencies), and a package.json exists (indicating a valid Node.js project). Returns a status line for each condition and an overall READY/NOT READY verdict. Use this as a fast pre-check in CI pipelines or before calling sswp_witness to ensure the repo is in a valid state. Does not seal an attestation or modify the registry.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Absolute path to the project root directory to check. Must be a valid filesystem path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it lists the four conditions checked, explicitly states it does not seal an attestation or modify the registry, and confirms idempotency without side effects. No contradiction with annotations (readOnlyHint true, destructiveHint false, idempotentHint true).
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 four sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words or repetition.
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 tool with one parameter and no output schema, the description fully covers what the tool does, what it checks, what it returns (status lines and verdict), and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for repoPath. The tool description reinforces that it must be an absolute path to the project root, adding minimal but helpful context beyond 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 clearly states it performs a lightweight repo health check by verifying four specific conditions (directory exists, .git directory, package-lock.json, package.json) and provides a READY/NOT READY verdict. This distinguishes it from siblings like sswp_witness, which runs the full pipeline.
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 recommends use as a fast pre-check in CI pipelines or before calling sswp_witness. It does not explicitly state when not to use, but the context and sibling names imply alternatives for full attestation or other checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the tamper-proof SSWP audit ledger, an append-only SHA-256 hash chain that records every witness run, gate vote, and probe result. Returns a formatted table showing ledger entries with their sequence ID, event type (WITNESS, BULK_WITNESS), hash, and timestamp. Optionally filter by event type to narrow results. The ledger chain is cryptographically verifiable — any altered or removed entry breaks the chain. Use this for audit trail review, compliance reporting, or incident investigation. For a quick fleet overview, use sswp_registry_health instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of ledger entries to return, ordered newest first. Defaults to 20 if not specified. | |
| eventType | No | Filter entries by event type. Common values: 'WITNESS' (single repo attestation), 'BULK_WITNESS' (batch run). Omit to return all event types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds critical behavioral context: the ledger is 'append-only SHA-256 hash chain', 'cryptographically verifiable', and 'any altered or removed entry breaks the chain'. This informs the agent of immutable and security properties.
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 four sentences, front-loaded with the main action, and each sentence adds value. It is well-structured but could be slightly more concise.
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 only two optional parameters, no output schema, and rich annotations, the description covers purpose, usage, behavioral traits, and parameter details. It mentions the return format (formatted table with fields). Minor gap: no mention of response structure or error handling, but acceptable.
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% with descriptions for both parameters. The description restates that eventType is optional and explains event types (WITNESS, BULK_WITNESS) which are already in schema. No additional semantics added beyond 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 clearly states it queries the SSWP audit ledger, specifying verb 'Query' and resource 'tamper-proof SSWP audit ledger'. It distinguishes from sibling tool sswp_registry_health by noting an alternative use case for fleet overview.
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 explicit use cases: 'audit trail review, compliance reporting, or incident investigation'. It also suggests an alternative tool for a different purpose (fleet overview). While it does not explicitly state when not to use, the guidance is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the SSWP fleet registry using full-text search (FTS5) across node names, tags, and descriptions. Matches partial keywords and ranks results by relevance. Returns a formatted table showing matching nodes with their name, node type, status, and repository path. Use this to find specific projects in the ecosystem registry by name fragment, technology tag, or description keyword. For a full sorted health board of all nodes, use sswp_registry_health instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string. Supports partial keyword matching across node names, tags, and descriptions. Example: 'anyio' or 'omega' or 'witness'. | |
| limit | No | Maximum number of matching results to return, ordered by FTS5 relevance rank. Defaults to 10 if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about full-text search behavior (partial keyword matching, FTS5 relevance ranking) and output format, which exceeds annotation coverage 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 two sentences long, front-loaded with the core purpose, and every sentence adds necessary information without redundancy.
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 annotations and schema, the description covers search behavior, output format, usage context, and alternative tool. No output schema exists, but the description adequately describes what is returned (formatted table with name, node type, status, repo path).
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%, but the description adds value by explaining the query parameter supports partial keyword matching across multiple fields and provides examples. It also clarifies that limit defaults to 10, which is already in schema but reinforced.
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 searches the SSWP fleet registry using FTS5 across node names, tags, and descriptions, and distinguishes it from the sibling tool 'sswp_registry_health' by specifying the output as a formatted table of matching nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to find specific projects... by name fragment, technology tag, or description keyword') and when to use an alternative ('for a full sorted health board of all nodes, use sswp_registry_health instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display the full fleet health board from the SSWP SQLite registry. Returns a formatted table showing every witnessed node with its name, status (active/deprecated/archived), last witness run timestamp, overall risk score (as percentage), and adversarial risk score (as percentage). Results are ordered by risk descending (most risky nodes first). Use this for an ecosystem-wide dashboard view of attestation status. For searching specific nodes by name, tag, or description, use sswp_node_search. For querying the audit ledger directly, use sswp_ledger.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of nodes to display in the health board. Defaults to 50 if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns a formatted table ordered by risk descending, which is beyond annotations. No behavioral traits are hidden; it accurately reflects a read-only, idempotent operation.
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?
Description is four sentences, with the main purpose in the first sentence, return format and ordering in the second, and usage guidelines in the final two. No redundant words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, clear annotations), the description is fully complete: it explains what it does, what it returns, ordering, and when to use it versus siblings. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter 'limit' fully with description and default. Description does not add any additional meaning or usage notes about the limit parameter beyond what schema provides, so 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?
Description clearly states it displays the fleet health board with specific fields (name, status, timestamps, risk scores) and ordering. It also names alternative tools for specific searches (node_search) and ledger queries (sswp_ledger), distinguishing itself as the ecosystem-wide dashboard.
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?
Explicit usage guidance: 'Use this for an ecosystem-wide dashboard view of attestation status.' Then explicitly points to sswp_node_search for searching specific nodes and sswp_ledger for ledger queries, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the SHA-256 cryptographic signature of an existing .sswp.json attestation file. Recomputes the hash over the entire attestation payload (sorted keys, excluding the signature field) and compares it against the stored signature. Returns VALID ATTESTATION if the file is intact and unmodified, or SIGNATURE MISMATCH if the file was altered after sealing. Use this to audit an attestation you received from someone else, or to confirm a repo's attestation still matches the file on disk. For generating new attestations, use sswp_witness; for quick repo readiness checks without sealing, use sswp_check_repo.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the .sswp.json attestation file to verify. The file must contain a valid SSWP attestation with a 'signature' field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains that it recomputes hash over sorted keys excluding signature field and compares against stored signature. Annotations already indicate read-only and idempotent; description adds algorithmic detail and return values.
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?
Concise yet comprehensive. Each sentence adds value: purpose, mechanism, outputs, usage guidance, alternatives. Front-loaded with core action.
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?
Covers all needed context: single parameter, return values (two outcomes), algorithm, usage scenarios, differentiation from siblings. No missing information for agent to invoke 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 covers filePath with clear details (absolute path, valid attestation requirement). Tool description reinforces this. Despite 100% schema coverage, description adds minor context about the signature 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?
Clearly states it verifies SHA-256 cryptographic signature of .sswp.json attestation file, specifying verb and resource. Distinguishes from siblings by naming alternatives (sswp_witness for generating, sswp_check_repo for repo checks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'audit an attestation you received' or 'confirm a repo's attestation'. Provides clear alternatives for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Witness a software project with deterministic attestation. Scans the full dependency graph (every node_modules package with resolved path, integrity hash, and risk score), runs a 5-gate pipeline (GIT_INTEGRITY, LOCKFILE, DETERMINISTIC_BUILD, TEST_PASS, LINT), adversarially probes every dependency for typosquatting, version anomalies, and missing integrity hashes, then produces a self-verifying .sswp.json attestation sealed with SHA-256. Auto-saves the attestation to the SQLite fleet registry and appends an entry to the tamper-proof audit ledger. This is the primary attestation tool — use it when you need a full cryptographic witness of a single repo's state. For multiple repos, use sswp_bulk_witness instead.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Absolute path to the project root directory containing package.json and node_modules. The tool resolves WSL/Windows path translations automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the tool's actions: scanning, running a pipeline, adversarial probing, producing an attestation, and auto-saving to a registry and audit ledger. This adds substantial context beyond the annotations (idempotent, not read-only, not destructive) and does not contradict them.
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 three sentences, front-loaded with the main action, and conveys all necessary details without excessive verbosity. It could be slightly more concise by breaking into bullet points, but overall it's efficient.
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 (single parameter, no output schema), the description covers the input, process, and output well. However, it does not specify what the tool returns to the agent (e.g., success message or attestation path), leaving a minor gap for an agent evaluating the output.
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 repoPath parameter well (100% coverage). The description adds context that the tool expects a directory with node_modules, which is useful but not critical. This slightly elevates the score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the primary attestation tool for single repos, specifying that it produces a self-verifying .sswp.json attestation after scanning the full dependency graph and running a 5-gate pipeline. It distinguishes itself from the sibling sswp_bulk_witness by stating the single-repo scope.
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 says 'use it when you need a full cryptographic witness of a single repo's state' and 'For multiple repos, use sswp_bulk_witness instead,' providing clear when-to-use and when-not-to-use guidance with a specific alternative.
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.
v1.0.2sswp_bulk_witnessv1.0.1sswp_analyze_deps4 fields changedInput schema / properties / packages / descriptionAdded value: +"Array of dependency objects to analyze. Each must include the package name and version string."Input schema / properties / packages / items / descriptionAdded value: +"A single dependency entry to analyze."Input schema / properties / packages / items / properties / name / descriptionAdded value: +"The npm package name (e.g., 'better-sqlite3', '@modelcontextprotocol/sdk')."Input schema / properties / packages / items / properties / version / descriptionAdded value: +"The version string as it appears in package-lock.json (e.g., '12.9.0', '^1.0.0')."sswp_bulk_witnesssswp_check_repo1 field changedInput schema / properties / repoPath / descriptionPrevious value: -"Project root path."New value: +"Absolute path to the project root directory to check. Must be a valid filesystem path."sswp_ledger2 fields changedInput schema / properties / eventType / descriptionPrevious value: -"Filter by event type"New value: +"Filter entries by event type. Common values: 'WITNESS' (single repo attestation), 'BULK_WITNESS' (batch run). Omit to return all event types."Input schema / properties / limit / descriptionPrevious value: -"Entries to show"New value: +"Number of ledger entries to return, ordered newest first. Defaults to 20 if not specified."sswp_node_search2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results"New value: +"Maximum number of matching results to return, ordered by FTS5 relevance rank. Defaults to 10 if not specified."Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Search query string. Supports partial keyword matching across node names, tags, and descriptions. Example: 'anyio' or 'omega' or 'witness'."sswp_registry_health1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max rows"New value: +"Maximum number of nodes to display in the health board. Defaults to 50 if not specified."sswp_verify1 field changedInput schema / properties / filePath / descriptionPrevious value: -".sswp.json path."New value: +"Absolute path to the .sswp.json attestation file to verify. The file must contain a valid SSWP attestation with a 'signature' field."sswp_witness1 field changedInput schema / properties / repoPath / descriptionPrevious value: -"Project root path."New value: +"Absolute path to the project root directory containing package.json and node_modules. The tool resolves WSL/Windows path translations automatically."v1.0.0sswp_analyze_depssswp_bulk_witnesssswp_check_reposswp_ledgersswp_node_searchsswp_registry_healthsswp_verifysswp_witnessScored across 8 tools
Each tool has a clearly distinct purpose: single attestation, bulk attestation, verification, dependency analysis, pre-flight checking, registry health, ledger audit, and node search. Even the similar single vs. bulk witness tools are explicitly differentiated by scope.
All tools share the sswp_ prefix and snake_case, but base names mix conventions: verb-only (witness, verify), verb_noun (analyze_deps, check_repo), and noun forms (ledger, registry_health, node_search). The domain prefix keeps it readable, but there's no single verb_noun pattern.
8 tools is well-scoped for a supply-chain attestation workflow: single and bulk witnessing, verification, pre-check, dependency analysis, and three query/audit surfaces. No redundancy or bloat.
The lifecycle is well covered: witness, bulk witness, verify, pre-check, dependency analysis, registry health, ledger audit, and search. Minor gaps exist around registry lifecycle management (e.g., no explicit tool to update node status or remove a node), but core workflows are covered.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
