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
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.
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
claude mcp add vouch-protocol-vouch-mcp -- uvx vouch-mcp
{
"mcpServers": {
"vouch-protocol-vouch-mcp": {
"command": "uvx",
"args": [
"vouch-mcp"
]
}
}
} {
"servers": {
"vouch-protocol-vouch-mcp": {
"command": "uvx",
"args": [
"vouch-mcp"
]
}
}
} codex mcp add vouch-protocol-vouch-mcp -- uvx vouch-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"vouch-protocol-vouch-mcp": {
"type": "local",
"command": [
"uvx",
"vouch-mcp"
],
"enabled": true
}
}
} openclaw mcp add vouch-protocol-vouch-mcp --command uvx --arg vouch-mcp
mcp_servers:
vouch-protocol-vouch-mcp:
command: "uvx"
args: ["vouch-mcp"] {
"McpServers": {
"vouch-protocol-vouch-mcp": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"vouch-mcp"
]
}
}
} assistant mcp add vouch-protocol-vouch-mcp -t stdio -c uvx -a vouch-mcp
{
"mcpServers": {
"vouch-protocol-vouch-mcp": {
"command": "uvx",
"args": [
"vouch-mcp"
]
}
}
} 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.
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 →
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 →
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.
| Name | Type | Req | Description |
|---|---|---|---|
| manifest_json | string | yes | – |
| path | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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'.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | – |
| did | string | yes | – |
| resource | string | yes | – |
| target | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| args_json | string | – | – |
| tool | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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'.
| Name | Type | Req | Description |
|---|---|---|---|
| current_status | – | – | – |
| last_seen_epoch | – | – | – |
| live_cosign_ok | boolean | – | – |
| tier | string | – | – |
| voucher_epoch | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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:...').
| Name | Type | Req | Description |
|---|---|---|---|
| credential_json | string | yes | – |
| last_pulse | string | yes | – |
| tier | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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).
| Name | Type | Req | Description |
|---|---|---|---|
| credential_json | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| now_iso | – | – | – |
| threshold | number | – | – |
| voucher_json | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| authority_epoch | integer | yes | – |
| status | string | – | – |
| subject_did | – | – | – |
| valid_seconds | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| decay_lambda | number | – | – |
| initial_trust | number | – | – |
| purpose | string | yes | – |
| valid_seconds | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| key | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | – |
| reputation_score | – | – | – |
| resource | string | yes | – |
| target | string | yes | – |
| to | – | – | – |
| valid_seconds | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| content_hash | string | yes | – |
| content_ref | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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).
| Name | Type | Req | Description |
|---|---|---|---|
| now_iso | – | – | – |
| snapshot_json | – | – | – |
| tier | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
get_identity ~19
Return this agent's DID (Decentralized Identifier).
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| did | string | yes | – |
| events_json | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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).
| Name | Type | Req | Description |
|---|---|---|---|
| action_json | string | yes | – |
| scope_json | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| credentials_json | string | yes | – |
| profile_id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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'.
| Name | Type | Req | Description |
|---|---|---|---|
| attestation_json | string | yes | – |
| issuer_public_key_jwk | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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'.
| Name | Type | Req | Description |
|---|---|---|---|
| credential_json | string | yes | – |
| ed25519_public_key_jwk | string | yes | – |
| mldsa44_public_key | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | – |
| post_quantum | boolean | – | – |
| resource | – | – | – |
| target | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| credential_json | string | yes | – |
| public_key | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| credential_json | string | yes | – |
| public_key | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| credential_json | string | yes | – |
| public_key | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
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.