Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.vouch-protocol/vouch-mcp

PYPI · VOUCH-MCP · SCANNED SEP 21

Sign and verify W3C Verifiable Credentials so AI agents can cryptographically authorize actions.

Available components

0 this week 66 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs setuptools.build_meta at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
  • 1 of 21 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
  • Clear OSI-approved license (Apache-2.0).Pass
  • Actively maintained (last published 13 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability69
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 4824 tokens (~201/item across 24 items; 24 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
  • Stability not yet verified: two runs of the same published version returned different tool surfaces, so we cannot tell a change in the package from a difference in our own sandbox run.Unverified
Tool Coverage71
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 0% of tool parameters carry a description.Fail
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "create_authority_state" implies "publish" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
  • An AI judge read all 24 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass

Unverified: 1 category

A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

Install

How do I install the io.github.vouch-protocol/vouch-mcp server?

io.github.vouch-protocol/vouch-mcp runs locally as a PyPI package, launched with uvx vouch-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · vouch-mcp

# add to Claude Code
claude mcp add vouch-protocol-vouch-mcp -- uvx vouch-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "vouch-protocol-vouch-mcp": {
      "command": "uvx",
      "args": [
        "vouch-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "vouch-protocol-vouch-mcp": {
      "command": "uvx",
      "args": [
        "vouch-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add vouch-protocol-vouch-mcp -- uvx vouch-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "vouch-protocol-vouch-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "vouch-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add vouch-protocol-vouch-mcp --command uvx --arg vouch-mcp
# ~/.hermes/config.yaml
mcp_servers:
  vouch-protocol-vouch-mcp:
    command: "uvx"
    args: ["vouch-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "vouch-protocol-vouch-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "vouch-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add vouch-protocol-vouch-mcp -t stdio -c uvx -a vouch-mcp
// mcp.json
{
  "mcpServers": {
    "vouch-protocol-vouch-mcp": {
      "command": "uvx",
      "args": [
        "vouch-mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 18 Sept 26 +15
    • Malware scan: unverified → pass security
  • 16 Sept 26 −15
    • Malware scan: pass → unverified security
  • 14 Sept 26 +15
    • Malware scan: unverified → pass security
  • 12 Sept 26 −13
    • Stability: 0.90 → unverified security
  • 11 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

  • 9 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

  • 7 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

  • 4 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 21 Sept 2026 · Analysed pypi/vouch-mcp@2.0.1

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted setuptools.build_meta

Background: Why install scripts are a supply-chain risk →

Dependencies 21 packages
Packages resolved 21
Stale 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 24 exposed · ~4,824 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
attribute ~136

Attribute authorship from a signed attribution manifest. Given an attribution manifest (which records, per file, what a human wrote versus what an AI agent generated), summarize the human/AI/pre-existing split across the whole manifest, or -- when ``path`` is given -- report the per-region authorship of that one file. Args: manifest_json: The attribution manifest as a JSON string. path: Optional file path to blame; omit for a whole-manifest summary. Returns: A per-file blame breakdown, or a manifest-wide authorship summary.

NameTypeReqDescription
manifest_jsonstringyes
path
NameTypeReqDescription
resultstringyes

No examples provided.

check_action ~243

Decide whether a DID may take one action on one resource (Shield). A pure authorization check against this server's rules file. It matches on the same three fields a Vouch Credential binds in ``credentialSubject.intent``, so the policy asks exactly the question the evidence answers. Requires VOUCH_RULES to point at a Shield rules file. Without it Shield holds no authority and everything is denied. Args: action: The verb being gated, e.g. 'read_file'. Matched exactly. target: The service or surface, e.g. 'filesystem'. Matched exactly. resource: The specific object, e.g. 'reports/q3.txt'. Glob-matched: '*' is one path segment, '**' is any depth. did: The DID asking to act. Returns: 'ALLOW' or 'DENY' with the reason. Reasons are stable strings: 'no matching rule', 'resource outside scope', 'unknown did', 'invalid resource', 'malformed rules'.

NameTypeReqDescription
actionstringyes
didstringyes
resourcestringyes
targetstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

check_action_aat ~268

Decide whether an AAT delegation chain permits a tool call (Shield). The counterpart to ``check_action`` for deployments that carry authority as an Attenuating Authorization Token chain. Rules come from the verified chain's **leaf** -- the authority after all narrowing -- rather than from a static capability grant. Unlike ``check_action``, this evaluates the call's *arguments* too: an AAT leaf can restrict ``path`` to ``reports/*``, and a call outside that is denied even though the tool itself is permitted. Requires ``VOUCH_AAT_CHAIN`` to point at a chain file. Denies if it is unset or if the chain does not verify -- there is no lax fallback. Precedence: when a static allow-list is also in force, both must allow. An AAT chain narrows what this server will do; it never widens it. Args: tool: The tool name being gated, e.g. 'read_file'. args_json: The call's arguments as a JSON object, e.g. '{"path": "reports/q3.txt"}'. Returns: 'ALLOW' or 'DENY' with the reason.

NameTypeReqDescription
args_jsonstring
toolstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

check_authority_freshness ~420

Decide whether an action passes the Authority Freshness gate. Compares the epoch a session voucher was minted under against the highest epoch this verifier has learned for the authority, and weighs the result against the action's consequence tier: - 'routine': time-decay trust only, so this gate always allows. - 'sensitive': the epoch comparison, applied locally against the epoch the verifier already holds. No network call at action time. - 'critical': the epoch comparison plus a live M-of-N quorum co-sign read at action time. Verify that co-sign separately and pass the outcome in as live_cosign_ok; this tool does not fetch or check one itself. This is the authority-state judgement alone. Fold it in with identity, revocation, and time-decay trust before honoring an action. Args: tier: Consequence tier: 'routine', 'sensitive', or 'critical' (default). An unknown tier is treated as 'critical' (fail-closed). voucher_epoch: The authorityEpoch the caller's session voucher was minted under. Omit if the voucher carries no epoch. last_seen_epoch: The highest epoch this verifier has learned for the authority. Omit if it has never seen one. current_status: The authority's current status if known, from a verified AuthorityState. Any value other than 'active' fails closed on a tier that enforces state freshness. live_cosign_ok: For the 'critical' tier: whether a live quorum co-sign was supplied and verified fresh. False fails closed on that tier. Returns: 'ALLOW' or 'DENY' with the tier and a stable reason code, for example 'authority_epoch_stale:seen=7,voucher=5'.

NameTypeReqDescription
current_status
last_seen_epoch
live_cosign_okboolean
tierstring
voucher_epoch
NameTypeReqDescription
resultstringyes

No examples provided.

check_intent_freshness ~304

Decide if a reasoned action's intent seal is fresh enough for its tier. Event-triggered intent recheck (the secondary seal). A heartbeat proves an agent is still running; it does not prove the agent's intent is current at the moment of a sensitive action. Someone who knows the pulse interval could time a sensitive action to land in the gap between two heartbeats, riding on an intent sealed earlier. For a sensitive tier this gate requires a seal made after the last heartbeat boundary and recently enough, and rejects a stale seal. Args: credential_json: A ReasonedActionCredential as a JSON string. It carries a 'sealedAt' in its justification block (or an escrow receipt whose 'depositedAt' is used as the seal time). last_pulse: The most recent heartbeat boundary as 'YYYY-MM-DDTHH:MM:SSZ'. tier: Consequence tier: 'routine', 'low', 'medium', 'high' (default), or 'critical'. Routine, low, and medium do not require a fresh seal. Returns: 'FRESH' when the seal is current for the tier, or 'STALE' with the stable reason string (for example 'intent_seal_stale:...').

NameTypeReqDescription
credential_jsonstringyes
last_pulsestringyes
tierstring
NameTypeReqDescription
resultstringyes

No examples provided.

check_revocation ~100

Check whether a credential has been revoked via its status list. Reads the credential's BitstringStatusList entry (credentialStatus), fetches the referenced status list, and reports whether the bit is set. Args: credential_json: The credential as a JSON string. Returns: 'ACTIVE', 'REVOKED', or a note that the credential is not individually revocable (no credentialStatus attached).

NameTypeReqDescription
credential_jsonstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

check_trust ~193

Recompute a session voucher's live trust and compare it to a threshold. A session voucher's trust decays over time (Trust Entropy). Before honoring a high-stakes action, recompute the *current* trust and refuse if it has fallen below the threshold you require -- unless the session is refreshed. Pair this with create_session, which issues the voucher. Args: voucher_json: The session voucher (from create_session) as a JSON string. threshold: Minimum trust in [0, 1] the action requires (default 0.5). now_iso: The verifier's clock as 'YYYY-MM-DDTHH:MM:SSZ'. Defaults to now. Returns: 'ALLOW' or 'DENY' with the current trust, threshold, and elapsed age.

NameTypeReqDescription
now_iso
thresholdnumber
voucher_jsonstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

create_authority_state ~275

Publish this authority's current epoch and status as a signed credential. An AuthorityState credential carries a monotonic ``authorityEpoch`` counter and a status. Bump the epoch on every authority-relevant transition (a mandate suspended, an incident opened, a key exposure, a revocation) and publish a fresh state. Verifiers that track the highest epoch they have seen can then refuse a session voucher minted under an older epoch. Args: authority_epoch: The monotonic epoch counter, a non-negative integer. It must strictly increase on every authority-relevant transition. status: One of 'active', 'suspended', 'incident', 'exposure_breached', or 'revoked'. Default 'active', the only status under which a state-freshness action may proceed. valid_seconds: Validity window of the published state in seconds (default 300). subject_did: The DID the state is about. Defaults to this server's DID, an authority publishing its own state. Returns: A compact JSON AuthorityState credential with an eddsa-jcs-2022 proof.

NameTypeReqDescription
authority_epochintegeryes
statusstring
subject_did
valid_secondsinteger
NameTypeReqDescription
resultstringyes

No examples provided.

create_session ~202

Issue a trust-decaying session voucher (Heartbeat Protocol). Unlike a plain long-lived credential, a session voucher carries a trust value that decays over time (Trust Entropy). A verifier recomputes the current trust with compute_trust_at and can refuse a high-stakes action once trust falls below a threshold, unless the session is refreshed. Args: purpose: What the session is for, e.g. 'calendar_access'. valid_seconds: Voucher lifetime in seconds (default 3600). decay_lambda: Trust decay rate per second (default 0.0005). initial_trust: Starting trust in [0, 1] (default 1.0). Returns: A compact JSON session voucher with an eddsa-jcs-2022 proof.

NameTypeReqDescription
decay_lambdanumber
initial_trustnumber
purposestringyes
valid_secondsinteger
NameTypeReqDescription
resultstringyes

No examples provided.

decode_did ~140

Decode a DID key or Multikey and report its algorithm. Accepts a ``did:key:z...`` identifier or a bare ``z...`` Multikey and reports the key algorithm and raw public-key size. Use it to inspect an identifier before trusting it -- for example to confirm a peer's key is an Ed25519 (``ed25519-pub``) key and not an unexpected algorithm. Args: key: A ``did:key:z...`` DID or a bare ``z...`` Multikey string. Returns: The decoded algorithm and public-key length, or a rejection reason.

NameTypeReqDescription
keystringyes
NameTypeReqDescription
resultstringyes

No examples provided.

delegate ~239

Issue a narrowed delegation grant to another agent. The principal (this server's identity) authorizes ``action`` on ``target``/``resource`` and hands the grant to a sub-agent. Every action the sub-agent signs is chained under this grant and can only *narrow* the authority, never widen it (Specification 9.3). Use this to give a worker agent exactly one scoped capability with an optional expiry. Args: action: The verb being delegated, e.g. 'charge', 'read', 'send'. target: The service or URL the grant applies to. resource: The specific object the grant is scoped to. to: Optional DID of the intended sub-agent (audience binding). valid_seconds: Optional lifetime of the grant in seconds. reputation_score: Optional minimum reputation the sub-agent must carry. Returns: A compact JSON delegation grant to pass to the sub-agent as its parent.

NameTypeReqDescription
actionstringyes
reputation_score
resourcestringyes
targetstringyes
to
valid_seconds
NameTypeReqDescription
resultstringyes

No examples provided.

disclose_ai_origin ~147

Sign a disclosure that a piece of content is AI-generated. Issues a Vouch Credential attesting that this agent produced the content identified by ``content_hash``. Attach it alongside generated text, images, or code so any downstream party can verify the AI-origin claim cryptographically rather than trusting an unsigned label. Args: content_hash: A content digest, e.g. 'sha256:ab12...'. content_ref: Optional locator for the content (URL or path). Defaults to the generic label 'ai-generated-content'. Returns: A compact JSON Vouch Credential disclosing AI origin.

NameTypeReqDescription
content_hashstringyes
content_ref
NameTypeReqDescription
resultstringyes

No examples provided.

evaluate_freshness ~246

Decide if a revocation snapshot is fresh enough for a disconnected action. Bounded-staleness revocation gate (PAD-106) for delay-tolerant / offline use: a verifier that cannot fetch a live status list weighs the age of the snapshot it holds against the consequence of the action, and fails closed when the view is too old. A routine beacon tolerates a 30-day-old snapshot; a critical maneuver does not (1-hour default budget). Args: tier: Consequence tier: 'routine', 'sensitive', or 'critical' (default). An unknown tier is treated as 'critical' (fail-closed). snapshot_json: The last-synced BitstringStatusListCredential as a JSON string, or omitted if no snapshot is held (allows only 'routine'). now_iso: The verifier's clock as 'YYYY-MM-DDTHH:MM:SSZ'. Defaults to now. Returns: 'ALLOW' or 'DENY' with the reason (snapshot age vs. the tier budget).

NameTypeReqDescription
now_iso
snapshot_json
tierstring
NameTypeReqDescription
resultstringyes

No examples provided.

get_identity ~19

Return this agent's DID (Decentralized Identifier).

Input schema present but exposes no named parameters.

NameTypeReqDescription
resultstringyes

No examples provided.

reputation ~161

Compute an agent's reputation score from a history of outcomes. Replays a sequence of recorded outcomes for ``did`` and returns the current reputation score and success rate. Use it to weigh how much to trust a peer agent that has a track record, or to gate a sensitive action on a minimum standing. Args: did: The DID whose reputation to compute. events_json: A JSON array of events, each '{"outcome":"success"|"failure","reason":"..."}', or a '{"boost"|"slash": <amount>, "reason":"..."}' adjustment. Returns: The computed score, total actions, and success rate.

NameTypeReqDescription
didstringyes
events_jsonstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

robot_check_action ~250

Check a robot's proposed physical action against its capability scope. The pre-actuation gate of the VLA accountability loop: given the physicalScope from a signed PhysicalCapabilityScope credential and a proposed action, decide deterministically whether the action stays inside the envelope. An over-speed motion near a human or a move outside an allowed zone is denied with the exact reason. Args: scope_json: The physicalScope object as JSON (or a whole PhysicalCapabilityScope credential; its credentialSubject .physicalScope is used), e.g. '{"maxForceN":80,"maxSpeedMps":1.5, "maxSpeedNearHumansMps":0.5,"allowedZones":["cell-3"]}'. action_json: The proposed action as JSON, e.g. '{"forceN":20, "speedMps":0.3,"nearHumans":true,"zone":"cell-3"}'. Returns: 'ALLOW' when the action is inside the scope, or 'DENY' with the reasons (which limits were exceeded).

NameTypeReqDescription
action_jsonstringyes
scope_jsonstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

robot_check_conformance ~200

Check a robot's credentials against a regulatory conformance profile. The evidence-pack check: given the credentials a robot presents (a JSON array) and a built-in profile id (eu-ai-act-high-risk, iso-10218, iso-ts-15066, eu-machinery-2023-1230, or ul-3300), report per clause whether the set satisfies the regulation, CONFORMS or the exact gaps. The caller is expected to have verified the credentials' signatures; this checks structure and coverage. Args: credentials_json: A JSON array of the robot's credentials. profile_id: One of the built-in profile ids listed above. Returns: 'CONFORMS' or 'GAPS' with the satisfied count, how well-sourced the profile's clause references are, and one line per requirement clause.

NameTypeReqDescription
credentials_jsonstringyes
profile_idstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

robot_verify_conformance_attestation ~140

Verify a signed robot conformance attestation offline. Checks the assessor's proof over a RobotConformanceAttestation and that the embedded report matches its bound digest, so a tampered report (for example a flipped 'conforms') is rejected. Args: attestation_json: The RobotConformanceAttestation credential as JSON. issuer_public_key_jwk: The assessor's Ed25519 public key as a JWK JSON string. Returns: 'VALID' with the profile and verdict, or 'INVALID'.

NameTypeReqDescription
attestation_jsonstringyes
issuer_public_key_jwkstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

robot_verify_credential ~214

Verify a robot credential, classical or post-quantum, auto-detected. The provenance-on-load check of the VLA accountability loop, and the general verify for any vouch.robotics credential: verifies the proof (or post-quantum proof set) a robot credential carries under the robot's key. A post-quantum credential requires the ML-DSA-44 public key; a classical credential ignores it. Args: credential_json: The robot credential as JSON. ed25519_public_key_jwk: The robot's Ed25519 public key as a JWK JSON string. mldsa44_public_key: Optional ML-DSA-44 public key (multikey string) for a post-quantum proof set. Returns: 'VALID' with the credential type, or 'INVALID'.

NameTypeReqDescription
credential_jsonstringyes
ed25519_public_key_jwkstringyes
mldsa44_public_key
NameTypeReqDescription
resultstringyes

No examples provided.

scan ~159

Scan text for leaked Vouch private keys and other key material. Run this over anything about to leave a trust boundary -- a diff, a log line, a chat message, a file the agent is about to paste or commit -- to catch an Ed25519 private JWK, a private multibase key, a hybrid post-quantum secret, a seed env var, or a DID document that embeds a private key, before it is exposed. Args: text: The text to scan (source, config, log output, message body). Returns: 'CLEAN' when nothing sensitive is found, or a list of findings with their kind, severity, line, and remediation.

NameTypeReqDescription
textstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

sign ~215

Issue a Vouch Credential authorizing a single sensitive action. Call this before any authenticated request to an external service. The returned credential binds this agent's identity to this exact action and resource, so a downstream service can confirm the call was authorized. Args: action: The verb, e.g. 'read', 'write', 'execute', 'send'. target: The service or URL being called. resource: The specific object, e.g. 'customer:123'. Defaults to target. post_quantum: If true, sign under the hybrid post-quantum profile (hybrid-eddsa-mldsa44-jcs-2026) for regulated deployments. Requires the server to have 'vouch-protocol[pq]' installed. Returns: A compact JSON Vouch Credential to attach as a 'Vouch-Credential' header.

NameTypeReqDescription
actionstringyes
post_quantumboolean
resource
targetstringyes
NameTypeReqDescription
resultstringyes

No examples provided.

verify ~168

Verify a Vouch Credential that another agent or service presented. This is the receiving side: given a credential (the JSON another party's sign produced), confirm the signature, validity window, and intent binding. Any MCP client can call this without installing an SDK. Args: credential_json: The credential as a JSON string. public_key: Optional Multikey public key of the issuer. If omitted, the issuer's DID is resolved to fetch its key (did:key offline, did:web over the network). If the key cannot be obtained, the credential is rejected rather than accepted. Returns: A human-readable verdict: the issuer DID and authorized intent when valid, or a rejection reason.

NameTypeReqDescription
credential_jsonstringyes
public_key
NameTypeReqDescription
resultstringyes

No examples provided.

verify_authority_state ~163

Verify an AuthorityState credential an authority published. Confirms the eddsa-jcs-2022 proof, that the signing key belongs to the issuer, that the validity window covers now, and that the epoch and status are well formed. On success it reports the epoch and status, which is what a verifier records as the highest epoch it has seen for that authority. Args: credential_json: The AuthorityState credential as a JSON string. public_key: The issuing authority's Ed25519 public key (Multikey or JWK). Returns: 'VERIFIED' with the issuer, subject, epoch, and status, or a rejection reason.

NameTypeReqDescription
credential_jsonstringyes
public_keystringyes
NameTypeReqDescription
resultstringyes

No examples provided.

verify_disconnected_edge ~222

Authenticate a disconnected-edge (DTN) credential's signature. Verifies the eddsa-jcs-2022 proof of any disconnected-edge credential type (PAD-106 to PAD-124): freshness tokens, channel-geometry presence, ephemeris-scoped grants, dead-man and accumulator revocation, distress and trust-state updates, time-quality, autonomy schedules, integrity risk, perception claims, DTN bundle custody, and more. This confirms authenticity and returns the credential's type and subject; the geometry, epoch-gap, region, and staleness *predicates* are applied by the holder with its own local state (position, epoch, clock), so they are not evaluated here. Args: credential_json: The disconnected-edge credential as a JSON string. public_key: The issuer's Ed25519 public key (Multikey or JWK). Returns: 'VERIFIED' with the credential type and subject, or a rejection reason.

NameTypeReqDescription
credential_jsonstringyes
public_keystringyes
NameTypeReqDescription
resultstringyes

No examples provided.

Common questions

What is the io.github.vouch-protocol/vouch-mcp server?

io.github.vouch-protocol/vouch-mcp is listed in the public MCP registry as io.github.vouch-protocol/vouch-mcp. Sign and verify W3C Verifiable Credentials so AI agents can cryptographically authorize actions. This page covers its PyPI package (vouch-mcp).

Is the io.github.vouch-protocol/vouch-mcp server safe to use?

io.github.vouch-protocol/vouch-mcp scores 66 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.vouch-protocol/vouch-mcp server expose?

io.github.vouch-protocol/vouch-mcp exposes 24 tools: sign, verify, create_session, check_revocation, get_identity, and 19 more. Their descriptions and schemas cost roughly 4,824 tokens of context every time the server is loaded.

Is the io.github.vouch-protocol/vouch-mcp server still maintained?

io.github.vouch-protocol/vouch-mcp is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the io.github.vouch-protocol/vouch-mcp server under?

io.github.vouch-protocol/vouch-mcp declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.