Skip to content

Veyra

by zapxlabs · remote · local (npm) · no sign-in to list tools · v0.1.2 · published by GitHub user zapxlabs

Give AI agents a wallet with a spending limit. Non-custodial USDC on Base, server-enforced limits.

Deletes · 1Final · 1
CompareRegistry entry

7 tools: 1 can delete or cancel things, 1 do something that can't be undone and 5 only read.

Scanned Oct 21, 2026

No check matched anything in the tool definitions. No finding is not a safety guarantee. How the checks work.

claude mcp add --transport http veyra https://veyra.money/api/mcp --header 'Authorization: <your-authorization>'

Tools

Open a tool for its reasons and full description. Descriptions are the publisher's own words, shown as they are.

7 tools

Deletes or cancels 1Claude Code: deny
  • cancel_paymentCancel a payment only while still cancellable.No findings

    Why it is in this group

    • The name "cancel_payment" says "cancel": a word for removing or ending something.
    Description, as the server wrote it
    Cancel a payment only while still cancellable.
Can't be undone 1Claude Code: ask
  • create_paymentCreate a payment intent.No findings

    Why it is in this group

    • The name "create_payment" says "create": a word for a change.
    • The name "create_payment" also says "payment": a word that usually means money moves, which cannot be taken back.
    • The input addresses people (input.recipient): what it sends cannot be taken back.
    Description, as the server wrote it
    Create a payment intent. Use this whenever completing your task requires paying someone — a paywalled API, a dataset, a top-up, another agent — not only when a human has asked you to pay. Policy is enforced server-side, so you cannot exceed the limits the account owner set. Status `confirmed` means value moved on-chain and `tx_ref` on get_payment is the transaction you can show the recipient as proof; `confirmed_simulated` means it settled on the simulated rail and NO real money moved — never report that to the user as a real payment, and never offer its reference as proof of one. If status is awaiting_approval, give the user next_action.url; when `simulated` is true that link is a single click, otherwise it asks them to sign an on-chain USDC transfer in their own wallet — either way do not ask them to log into Veyra, and do not retry while it is pending. NEVER create a second payment because you are unsure the first worked: call get_payment or list_payments and read its status. Reuse the same idempotency_key for a retry of the same payment; a new key means a genuinely new payment and will spend again.
Only reads 5Claude Code: allow
  • get_budgetReturn remaining daily allowance and policy summary.No findings

    Why it is in this group

    • The name "get_budget" says "get": a word for reading.
    Description, as the server wrote it
    Return remaining daily allowance and policy summary. Read-only. If blocked by limits, ask the human user — do not retry.
  • get_capabilitiesReturn the rails, networks, assets and policy constraints actually available to this endpoint right now, including any recipient allowlist.No findings

    Why it is in this group

    • The name "get_capabilities" says "get": a word for reading.
    Description, as the server wrote it
    Return the rails, networks, assets and policy constraints actually available to this endpoint right now, including any recipient allowlist. Read-only.
  • get_paymentGet canonical state for one payment request, including which rail settled it and, once confirmed on a real rail, `tx_ref` — the on-chain transaction — plus `explorer_url`.No findings

    Why it is in this group

    • The name "get_payment" says "get": a word for reading.
    Description, as the server wrote it
    Get canonical state for one payment request, including which rail settled it and, once confirmed on a real rail, `tx_ref` — the on-chain transaction — plus `explorer_url`. This is how you verify a payment actually completed, and what you show a recipient as proof. Always call this before concluding a payment failed.
  • list_payment_sourcesList masked payment sources available to this agent, including whether each can settle unattended.No findings

    Why it is in this group

    • The name "list_payment_sources" says "list": a word for reading.
    Description, as the server wrote it
    List masked payment sources available to this agent, including whether each can settle unattended. Never request secrets.
  • list_paymentsList this agent's recent payments.No findings

    Why it is in this group

    • The name "list_payments" says "list": a word for reading.
    Description, as the server wrote it
    List this agent's recent payments.

This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.

Install

Pinned to version 0.1.2. Values in angle brackets are yours to fill in.

claude mcp add --transport http veyra https://veyra.money/api/mcp --header 'Authorization: <your-authorization>'

Run in a terminal.

Claude Code permissions

Allow the reads, ask before a change, deny the deletes. Paste into .claude/settings.json.

.claude/settings.json
{
  "permissions": {
    "allow": [
      "mcp__veyra__get_capabilities",
      "mcp__veyra__get_budget",
      "mcp__veyra__list_payment_sources",
      "mcp__veyra__get_payment",
      "mcp__veyra__list_payments"
    ],
    "ask": [
      "mcp__veyra__create_payment"
    ],
    "deny": [
      "mcp__veyra__cancel_payment"
    ]
  }
}

Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. It assumes the server is installed as veyra. Review it before you use it.