@slippay/mcp
v0.2.0
Published
Give your agent's checkout a limit it can prove. SlipPay MCP server: pay, re-verify the bound, check status.
Maintainers
Readme
@slippay/mcp
Give your agent's checkout a limit it can prove.
One tool to let an AI agent pay. One tool to re-verify the limit it can't break — locally, offline, in seconds. SlipPay runs on Stellar/Soroban: settlement in ~5s for a fraction of a cent, and the agent's wallet enforces a machine-proved spending bound on-chain.
Most agent-checkout tools gate spend with a configured guard — "abort if the total drifts more than 5%." That's a number someone typed. SlipPay's bound is a theorem, and slippay_verify hands it to you as an object you re-check yourself — no install, no trust.
Install
// Claude Desktop / any MCP client — mcpServers config
{
"mcpServers": {
"slippay": {
"command": "npx",
"args": ["-y", "@slippay/mcp"],
"env": {
"SLIPPAY_API_KEY": "sk_live_..." // for slippay_pay / slippay_status
}
}
}
}slippay_verify needs no key and no network — it works the moment the server loads.
Tools
slippay_verify · the one that matters
Re-verify a SlipPay proof-carrying certificate against the agent spec it covers. Returns:
- the spec ↔ certificate SHA-256 binding (tamper-evidence — change a byte, it goes red),
- structural coherence of the certificate,
- the exact SMT-LIB proof obligations the compiler discharged (copy-runnable in any
z3).
Call it before trusting any counterparty agent's claimed limit. Nothing is sent anywhere.
slippay_verify(certificate: <cert JSON>, spec: <the .axl spec>)slippay_pay
Send a payment from your SlipPay agent wallet. Executes only if it stays within the proved per-transaction and sliding-window limits.
slippay_pay(recipient: "G…", amount: "0.50", asset: "USDC", memo?: "order-123")slippay_status
Look up a payment by reference / transaction hash. Returns settlement status and the on-chain link.
slippay_status(reference: "<tx hash>")Env
| var | default | used by |
|---|---|---|
| SLIPPAY_API_KEY | — | slippay_pay, slippay_status |
| SLIPPAY_API_BASE | https://api.slippay.cc/api/v1 | slippay_pay, slippay_status |
Why a proved bound
A configured guard fails open: misconfigure it, or let an attacker influence the inputs it reads, and the cap is whatever the runtime says it is. A proved bound holds for every reachable state of the contract — the proof is over the state machine, not over one execution. slippay_verify is what lets a third party confirm that without taking our word for it. The day a config-guard competitor ships a real proof, they've conceded their guard was never enough.
Re-verify in the browser too: app.slippay.cc/verify.
Built on Stellar · proofs discharged by z3 · part of SlipPay.
