From wauth-stripe
Perform Stripe actions safely through the WAUTH Stripe doorkeeper — propose a plan, let WAUTH classify the risk tier, route risky actions to a human passkey/liveness approval, then execute with a credential the agent never holds. Use whenever the user wants to refund, pay out, charge, manage subscriptions/customers/products/prices/coupons, or read Stripe data via WAUTH.
How this skill is triggered — by the user, by Claude, or both
Slash command
/wauth-stripe:wauth-stripeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You act through a **doorkeeper**: a separate trust domain that holds the real Stripe secret key.
You act through a doorkeeper: a separate trust domain that holds the real Stripe secret key.
You (the agent) never see or handle that key. You hold only a least-privilege agent key,
supplied to you as the wauth-stripe MCP server's bearer token. Your job is to propose actions;
WAUTH classifies their risk, and for risky ones a human approves with a passkey (plus a live
face scan for the riskiest). The doorkeeper performs the action and returns a signed receipt.
Never ask the user for, accept, or store a Stripe sk_… key, and never call the Stripe API
directly. Everything goes through the wauth-stripe MCP tools. If a task seems to need the raw
key, stop — the doorkeeper is the only thing that should ever hold it.
plan_action does)Thresholds, "new destination" detection, and bulk size can escalate a tier. Always trust the
tier that plan_action returns; never infer it yourself.
plan_action — describe the action ({ action, amount, currency, destination, … }). Returns plan_id, tier, action_hash, and a human-readable summary. No Stripe call happens yet.request_approval_credential → complete_approval_credential (submit the acknowledgement) → an action-approval credential lands in the wallet.get_plan until the action-approval credential exists.request_presentation → present_vp — present your wallet's verifiable presentation (+ SSH proof) to exchange the approval for a single-use capability.execute_authorised_action — the doorkeeper performs the Stripe action with its own key and returns the result + a signed receipt. It takes only plan_id; you cannot re-parameterise at execution time.get_receipt, list_audit_events, search_receipts, verify_audit_chain.enrol_developer, issue_wallet_credentials, delegate_agent_identity, or register passkeys — those require the admin key and are filtered out of your tools/list. That's expected; ask the operator.plan_action says T3, a live human approval is mandatory.get_plan; do not retry execute_authorised_action until the capability is minted.Connection details and the full tool list live in the doorkeeper's
CONNECT.md/MCP.md. The trust model isTHREAT-MODEL.md(the doorkeeper must be a different trust domain than you).
npx claudepluginhub advatar/get.wauth.plugins --plugin wauth-stripeProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.