# tech.vauban/pay-mcp (npm · @vauban-pay/mcp) x402 tools for MCP clients: pay exact/Starknet or STARK-receipt 402s, verify, JCS-hash. No account. - Trust score: 68/100 (medium) - Change this week: +3 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-09-21 ## Components - npm · `@vauban-pay/mcp`: 68/100 (this document), [markdown](https://verifymcp.io/servers/tech-vauban-pay-mcp/vauban-pay-mcp.md), [page](https://verifymcp.io/servers/tech-vauban-pay-mcp/vauban-pay-mcp) ## Channel facts - Registry: `npm` - Package: `@vauban-pay/mcp` - Version: `0.7.1` - Transport: `stdio` ## Trust breakdown 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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-09-21. - **Supply Chain Security**: 98/100 - No malware found by supply-chain analysis. - Known CVEs were checked across the 135 of 136 dependencies we could resolve, so this covers what we could see, not the whole tree. - No install/post-install scripts declared. - Dependency health was assessed across the 135 of 136 dependencies we could resolve, so this covers what we could see, not the whole tree. - **Provenance & Transparency**: 19/100 - Repository check failed: no source repository is declared. - Provenance check failed: no build-provenance attestation is published. - Clear OSI-approved license (Apache-2.0). - Actively maintained (last published 11 days ago). - Security-disclosure policy not yet verified: we couldn't inspect the source repository. - **Schema Quality & AI Usability**: 65/100 - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 1688 tokens (~281/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 47/100 - Stability observed for 14 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - **Tool Safety**: 75/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "pay_for_resource" implies "pay" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. - An AI judge read all 6 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the tech.vauban/pay-mcp server? tech.vauban/pay-mcp runs locally as an npm package, launched with npx -y @vauban-pay/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add tech-vauban-pay-mcp -- npx -y @vauban-pay/mcp ``` ### Cursor ```json { "mcpServers": { "tech-vauban-pay-mcp": { "command": "npx", "args": [ "-y", "@vauban-pay/mcp" ] } } } ``` ### VS Code ```json { "servers": { "tech-vauban-pay-mcp": { "command": "npx", "args": [ "-y", "@vauban-pay/mcp" ] } } } ``` ### Codex ```bash codex mcp add tech-vauban-pay-mcp -- npx -y @vauban-pay/mcp ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "tech-vauban-pay-mcp": { "type": "local", "command": [ "npx", "-y", "@vauban-pay/mcp" ], "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add tech-vauban-pay-mcp --command npx --arg -y --arg @vauban-pay/mcp ``` ### Hermes ```yaml mcp_servers: tech-vauban-pay-mcp: command: "npx" args: ["-y", "@vauban-pay/mcp"] ``` ### Netclaw ```json { "McpServers": { "tech-vauban-pay-mcp": { "Transport": "stdio", "Command": "npx", "Arguments": [ "-y", "@vauban-pay/mcp" ] } } } ``` ### Vellum ```bash assistant mcp add tech-vauban-pay-mcp -t stdio -c npx -a -y @vauban-pay/mcp ``` ### Other ```json { "mcpServers": { "tech-vauban-pay-mcp": { "command": "npx", "args": [ "-y", "@vauban-pay/mcp" ] } } } ``` ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-09-21 (score 68, +1) No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-18 (score 67, +1) No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-16 (score 66, +1) No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-14 (score 65, +1) No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-12 (score 64, +1) No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-10 (score 63, +1) No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-09-09 (score 62, +15) - [security improvement] Malware scan: unverified → pass ### 2026-09-08 (score 47, 0) - [security improvement] Malware scan: unverified → pass - [functional regression] Schema quality: 240 → 281 - [functional improvement] Stability: unverified → 0.03 - [functional] Package version: 0.6.0 → 0.7.1 ## MCP tools (6) ### `jcs_hash` (~58 tokens) JCS (RFC 8785) canonicalize a JSON object then compute its SHA-256 hash. Returns base64-encoded canonical bytes and the hex digest. Input parameters: - `json_object` (object, required): The JSON object to canonicalize and hash. ### `make_payment` (~325 tokens) Make a payment on Starknet Sepolia testnet. Call it with no arguments to get a real, sponsored settlement: we fund the testnet payment, so you need no wallet, no account and no STRK. Returns the transaction hash of YOUR payment plus a Voyager link, and you can read it back from any Sepolia RPC you trust. Pass amount_wei (a decimal string in STRK-wei) to choose the amount, within the published cap. The payee is fixed by the sponsor, so this is a funded demo and not a faucet. If you would rather pay from your own account, set PAY_MCP_SEPOLIA_ACCOUNT_ADDRESS + PAY_MCP_SEPOLIA_PRIVATE_KEY and this tool switches to your signer ; in that mode it emits a receipt hash through the PaymentDemoEmitter contract, which moves NO value and is not proof of a settled payment. Input parameters: - `amount_wei` (string): Amount in STRK-wei, as a decimal STRING. A string because wei amounts exceed Number.MAX_SAFE_INTEGER and a JSON number would silently lose precision. Omit for the sponsored default. - `cap_per_period_wei` (string): Optional per-period cap, STRK-wei as a string. - `cap_per_tx_wei` (string): Optional per-transaction cap, STRK-wei as a string. - `recipient` (string): Informational only in sponsored mode: the payee is fixed by the sponsor so that this is a demo and not a faucet. - `scope` (string): Optional label carried into the authorization object. ### `verify_receipt` (~248 tokens) Verify a SettlementReceipt. Two modes: 1\. Local JCS mode: provide receipt + expected_hash. Computes JCS+SHA-256 and compares. 2\. On-chain mode: provide tx_hash. Reads the transaction from Starknet Sepolia and recognizes TWO distinct, never-conflated outcomes: a sponsored settlement (a real STRK value transfer -- returns execution status, block number, amount_wei, sender, recipient) or a PaymentDemoEmitter receipt-hash emission (moves NO value -- returns the reconstructed receipt and its JCS hash, as before). A reverted transaction, a transaction that does neither, or a tx_hash that does not exist all return verified: false with an explicit reason -- never a guess. Exactly one of (receipt + expected_hash) or (tx_hash) must be provided. Input parameters: - `expected_hash` (string): Expected SHA-256 hex digest, optionally prefixed with 'sha256:' (local JCS mode). - `receipt` (object): The SettlementReceipt object to verify (local JCS mode). - `tx_hash` (string): Starknet tx hash to look up on-chain (on-chain mode). E.g. 0x. ### `request_delegation_grant` (~137 tokens) Create a DelegationGrant authorization object. Builds the grant with canon_version 'x402-jcs-v1.0.0', JCS-hashes it and returns the grant hash. Input parameters: - `cap_per_period` (integer): Optional per-period cap in centimes. - `cap_per_tx` (integer): Optional per-transaction cap in centimes. - `delegatee` (string, required): Delegatee identifier (address or DID). - `delegator` (string, required): Delegator identifier (address or DID). - `expires_at` (string, required): ISO 8601 expiration timestamp. - `scope` (string, required): Delegation scope string. ### `check_merchant` (~278 tokens) Check a merchant's proven service history (an x402 STARK-receipt history document, e.g. https://demo.pay.vauban.tech/x402/v1/history). Fetches history_url, validates the document, and verifies a sample of entries: L1 = structure + per-entry invariants + JCS canonicalization; L2 = each sampled settlement transaction is read from Starknet Sepolia and must be SUCCEEDED (a visible entry must carry a value transfer or a recognized receipt event). Four verdicts, NEVER conflated: \- PROVEN_SAMPLE: document valid, sampled entries verify at the announced level. \- REFUTED: an element contradicts itself or the chain -- the response names it. \- NO_RECORD: no proven history at this URL. Indeterminate, NOT negative -- this is the state of most merchants today. \- UNREACHABLE: transport failure; says nothing about the merchant. An RPC failure during L2 degrades the level to L1 and says so; it never becomes REFUTED. Full STARK re-verification (L3) is not run here; the response carries the public docker command. Input parameters: - `history_url` (string, required): The merchant's history endpoint (http(s) URL). - `sample_size` (integer): Entries to verify, 1..20 (default 5). ### `pay_for_resource` (~642 tokens) Fetch a resource gated behind x402 and complete the payment flow to obtain it -- the x402 CLIENT walk, which none of the other tools here perform. GET url: if it answers 200 directly, the resource was free (outcome no_payment_required -- not a failure, x402 gates specific endpoints, not the whole internet). If it answers 402, parses the PAYMENT-REQUIRED manifest, downloads a STARK proof from proof_url (defaulted to the published demo proof only when url's host is demo.pay.vauban.tech; REQUIRED for any other host -- never guessed), gunzips it in memory, and POSTs it back to url. v0 HONESTY LIMIT: there is no public prover at v0, so the proof submitted is always PRE-GENERATED and published by the merchant, never produced by this agent from its own payment. A 'paid' outcome carries proof.honesty stating exactly what the resulting 200 proves (a real STARK verification, really bound to the settlement) and what it does NOT prove (that this agent spent its own funds or generated its own proof). Four outcomes, never conflated: no_payment_required (free), paid (200 after proof -- content + receipt + manifest + honesty label), refused (402 again after the proof was submitted -- the server's own reason, verbatim: a result, not an exception), unreachable (transport failure or an unrecognized HTTP status -- says nothing about the merchant). A missing proof_url on a non-demo host that requires payment returns a plain input error instead, since no request was ever sent to guess at. STANDARD x402 v2 (since 0.7.0): if the 402 carries the x402 foundation's PaymentRequired document (standard base64 of JSON, x402Version 2) with an exact offer on a Starknet network, this tool pays it the standard way instead: the configured Starknet account signs a SNIP-9 authorization for exactly that transfer, the merchant's facilitator settles it and pays the gas, and the same GET is retried with PAYMENT-SIGNATURE. A 'paid' outcome then carries standard{scheme, network, payTo, amount, asset, payer,… Input parameters: - `proof_url` (string): Where to download a pre-generated, gzipped STARK proof to submit. Defaults to the published demo proof when url's host is demo.pay.vauban.tech. REQUIRED for any other host. - `url` (string, required): The resource URL to fetch (http(s)). ## Diagnostics Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/tech-vauban-pay-mcp/vauban-pay-mcp#diagnostics ## Score history - 2026-09-21: 68 - 2026-09-20: 67 - 2026-09-19: 67 - 2026-09-18: 67 - 2026-09-17: 66 - 2026-09-16: 66 - 2026-09-15: 65 - 2026-09-14: 65 - 2026-09-13: 64 - 2026-09-12: 64 - 2026-09-11: 63 - 2026-09-10: 63 - 2026-09-09: 62 - 2026-09-08: 47 - 2026-09-07: 47 ## Common questions ### What is the tech.vauban/pay-mcp server? tech.vauban/pay-mcp is listed in the public MCP registry as tech.vauban/pay-mcp. x402 tools for MCP clients: pay exact/Starknet or STARK-receipt 402s, verify, JCS-hash. No account. This page covers its npm package (@vauban-pay/mcp). ### Is the tech.vauban/pay-mcp server safe to use? tech.vauban/pay-mcp scores 68 out of 100 on VerifyMCP. It declares no install or post-install scripts. 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 tech.vauban/pay-mcp server expose? tech.vauban/pay-mcp exposes 6 tools: jcs_hash, make_payment, verify_receipt, request_delegation_grant, check_merchant, pay_for_resource. Their descriptions and schemas cost roughly 1,688 tokens of context every time the server is loaded. ### Is the tech.vauban/pay-mcp server still maintained? tech.vauban/pay-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 tech.vauban/pay-mcp server under? tech.vauban/pay-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. ## Links - npm package: https://www.npmjs.com/package/@vauban-pay/mcp - Socket report: https://socket.dev/npm/package/@vauban-pay/mcp - Changelog RSS feed: https://verifymcp.io/servers/tech-vauban-pay-mcp/vauban-pay-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/tech-vauban-pay-mcp/vauban-pay-mcp.json - HTML version of this page: https://verifymcp.io/servers/tech-vauban-pay-mcp/vauban-pay-mcp