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 MCP is the attestation and witness layer of the VERITAS & Sovereign Ecosystem (Omega Universe). Where Omega Brain governs execution paths through policy gates, SSWP governs the artifact itself — capturing what code was, what was done to it, and whether it survived disciplined attempts to break it, all sealed against revision. It exposes an MCP server that Hermes, Claude, Cline, or any compatible agent can call natively to witness any software project with deterministic attestation, probe dependencies for supply-chain risk, and audit the fleet registry across every node in the ecosystem. Every sswp_witness call produces a self-verifying .sswp.json attestation file. Every sswp_bulk_witness run is logged to the tamper-proof audit ledger. The fleet registry — currently 131 nodes — makes the entire ecosystem auditable in one command.
SYSTEM INVARIANT: SSWP does not certify that code is correct. SSWP certifies what code was, what was done to it, and by whom — sealed against revision.
Related MCP server: Agent Receipts
SSWP MCP is a self-contained Model Context Protocol (MCP) server that runs as a local process alongside any MCP-compatible AI client. It exposes 8 tools covering four witness domains:
Deterministic attestation — scan, gate-test, adversarially probe, and seal any software repo to a self-verifying .sswp.json file
Supply-chain probing — typosquatting detection, version anomaly scanning, metadata integrity checks, and optional Kimi K2-powered reasoning
Fleet registry — SQLite database with FTS5 search, health board, risk leaderboard, and gate trends across all witnessed repos
Tamper-proof audit ledger — append-only SHA-256 hash chain; every witness run, every gate vote, every probe result is sealed
One repository. Node.js v18+. Zero cloud dependencies.
Compatible clients: Hermes, Claude Desktop, VS Code Copilot, Cursor, Cline, Windsurf, and any MCP-compliant host.
Not a build system. SSWP witnesses — it does not orchestrate builds, deployments, or CI pipelines.
Not a CVE database. The adversarial probes are heuristic (typosquatting patterns, version pinning, metadata integrity). They complement, not replace, dedicated vulnerability scanners.
Not a security audit. SSWP produces evidence. Whether that evidence satisfies a reviewer's threshold is the reviewer's decision.
Not a cloud service. All data remains on the operator's machine in ~/.sswp_registry.sqlite and the .sswp.json files in each repo.
When an AI agent operates on a codebase, four questions haunt every serious reviewer:
What state was the code in when the agent saw it?
What did the agent change, exactly?
Did the changes survive disciplined attempts to break them?
Can any of this be verified later, by someone who wasn't there?
Existing supply-chain tools answer subsets of this. Sigstore signs releases. SLSA attests build provenance. in-toto attests pipelines. None of them are agent-native, and none of them probe the artifact adversarially before sealing.
SSWP fills that gap.
Every sswp_witness call performs four phases atomically against a target repo:
Scan — capture the full dependency graph (every node_modules package with resolved path, integrity hash, and risk score), the build environment (Node version, OS, arch, CI status), and repo metadata (name, commit hash, branch).
Gate-test — run a 5-gate deterministic pipeline against the codebase:
Gate | What it checks | Verdict |
|
| PASS if no modified files |
|
| INCONCLUSIVE if no |
| Detected build command exits 0 | INCONCLUSIVE if no build command detected |
|
| PASS / FAIL |
| eslint → biome → tsc, first to pass wins | INCONCLUSIVE if no linter configured |
Adversarially probe — three per-package probes run on every dependency:
Probe | What it detects | Signal |
| Name matches known suspicious pattern list | WARN if matched |
| Unpinned version ranges ( | WARN on range |
| Integrity hash present on dep entry | CRITICAL if missing |
Optional Kimi K2 reasoning (KIMI_REASONING probe) deepens the analysis when OLLAMA_CLOUD_API_KEY is set. Aggregate overallRisk = (CRITICAL_count × 0.4 + WARN_count × 0.15) / dep_count, clamped to [0, 1].
Seal — produces a .sswp.json attestation: SHA-256 over the scan, gates, adversarial report, and metadata (sorted keys, signature field excluded from hash). Written to disk and appended to the tamper-proof audit ledger in the SQLite registry.
Verification later is one call: sswp_verify recomputes the SHA against the file. If anything was edited after the seal, the hash diverges.
{
"version": "1.0.0",
"timestamp": "2026-04-27T11:27:47.606Z",
"target": {
"name": "veritas-topography-map",
"repo": "/mnt/c/Veritas_Lab/veritas-topography-map",
"commitHash": "85887560bc0feedec78c4cb2524112200ffcd6ca",
"branch": "master"
},
"environment": {
"nodeVersion": "v22.14.0",
"os": "linux",
"arch": "x64",
"ci": false
},
"dependencies": [
{ "name": "@modelcontextprotocol/sdk", "version": "1.29.0",
"integrity": "7ab20eba8fee70f3", "suspicious": false, "riskScore": 0.1 },
{ "name": "better-sqlite3", "version": "12.9.0",
"integrity": "9d2524247288858c", "suspicious": false, "riskScore": 0.1 },
{ "name": "esbuild", "version": "0.25.12",
"integrity": "cb7d5b1fe478f8cb", "suspicious": false, "riskScore": 0.5 }
// ... 14 more dependencies (17 total)
],
"gates": [
{ "gate": "GIT_INTEGRITY", "status": "FAIL", "evidence": "Modified files: 468", "durationMs": 1531 },
{ "gate": "LOCKFILE", "status": "PASS", "evidence": "package-lock.json present", "durationMs": 1 },
{ "gate": "DETERMINISTIC_BUILD", "status": "PASS", "evidence": "Build succeeded: npm run build", "durationMs": 917 },
{ "gate": "TEST_PASS", "status": "FAIL", "evidence": "Tests failed: Missing script: \"test\"", "durationMs": 149 },
{ "gate": "LINT", "status": "PASS", "evidence": "npx tsc --noEmit passed", "durationMs": 4129 }
],
"adversarial": {
"totalPackages": 17,
"suspiciousPackages": 1,
"probes": [
{ "package": "@modelcontextprotocol/sdk", "probe": "TYPO_SQUATTING", "result": "PASS", "detail": "Name heuristic clean" },
{ "package": "esbuild", "probe": "TYPO_SQUATTING", "result": "WARN", "detail": "Name matches known suspicious patterns" },
{ "package": "@modelcontextprotocol/sdk", "probe": "VERSION_ANOMALY", "result": "PASS", "detail": "Pinned: 1.29.0" }
// ... 48 more probes (51 total)
],
"overallRisk": 0.0235
},
"seal": {
"chainHash": "e8f4a...",
"sequence": 4
},
"signature": "a7b3c91d2f84e6a09c..."
}Full repo witness — scans every dependency in node_modules, captures build environment, runs the 5-gate pipeline, performs adversarial probing, and seals the result as a single .sswp.json file
Self-verifying — the signature field is SHA-256 over the entire sorted payload (excluding signature itself); any edit to the file is detectable with one call to sswp_verify
Bulk mode — sswp_bulk_witness runs sequentially across multiple repos, auto-saving each to the registry and logging to the ledger
Typosquatting detection — matches package names against a known suspicious pattern list (e.g., left-pad, event-stream, colors, faker)
Version anomaly scanning — flags unpinned version ranges (*, >=, ^0, ~0, latest) that allow uncontrolled dependency drift
Metadata integrity — CRITICAL on any dependency missing an integrity hash
Kimi K2 reasoning — optional deep analysis when OLLAMA_CLOUD_API_KEY is set; returns INCONCLUSIVE without it (not a failure)
131 nodes tracked — every repo witnessed gets a node record in the SQLite registry with type, status, tags, and metadata
FTS5 full-text search — sswp_node_search "anyio" returns instant results across all witnessed repos
Health dashboard — sswp_registry_health shows every node, last run time, risk score, and adversarial risk in a single view
Risk leaderboard — sortable by VERITAS score; filter by threshold (e.g., "show me every repo below 0.3")
Gate trends — per-node, per-gate history over configurable time windows
Append-only SHA-256 hash chain — every witness run generates internal entries (SCAN → GATES → ADVERSARIAL → ATTEST), each linked to its predecessor via prev_hash
Persistent — full attestation JSON saved to the SQLite registry; ledger entries queryable via sswp_ledger
Verifiable — the registry ledger can be validated end-to-end to confirm no entry has been altered or removed
┌───────────────────────────────────────────────────────┐
│ MCP CLIENT │
│ (Hermes / Claude Desktop / Cline / Copilot) │
└───────────────────────┬───────────────────────────────┘
│ MCP stdio (JSON-RPC 2.0)
▼
┌───────────────────────────────────────────────────────┐
│ SSWP MCP SERVER │
│ src/sswp/mcp/server.ts │
│ │
│ ┌──────────────────────────┐ ┌────────────────────┐ │
│ │ WITNESS ENGINE │ │ FLEET REGISTRY │ │
│ │ │ │ │ │
│ │ 1. Scan (dep graph) │ │ nodes │ │
│ │ 2. Gates (5-gate run) │ │ attestations │ │
│ │ 3. Probe (3 heuristic │ │ gates_history │ │
│ │ + Kimi reasoning) │ │ ledger (SHA-256) │ │
│ │ 4. Seal → .sswp.json │ │ dep_snapshots │ │
│ │ │ │ FTS5 search │ │
│ └──────────┬───────────────┘ └─────────┬──────────┘ │
└─────────────│───────────────────────────│─────────────┘
│ │
▼ .sswp.json file ▼ SQLite
┌──────────────────────┐ ┌──────────────────────┐
│ <repo>/.sswp.json │ │ ~/.sswp_registry │
│ (self-verifying) │ │ .sqlite │
└──────────────────────┘ └──────────────────────┘Node.js v18 or later
npm (installed with Node.js)
A project with a package.json and node_modules to witness
git available in PATH (for the GIT_INTEGRITY gate and commit hash capture)
Ensure Node.js v18+ and npm are installed:
node --version # v18.0.0 or higher
npm --version # bundled with Node.jsgit clone https://github.com/VrtxOmega/sswp-mcp.git
cd sswp-mcp
npm installThe bundled CJS is pre-built in dist/ — no TypeScript compilation required.
node dist/sswp-cli.cjs witness --help
# SSWP CLI v2.0.0 — ready# Clone the repo
git clone https://github.com/VrtxOmega/sswp-mcp.git
cd sswp-mcp
# Install dependencies
npm install
# Witness a repo
npx tsx src/sswp/mcp/server.ts
# (MCP server starts on stdio — ready for client connection)
# Or use the bundled CJS (no TypeScript compilation needed)
node dist/sswp.cjs
# CLI (no MCP required)
node dist/sswp-cli.cjs witness /path/to/your/repo
node dist/sswp-cli.cjs verify /path/to/your/repo/.sswp.json~/.hermes/config.yaml)mcp:
servers:
sswp:
command: bash
args:
- /mnt/c/Veritas_Lab/sswp-mcp/run_mcp.sh
env:
OLLAMA_CLOUD_API_KEY: ${OLLAMA_CLOUD_API_KEY}On Windows via WSL, the Hermes gateway spawns MCP servers from the Linux environment. The run_mcp.sh wrapper handles directory resolution automatically.
cline_mcp_settings.json){
"mcpServers": {
"sswp": {
"command": "node",
"args": ["C:\\Veritas_Lab\\sswp-mcp\\dist\\sswp-mcp.cjs"],
"env": {
"OLLAMA_CLOUD_API_KEY": "your-key-here"
}
}
}
}Note: The
OLLAMA_CLOUD_API_KEYenvironment variable is optional. Without it, adversarial probing still runs the three heuristic probes; only the Kimi K2 reasoning probe returns INCONCLUSIVE.
Tool | Description | When to use |
| Full scan, gates, probe, seal → | Sealing a single repo before or after agent work |
| SHA-256 signature validation on | Confirming an attestation matches current repo state |
| Sequential witness on multiple repos, auto-save to registry | Nightly fleet audit or pre-release sweep |
| Lightweight health check (exists, git, lockfile) | Quick CI gate without full witness overhead |
| Kimi K2 reasoning on a dependency list | Deep supply-chain analysis on critical dependency trees |
| Full fleet health board (all nodes, risk scores) | Dashboard view of ecosystem state |
| Query the tamper-proof audit ledger | Audit trail review, chain integrity verification |
| FTS5 search across registry nodes | Finding repos by name, tag, description, or dep name |
SSWP ships with a standalone CLI that does not require an MCP client:
# Witness a single repo
node dist/sswp-cli.cjs witness /mnt/c/Veritas_Lab/veritas-topography-map
# Verify an attestation
node dist/sswp-cli.cjs verify /mnt/c/Veritas_Lab/veritas-topography-map/.sswp.json
# Registry operations
node dist/sswp-cli.cjs registry list # all nodes
node dist/sswp-cli.cjs registry health # health board
node dist/sswp-cli.cjs registry risky 0.3 # nodes below 0.3 score
# Ledger
node dist/sswp-cli.cjs registry ledger 20 # last 20 entries
node dist/sswp-cli.cjs registry verify-ledger # chain integrity checkAgent-native. SSWP is an MCP server first. Hermes, Claude, Cline, or any MCP client can witness a repo without leaving the conversation. Sigstore, SLSA, and in-toto require CI pipeline integration — they don't speak the protocol your agent already uses.
Adversarial probing built in. Every seal includes the result of heuristic probes (typosquatting, version anomaly, metadata integrity) and optional AI-powered reasoning over the dependency tree. Other protocols attest that something was built — SSWP attests what the dependency tree looked like and whether anything in it triggered known risk patterns.
Fleet-aware. The registry is part of the protocol, not an afterthought. Querying "show me every repo in my ecosystem with a suspicious dependency" is one tool call, not a custom pipeline across disparate tools.
Self-verifying artifact. The .sswp.json file carries its own SHA-256 signature. Verification is stateless — give the file to someone who wasn't there, and they can confirm the attestation with one command.
Python/Maven/Cargo project support (currently JavaScript/TypeScript)
CVE feed integration for typosquatting probe (replace hardcoded heuristic list)
Deterministic build hash comparison across two builds
Multi-user registry federation
GitHub Action for CI-integrated witnessing
SSWP MCP is one component of the VERITAS Omega Universe — a sovereign AI infrastructure stack built on deterministic attestation, cryptographic audit, and operator-declared policy.
Repo | Role |
Governance core — 10-gate VERITAS pipeline, Cortex approval gate, S.E.A.L. audit ledger | |
Desktop operator terminal — Electron + Python agent loop | |
Ollama → MCP inference bridge (6 tools) | |
Deterministic verification spec + dashboard | |
AI knowledge retention engine | |
sswp-mcp | Attestation and witness layer (this repo) |
This project is part of the VERITAS Omega Universe — a sovereign AI infrastructure stack.
VERITAS-Omega-CODE — Deterministic verification spec (10-gate pipeline)
omega-brain-mcp — Governance MCP server (Triple-A rated on Glama)
Gravity-Omega — Desktop AI operator platform
Ollama-Omega — Ollama MCP bridge for any IDE
OmegaWallet — Desktop Ethereum wallet (renderer-cannot-sign)
veritas-vault — Local-first AI knowledge engine
sovereign-arcade — 8-game arcade with VERITAS design system
SSWP — Deterministic build attestation protocol
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. Dates show when Glama detected each change.
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_witnessEach tool targets a distinct operation: dependency analysis, batch witnessing, repo readiness check, ledger queries, fleet search, health dashboard, attestation verification, and full single-repo witnessing. No two tools have overlapping purposes.
All tools share the 'sswp_' prefix. Most follow a verb_noun pattern (e.g., sswp_analyze_deps, sswp_bulk_witness, sswp_check_repo). Minor exceptions: sswp_ledger (noun-only) and sswp_verify (verb-only) break the pattern slightly, but the overall naming is predictable and clear.
With 8 tools covering pre-checks, dependency analysis, single/batch witnessing, verification, registry queries, and audit trail, the count is well-scoped for a supply-chain security server. Each tool earns its place without redundancy.
The tool set covers the full attestation lifecycle: pre-check (sswp_check_repo), analysis (sswp_analyze_deps), single and batch witnessing (sswp_witness, sswp_bulk_witness), verification (sswp_verify), and registry/ledger queries (sswp_node_search, sswp_registry_health, sswp_ledger). No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VrtxOmega/sswp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
