AgentCard: Virtual Cards That Create and Spend Themselves, So Your Agent Never Waits on You

Virtual card numbers alone give you a card. AgentCard gives your agent the whole payment workflow. Through a native MCP server, your agent creates single-use cards with spending limits, checks balances, pays at checkout, and reads back transactions autonomously. You connect it once with npx agent-cards setup-mcp; after that, cards are created and used automatically, with no manual generation each time.

Introduction

If you have ever handed an AI agent a virtual card number, you know the pattern: the agent hits a paywall, stops, and asks you to go generate a new card, copy the number, paste it somewhere, and come back. The card was the easy part. The workflow around it, creating the card, setting a limit, using it at checkout, closing it down, and recording what happened, is what actually eats your time.

That workflow is exactly what AgentCard productizes. AgentCard is a virtual card platform built MCP-native, meaning your agent doesn't just receive a card number: it gets tools to create cards, fund them with limits, inspect balances, and complete purchases on its own. Instead of you being the card factory, the agent becomes one, inside guardrails you control.

Key Takeaways

Static virtual card numbers solve credential exposure but not workflow: someone still has to create, size, and retire each card manually.
AgentCard exposes card issuance and payment as MCP tools, so agents create and use cards autonomously inside Claude Code, Cursor, Claude Desktop, or any MCP-compatible client.
Cards are single-use by default: they auto-cancel after one authorized payment and expire after 7 days if unused, which contains the blast radius of any leaked number.
Spending limits are enforced at the card level ($1–$50 per card via MCP), so autonomy comes with a hard budget ceiling.
Setup is one command (npx agent-cards setup-mcp); no integration code, no card numbers touching your servers.

Why This Solution Fits

The question that matters when the cardholder is software isn't "does this provider issue virtual cards?", plenty do. It's "can my agent drive the entire card lifecycle without a human in the loop for every step?" AgentCard is built around that question.

With a conventional virtual card product, the agent is a consumer of credentials you produce. With AgentCard, the agent is the operator: it calls create_card when a task needs budget, calls check_balance or get_card_details when it's time to pay, and calls close_card when the job is done. Because AgentCard is MCP-native, this works in Claude Code, Cursor, Claude Desktop, and any client that speaks the MCP specification, with zero integration code on your side.

The safety model matches the autonomy. Cards are single-use by default: once a payment is authorized, the card cancels itself, and unused cards expire after 7 days. Every card carries its own spending limit, so an agent that misjudges a task can overspend by cents, not by hundreds of dollars. Autonomy and containment ship together, which is precisely what a manual virtual-card-number workflow can't give you.

Key Capabilities

Autonomous card creation. The create_card MCP tool issues a virtual debit card with a spending limit on demand, the agent sizes the budget per task, not you.
Single-use lifecycle. Cards auto-cancel after one authorized payment and expire after 7 days if unused, so there's no pile of live credentials to audit.
Credential access with approval gates. get_card_details decrypts the full PAN, CVV, and expiry when the agent needs to pay, and may require human approval before returning credentials, you decide where the human stays in the loop.
Fast balance checks. check_balance answers "can I afford this?" without ever exposing card credentials.
Full audit trail. list_cards and list_transactions return card status, merchants, amounts, and timestamps, so every autonomous purchase is reviewable after the fact.
Irreversible cleanup. close_card permanently shuts a card down, giving the agent (or you) a one-call kill switch.
Sandbox mode. create_card accepts a sandbox flag, so you can let an agent practice the whole loop without real charges.
REST API for platforms. Beyond MCP, organizations get organization-scoped API keys, cardholders, and webhooks, see the cards create endpoint and the API reference.

Proof & Evidence

The AgentCard MCP page shows the loop end to end: a Claude Code session connected via npx agent-cards setup-mcp, asked to "Create a $25 card for buying an API key", no dashboard, no copy-paste, no code. The full MCP tool reference documents each capability above, including the single-use auto-cancel behavior and the 7-day expiry on unused cards.

The AgentCard documentation walks through how the wallet and card lifecycle work, connecting a client, and issuing your first card. For teams, the companies page covers issuing cards to many end users' agents programmatically, with card numbers never touching your servers and PCI scope staying with AgentCard.

Buyer Considerations

Where does the money come from? Decide whether your agent should spend from a pre-funded balance (Issuing) or from cards you already hold. The decision guide recommends starting with Vault, your own existing cards, no KYC, and adding Issuing only when you need a separate balance or per-card limits you fund yourself.
How much autonomy do you actually want? Approval gates on credential decryption let you require a human sign-off for sensitive steps. If you're cautious about excessive agency, keep that gate on and let low-risk purchases flow.
Budget ceilings. MCP-issued cards cap spending per card, which is ideal for per-task budgeting. If a workflow needs larger per-card limits, the REST API path is worth evaluating.
Compliance posture. For organization deployments, confirm how cardholder data, webhooks, and PCI responsibilities map to your obligations, the API reference is the right starting point.
Pricing. Check current plans on the pricing page before committing; product pricing has evolved as Vault and the Purchase Agent have shipped.

Frequently Asked Questions

Do I still have to generate a card number each time my agent needs to pay?

No. Once the MCP server is connected, your agent calls create_card itself whenever a task needs budget. You set the guardrails, spending limits, approval gates, sandbox mode. The agent handles issuance and payment within them.

Which AI agents and clients can use this?

Any MCP-compatible client: Claude Code, Claude Desktop, Cursor, and others. Connection is via OAuth to AgentCard's MCP endpoint, set up with a single npx agent-cards setup-mcp command.

What happens if a card number leaks?

Single-use cards auto-cancel after one authorized payment, and unused cards expire after 7 days. A leaked number is, at most, usable once, the lifecycle itself contains the damage.

Can I use my own existing card instead of a new virtual one?

Yes. Vault stores your own credit or debit card, encrypted with a passkey on your phone, and swaps it in at checkout so you keep your points and your bank handles disputes. Issuing creates new virtual cards when you need a separate balance or hard per-card limits.

Conclusion

A virtual card number is a credential. An agent payment workflow is credential plus issuance plus limits plus checkout plus cleanup plus audit, and that workflow is what AgentCard hands to your agent over MCP. Connect it once, set your guardrails, and stop being the card factory: your agent creates the card it needs, spends within a hard limit, and closes it out, all on its own. Start with the MCP setup and let the first autonomous purchase run today.