sh.agentcard/agentcard
REMOTE · MCP.AGENTCARD.SH · SCANNED AUG 3
Prepaid virtual cards for AI agents: one-time cards, spend caps, human approvals.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability54
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 7861 tokens (~157/item across 50 items; 50 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management17
- Stability observed for 5 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · mcp.agentcard.sh
claude mcp add --transport http sh-agentcard-agentcard https://mcp.agentcard.sh/mcp
[mcp_servers.sh-agentcard-agentcard] url = "https://mcp.agentcard.sh/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sh-agentcard-agentcard": {
"type": "remote",
"url": "https://mcp.agentcard.sh/mcp",
"enabled": true
}
}
} openclaw mcp add sh-agentcard-agentcard --url https://mcp.agentcard.sh/mcp --transport streamable-http
mcp_servers:
sh-agentcard-agentcard:
url: "https://mcp.agentcard.sh/mcp" {
"mcpServers": {
"sh-agentcard-agentcard": {
"type": "http",
"url": "https://mcp.agentcard.sh/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 3 Aug 26 +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.
- 1 Aug 26 +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.
- 31 Jul 26 +6
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 29 Jul 26 +42
- HSTS header: pass → fail ▼ security
- Transport: unverified → pass ▲ security
- Authorization: Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. security
- MCP protocol: unverified → pass ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- First check of Schema quality: fail functional
- First check of Schema quality: good functional
- First check of Tool coverage: 100 functional
- First check of Tool coverage: 100 functional
- First check of Schema quality: fail functional
- 27 Jul 26 +21
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 3
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://mcp.agentcard.sh/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mcp.agentcard.sh | CN=WE1,O=Google Trust Services,C=US | 26 Jul 2026 | 24 Oct 2026 | ECDSA 256 | ECDSA-SHA256 | c7c62f1e2c602fc60e2e1649875e2365 |
| SANs: mcp.agentcard.sh | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
DNSSEC insecure
Validation of mcp.agentcard.sh. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| sh. | present | 55297 | 8 | Verified |
| agentcard.sh. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://mcp.agentcard.sh/.well-known/oauth-protected-resource/mcp"
Bearer resource_metadata="https://mcp.agentcard.sh/.well-known/oauth-protected-resource/mcp" Protected resource metadata
| Document | https://mcp.agentcard.sh/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.agentcard.sh/mcp |
| Authorisation server | https://mcp.agentcard.sh/ |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.agentcard.sh/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.agentcard.sh/mcp | HTTPS enforced | 301 | https://mcp.agentcard.sh/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
add_funds ~248
Generate a secure checkout link the user opens to add cash to their own balance (the money that funds new cards) via Apple Pay or Google Pay, in USD. Calling this tool moves NO money and initiates NO transfer: it only prepares a single-use hosted payment page — the exact equivalent of the user clicking 'Add funds' in the dashboard. The user personally reviews, authorizes, and completes (or abandons) the payment in their own browser with their own payment method; you never see or handle payment credentials. If a one-time phone verification is needed first, this tool automatically sends the user a code and tells you where it went: ask the user for the code, call verify_phone with it, then call add_funds again.
| Name | Type | Req | Description |
|---|---|---|---|
| amount_cents | number | yes | Amount to add in cents (e.g. 5000 = $50.00). Typical range: $20.00 to $10,000.00 (2000 to 1000000 cents); the exact range depends on the active funding provider and is returned by the API when the am… |
| payment_method | string | — | Payment method for the checkout. Defaults to apple_pay. |
| Name | Type | Req | Description |
|---|---|---|---|
| amountUsd | string | — | Amount of the created checkout in USD. |
| checkoutUrl | string | — | Single-use payment link to hand the user verbatim (present when a checkout was created). |
| message | string | yes | Human-readable result or next step. |
No examples provided.
approve_request ~195
Resolve a pending approval request (approve or deny) once the USER has decided. Use this after get_card_details or create_card returns a 202 requiring approval, or for a row from list_pending_approvals. For card_details and transaction, approval automatically completes the follow-up action and returns the result. For cross_app actions (asks from another app: close/pause/resume a card, change a limit, view details), approval records the user's consent and the REQUESTING app completes the action from its side when it retries with the approval id.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | The original action type from the approval prompt (list_pending_approvals rows carry it as action). |
| approval_id | string | yes | The approval request ID |
| decision | string | yes | Whether to approve or deny the request |
| resource_id | string | yes | Card ID (for card_details and cross_app actions) or approval ID (for transaction) |
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | — | The original action type from the approval prompt: 'card_details' or 'transaction'. |
| card | object | — | The card resource returned by the approved follow-up action, when applicable. |
| decision | string | — | The decision that was applied: 'approved' or 'denied'. |
| message | string | yes | Human-readable summary of the approval outcome and any follow-up action. |
| status | string | — | Outcome of the request: 'denied', 'card_details', 'card_created', 'resolved' (cross_app approvals: consent recorded, the requesting app completes the action), 'personal_surface_only' (company-connect… |
No examples provided.
attach_card ~234
Attach the user's OWN Visa card to Agentcard so purchases charge that card directly — no identity verification (KYC) and no balance funding needed. Two-phase and conversational: the first call returns a secure link the user opens (about a minute: a one-time code from their bank plus a passkey); call attach_card again to check whether they finished. Once attached, create_card automatically mints against the attached card. If the card is not eligible (for example a Chase-branded, business, or non-US card), fall back to create_card, which issues an Agentcard funded from the user's cash balance.
| Name | Type | Req | Description |
|---|---|---|---|
| additional | boolean | — | Attach ANOTHER card while one is already active (multi-card). Default false: with a card already attached the tool answers already_attached instead of starting a new enrollment. New cards become the… |
| restart | boolean | — | Set true ONLY when the user lost or never received a pending attach link — starts a fresh link. Never needed on the first call or for normal status checks. |
| Name | Type | Req | Description |
|---|---|---|---|
| attachUrl | string | — | The secure link the user opens to add their card. Present only when status is "attach_started". |
| card | object | — | Display details of the attached card (brand, last4). Present on "attached" and "already_attached". |
| connectedCardId | string | — | The attachment id. Present on "attach_started", "attached", and "already_attached". |
| expiresAt | string | — | When the attach link expires (ISO 8601). Present only when status is "attach_started". |
| message | string | yes | Human-readable result or guidance for the next step. |
| reason | string | — | Why the card cannot be attached (e.g. "issuer_excluded", "commercial_card"). Present only when status is "attach_ineligible". |
| status | string | — | Outcome discriminator: "attach_started" (send attachUrl to the user, then call attach_card again to check), "pending" (user has not finished the link yet — check again after they do), "attached" (don… |
No examples provided.
buy ~390
Shop and check out, in natural language, across the merchants the user has linked (DoorDash, etc.). Pass the whole ask as `request` — e.g. "order a caesar salad from Zuni on DoorDash" — and this tool runs the shopping flow for you. It is CONVERSATIONAL: this tool RETURNS a `conversation_id`; pass that SAME `conversation_id` back on every follow-up (your reply to a question, "add a coke", "yes, check out") so it continues the SAME order. Omit it (or set new_order=true) only to start a fresh order. It will ask for the delivery address and have you confirm the cart and total. CHECKOUT (which charges a one-time card) happens ONLY after the user explicitly confirms in a later message — relay the confirmation through `request` ("yes, place the order") on the SAME conversation_id. If it hands out a merchant login link (hosted connect), just reply on the SAME conversation_id once the user finishes (e.g. "done — I logged in") and it verifies the link itself. Logins started here have no pending_id, so the buy_connect / buy_connect_status pair does not apply to them. Call get_instructions FIRST for the current usage guide before your first buy.
| Name | Type | Req | Description |
|---|---|---|---|
| conversation_id | string | — | The conversation_id returned by a previous buy call. Pass it to continue the SAME order (keeps the cart + confirmation). Omit to start a new order. |
| new_order | boolean | — | Start a fresh shopping conversation instead of continuing the current one. Use when beginning an unrelated order (ignores any conversation_id). |
| request | string | yes | The natural-language ask or follow-up, e.g. "order a caesar salad from Zuni on DoorDash", "deliver to 123 Main St", or "yes, place the order". |
| Name | Type | Req | Description |
|---|---|---|---|
| conversation_id | string | — | The conversation id to thread back as conversation_id on the next buy call to continue the SAME order. Present on a successful assistant turn. |
| message | string | yes | The assistant's conversational turn (it may ask for the delivery address, show the cart + total, confirm, or report a placed order), or an error explanation. |
| messages | array | — | The same turn split into ordered messages for multi-bubble surfaces (each narration segment, then the final reply/confirmation). `message` is the same content consolidated; clients that show one bubb… |
| status | string | — | Discriminator for the outcome. 'assistant_turn' when the buy loop replied; 'conversation_start_failed' or 'request_failed' on errors. |
No examples provided.
buy_connect ~166
Connect a merchant for shopping. For merchants that need a real login (e.g. DoorDash) this opens a secure hosted browser session and returns a URL the user opens to log in; after they finish, call buy_connect_status with the pending_id to confirm. Merchants that need no login (e.g. Agentcard Flights) come back ready immediately. Use this instead of buy_link_merchant for hosted-login merchants. This tool pairs only with buy_connect_status and only tracks logins it started itself; a login link handed out by the conversational `buy` tool has no pending_id and is verified inside that same buy conversation (the user replies there, e.g. "done — I logged in").
| Name | Type | Req | Description |
|---|---|---|---|
| merchant | string | yes | merchant slug (e.g. doordash) |
| Name | Type | Req | Description |
|---|---|---|---|
| loginUrl | string | — | URL the user must open to log in to the merchant. Absent for auto-link merchants. |
| merchant | string | — | The merchant slug, present when an auto-link merchant needs no login. |
| message | string | yes | Human-readable next step. |
| pendingId | string | — | Session id to pass to buy_connect_status. Absent for auto-link merchants. |
| status | string | — | Outcome: 'pending' (hosted login started), 'ready'/'linked' (auto-link merchant — no login needed), or 'error'. |
No examples provided.
buy_connect_status ~145
Check the status of a hosted merchant login started with buy_connect. Returns linking (still in progress — call again in a few seconds), linked (success — the merchant is ready to shop), expired, or error. Pass the merchant and the pending_id from buy_connect. ONLY for logins started by the buy_connect tool: a login link handed out by the conversational `buy` tool has no pending_id — for those, reply to the same `buy` conversation ("done — I logged in") instead of calling this.
| Name | Type | Req | Description |
|---|---|---|---|
| merchant | string | yes | merchant slug (e.g. doordash) |
| pending_id | string | yes | The pending_id returned by buy_connect. |
| Name | Type | Req | Description |
|---|---|---|---|
| cart_carried_over | boolean | — | True when a cart built anonymously before linking was moved onto the linked account — re-show it (buy_view_cart) and re-confirm the total before checkout. |
| merchant | string | — | The merchant slug, present when linked. |
| message | string | yes | Human-readable status / next step. |
| status | string | — | Connect state: 'linking', 'linked', 'expired', or 'error'. |
No examples provided.
buy_list_merchants ~42
List merchants available for agent commerce (Rappi, Good Eggs, DoorDash) and whether this user has linked each one. Link a merchant before shopping it.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| count | number | — | Number of merchants returned. |
| merchants | array | — | Available commerce merchants and this user's link status for each. |
| message | string | yes | Human-readable merchant list (or an error / empty note). |
| status | string | — | Outcome: 'ok', 'empty', or 'error'. |
No examples provided.
buy_unlink_merchant ~57
Disconnect a merchant — drops the saved session + link. The user must re-link (e.g. hosted connect) before shopping it again.
| Name | Type | Req | Description |
|---|---|---|---|
| merchant | string | yes | Merchant slug to disconnect (e.g. doordash). |
| Name | Type | Req | Description |
|---|---|---|---|
| merchant | string | — | The merchant slug that was unlinked (or attempted). |
| message | string | yes | Human-readable unlink outcome. |
| status | string | — | Outcome: 'unlinked', 'not_linked', or 'error'. |
No examples provided.
check_kyc_document ~50
Check the conversational verification state — use after the user uploads their ID via the browser upload link (or any time you need to re-orient). Returns the current step and the fields still missing.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | — |
| missingFields | array | — | — |
| nextStep | string|null | — | — |
| uploadUrl | string | — | — |
| verificationUrl | string | — | — |
No examples provided.
close_card ~147
Permanently close a virtual card. This is irreversible — the card cannot be reopened. Safe to call on an already-closed card (idempotent). The user's rewards card (the card their tokenback redeems onto) is close-protected: closing it returns its balance to the wallet but retires the card number the user may have on file at AI labs, so it requires confirm_rewards_card — set it ONLY after the user explicitly confirms they want the rewards card closed.
| Name | Type | Req | Description |
|---|---|---|---|
| card_id | string | yes | The card ID to close |
| confirm_rewards_card | boolean | — | Required to close the rewards card. Only set after the user explicitly confirms; never set it preemptively. |
| Name | Type | Req | Description |
|---|---|---|---|
| approvalId | string | — | Present when status is approval_required: pass it back as approval_id after the user approves. |
| cardId | string | — | The ID of the card that was closed. |
| message | string | yes | Human-readable confirmation that the card was closed. |
| status | string | — | Outcome discriminator; always "closed" on success. |
No examples provided.
create_card ~538
Create a new virtual debit card. Cards are live and charged for real when used. Money source: by default an active ATTACHED card wins when the user has one (attach_card), otherwise the card is funded from the user's cash balance; pass connected_card_id to mint against a specific attached card, or source "issued" to force the cash balance even when a card is attached. If the balance is short, top up with add_funds. Connections through a company OAuth client have NO card count or amount limits; only first-party personal accounts have per-plan caps. Call get_plan for the limits in effect.
| Name | Type | Req | Description |
|---|---|---|---|
| amount_cents | number | yes | Card funding amount in CENTS, not dollars (minimum 100). 100 = $1.00 and 2500 = $25.00 — a value like 25 would be $0.25. Company-governed connections have no maximum; personal accounts are capped by… |
| connected_card_id | string | — | Multi-card BYOC: mint against a SPECIFIC attached card (an id from the user's attached cards) instead of the newest active one. Omit for the default. |
| expires_at | string | — | Optional hard expiry for a multi-use card (ISO-8601 with timezone, e.g. "2027-01-01T00:00:00Z"). Must be in the future, at most 365 days out. The card closes automatically when it passes. |
| funds_source | string | — | Where the card funds come from. OMIT unless instructed: the server applies the right default (company-connected accounts use the company wallet automatically when the company enables it). company_flo… |
| scope_preset | string | — | Create an AI card: a multi-use card restricted to AI-lab merchants (OpenAI, Anthropic, Gemini); charges anywhere else are declined at authorization. AI cards earn boosted tokenback on eligible spend.… |
| source | string | — | Force the card to be funded from the user's cash balance even when they have an attached card. Omit for the default (an active attached card wins). |
| type | string | — | Card behavior. 'single_use' (default) closes after its first approved charge — right for one-off purchases. 'multi_use' stays open across charges until its total limit is spent — right for subscripti… |
| Name | Type | Req | Description |
|---|---|---|---|
| approvalId | string | — | The approval request ID to pass to approve_request. Present only when status is "approval_required". |
| approvalUrl | string | — | The passkey approval link to send to the user. Present only when status is "approval_pending". |
| balanceCents | number | — | Card balance in cents. Present only when status is "created". |
| balanceDollars | string | — | Card balance formatted as USD dollars, e.g. "12.50". Present only when status is "created". |
| cardId | string | — | The new card ID. Present only when status is "created". |
| cardStatus | string | — | Card status, e.g. "active". Present only when status is "created". |
| expiry | string | — | Card expiry (MM/YY). Present only when status is "created". |
| last4 | string | — | Last four digits of the new card. Present only when status is "created". |
| message | string | yes | Human-readable result or guidance for the next step. |
| reason | string | — | Why the previous identity-verification attempt failed (e.g. "document_unverified_other"). Present only when status is "kyc_required" and a prior attempt was rejected. |
| source | string | — | "connected" when the card was minted against the user's attached card (see attach_card). Absent for wallet-funded cards. |
| status | string | — | Outcome discriminator: "created" (card issued), "approval_required" (human approval needed), "approval_pending" (BYOC passkey approval — send approvalUrl to the user, then retry with the same argumen… |
No examples provided.
create_withdrawal_recipient ~329
Save a bank account as a withdrawal destination for the user's cash balance. Supports US bank accounts (ACH: routing + account number) and international bank accounts (SWIFT wire: IBAN + BIC). Ask the user for their bank details conversationally, then call this once. After saving, use withdraw to request a payout.
| Name | Type | Req | Description |
|---|---|---|---|
| account_number | string | — | ACH only: US account number (4-17 digits). |
| account_type | string | — | ACH only: account type. |
| bank_name | string | — | The recipient bank's name (recommended). |
| beneficiary_name | string | yes | The account holder's full legal name, exactly as the bank knows it. |
| country_code | string | yes | Two-letter country code of the account holder (e.g. 'US', 'DE'). |
| country_specific | object | — | Extra banking fields some countries require: {"ifsc": "..."} for India, {"clabe": "..."} for Mexico, {"bsb": "..."} for Australia. Required for those countries; the validation error names the missing… |
| iban | string | — | International only: IBAN (e.g. DE89370400440532013000). |
| nickname | string | — | A label for this account (e.g. 'My checking'). |
| routing_number | string | — | ACH only: 9-digit US routing number. |
| swift_code | string | — | International only: 8 or 11 character SWIFT/BIC. |
| type | string | yes | ach for US bank accounts; international_wire (SWIFT) for everywhere else. |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable result or next step. |
No examples provided.
get_balance ~61
The user's cash balance: the money that funds new cards. Provisions the balance account on first use. Users add cash with Apple Pay or Google Pay in USD; funds are held as USDC. (Their wallet, meaning the cards themselves, is list_cards.)
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| balanceUsd | string | — | Spendable cash balance in USD (string decimal). |
| confirmingUsd | string | — | Deposit clearing on-chain, not yet spendable (present only mid-deposit). |
| message | string | yes | Human-readable balance summary. |
| status | string | — | Balance account status. |
No examples provided.
get_card_balance ~63
The live balance of ONE virtual card (the user's overall cash balance is get_balance). Prefer this over get_card_details when you only need to verify available funds: it is faster and does not expose sensitive card credentials.
| Name | Type | Req | Description |
|---|---|---|---|
| card_id | string | yes | The card ID |
| Name | Type | Req | Description |
|---|---|---|---|
| balanceCents | number | — | Available balance in cents. |
| balanceDollars | string | — | Available balance formatted as USD dollars, e.g. "12.50". |
| cached | boolean | — | Whether the balance was served from a short-lived cache rather than fetched live. |
| message | string | yes | Human-readable balance summary. |
No examples provided.
get_card_details ~145
Get decrypted PAN, CVV, expiry, and current balance for a specific card. Use this only when you need to fill in a payment form — prefer get_card_balance if you only need the balance. May require human approval before returning credentials. If approval is required, prompt the user and then call approve_request. Card details are encrypted at rest with AES-256-GCM.
| Name | Type | Req | Description |
|---|---|---|---|
| approval_id | string | — | Approval id from a prior approval_required response, once the user has approved. Only for cards created through ANOTHER app: first call without it (the user is emailed an approve link), then retry wi… |
| card_id | string | yes | The card ID |
| Name | Type | Req | Description |
|---|---|---|---|
| approvalId | string | — | The approval request ID to pass to approve_request. Present only when status is "approval_required". |
| balanceCents | number | — | Card balance in cents. Present only when status is "details". |
| balanceDollars | string | — | Card balance formatted as USD dollars, e.g. "12.50". Present only when status is "details". |
| cardId | string | — | The card ID. |
| cardStatus | string | — | Card status, e.g. "active" or "closed". Present only when status is "details". |
| expiry | string | — | Card expiry (MM/YY). Present only when status is "details". |
| last4 | string | — | Last four digits of the card number. Present only when status is "details". |
| message | string | yes | Human-readable card details (or an approval-required prompt). |
| status | string | — | Outcome discriminator: "details" when credentials were returned, "approval_required" when human approval is needed first, "not_accessible" when the card exists outside this connection's scope, "manag… |
No examples provided.
get_instructions ~30
Call this BEFORE using `buy`; returns the latest usage guide for shopping and checking out with AgentCard.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | The latest buy usage guide / instructions text. |
No examples provided.
get_kyc_status ~63
Check the user's identity verification (KYC) status. Returns whether they are verified and, if not, the current state plus the conversational next step. Use this to poll after the user does the face scan, or any time create_card reports kyc_required.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable status / next step. |
| missingFields | array | — | — |
| nextStep | string|null | — | Conversational next step when the flow is in progress. |
| reason | string|null | — | Failure reason from the verification provider when one exists. |
| status | string|null | — | Raw KYC state: "verified", "pending", "requires_input", "duplicate_identity", "canceled", or null if never started. |
| verificationUrl | string | — | — |
| verified | boolean | — | True when identity verification has passed. |
No examples provided.
get_plan ~84
Show the user's current subscription plan, card limits, and this month's usage. Call this before create_card when you need the per-card amount cap or remaining monthly quota, or whenever the user asks about their plan, limits, billing, or upgrading. To cancel a paid plan, the gated tool cancel_plan also exists; call it by name even though it isn't in the tools list.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| cancelAtPeriodEnd | boolean | — | Whether the subscription cancels at the end of the current billing period. |
| cardsRemaining | number|null | — | Cards remaining this month; null means unlimited. |
| cardsThisMonth | number | — | Number of cards created this month. |
| currentPeriodEnd | string|null | — | ISO date the current billing period ends, or null. |
| maxCardAmountCents | number|null | — | Maximum funding per card, in cents; null means no per-card cap. |
| maxCardAmountDollars | string|null | — | Maximum funding per card, formatted as USD dollars, e.g. "500.00"; null means no per-card cap. |
| maxCardsPerMonth | number|null | — | Max cards allowed per month; null means unlimited (connections through a company OAuth client or organization have no card limits). |
| maxLifetimeOrders | number|null | — | Lifetime free-order quota; null means unlimited (paid plans). |
| message | string | yes | Human-readable plan + usage summary. |
| ordersPlaced | number | — | Orders placed (counts toward the free-order quota on Free). |
| plan | string | — | Raw plan id, e.g. 'free', 'basic', or 'pro'. |
| planName | string | — | Display label of the plan, e.g. "Basic ($15/mo)". |
| subscriptionStatus | string|null | — | Stripe subscription status (e.g. 'active', 'past_due'), or null on Free / when unavailable. |
No examples provided.
get_rewards ~89
Show the user's tokenback: balance, lifetime earned, and recent activity. Tokenback pays tokens (1 token = 1¢ of credit value) on settled card spend. AI cards (create_card scope_preset: 'ai_labs') earn a boosted rate on AI-lab purchases, and companies can route a share of their earnings to their users as tokenback. Redeem with redeem_rewards.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| balanceTokens | number | — | Current token balance (1 token = 1 cent). |
| lifetimeEarnedTokens | number | — | Tokens earned all-time. |
| message | string | yes | Human-readable summary. |
| minRedeemTokens | number | — | Minimum tokens per redemption. |
| redeemedTokens | number | — | Tokens redeemed all-time. |
No examples provided.
get_settings ~65
View the user's notification preferences (which email alerts they receive) and authorization settings (whether viewing card details or making transactions requires explicit approval). Authorization settings are read-only here; change notification preferences with the gated tool update_settings, calling it by name even though it isn't in the tools list.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| authorization | object | — | Authorization (approval) settings — read-only. |
| message | string | yes | Human-readable settings summary. |
| notifications | object | — | Email notification preferences. |
No examples provided.
link_account ~237
Link or merge another Agentcard account that belongs to the same person. Use when the user says they already have an account under a DIFFERENT email or phone number — most often after identity verification (KYC) is rejected as a duplicate, which means that person already verified on another account. Two steps: (1) call with { type, identifier } to send a one-time code to that email/phone; (2) call again with the { ticket, code } to verify. If the identifier belongs to a different account, the two accounts are MERGED (the identity-verified account survives and gains the other's email/phone, so both sign in to one account); if no account has it, it is simply added to the current account.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | — | Step 2: the one-time code the user received. |
| identifier | string | — | Step 1: the email address or phone number of the other account to verify. |
| ticket | string | — | Step 2: the ticket returned by step 1. |
| type | string | — | Step 1: which kind of identifier the OTHER account uses. |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable result or next step. |
No examples provided.
list_attached_cards ~81
List the user's ATTACHED cards (their own Visa cards enrolled via attach_card — the BYOC funding source), with ids, brand, last4, expiry, and status. The newest active one is the default mint target; create_card can pick a specific one via connected_card_id. Not the same as list_cards (the virtual cards Agentcard issues).
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| attachedCards | array | — | Attached-card enrollments, newest first. The first active row is the default mint target. |
| count | number | — | Number of non-revoked attached cards. |
| message | string | yes | Human-readable list (or an empty-state note). |
No examples provided.
list_cards ~119
The user's wallet: every live card they hold, with IDs, last four digits, expiry, balance, and status. Start here to find available cards; if none are returned, call create_card to issue one. When the shared wallet is enabled, `wallet` lists every card across all connected apps and companies, each tagged with its source (kind personal/company, the minting app, and the company where applicable) — cards minted by another app or company are read-only from this session: get_card_details and close_card will not work on them.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| cards | array | — | The user's own virtual cards. |
| connectedAccounts | array | — | Read-only cards issued and managed by an organization the user is linked to. |
| count | number | — | Total number of cards across the user's own cards and any connected-account cards. |
| message | string | yes | Human-readable list of cards (or an empty-state message). |
| wallet | array | — | One-wallet view (present when the shared wallet is enabled): every LIVE card across personal and company sources, each tagged with its provenance. Closed cards are excluded; transactions carry histor… |
No examples provided.
list_connections ~59
List the third-party apps the user has connected to their Agentcard account via OAuth (e.g. Kilo), including when each was connected and whether it is still active. Read-only. To revoke an app, call revoke_connection with its clientId.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| connections | array | — | The third-party apps connected to the user's account via OAuth. |
| count | number | — | Number of connected apps. |
| message | string | yes | Human-readable summary of the connected apps. |
| status | string | — | Result status: "no_connections" when none are connected, otherwise "ok". |
No examples provided.
list_payment_methods ~90
List the saved payment methods (used only to pay for flight bookings, not for cards or adding funds). Returns each method with its id, brand, last 4 digits, and expiry, and marks the default one. Use setup_payment_method to add a new one. The gated tools set_default_payment_method and remove_payment_method also exist; call them by name even though they aren't in the tools list.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| count | number | — | Number of saved payment methods. |
| defaultId | string | — | The id of the payment method marked as default, if any. |
| message | string | yes | Human-readable summary of the saved payment methods. |
| paymentMethods | array | — | The saved payment methods. |
| status | string | — | Whether any payment methods are saved. |
No examples provided.
list_pending_approvals ~102
List the user's PENDING approval requests: asks from connected apps (create a card, view full card details, close/pause/resume a card, change a limit) waiting on the user's decision. Surface each one to the user and let THEM decide; after the user answers, resolve with approve_request. NEVER approve or deny on your own — an approval is the user's consent, not yours. Personal sessions only; company-connected sessions have no personal inbox.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| approvals | array | — | Pending, unexpired approval requests, newest first. Each is waiting on the user's decision. |
| count | number | — | Number of pending approvals. |
| message | string | yes | Human-readable list of pending approvals (or an empty-state note). |
| status | string | — | Present only when the list is unavailable: "personal_surface_only" for company-connected sessions. |
No examples provided.
list_transactions ~182
Transactions with amount, merchant, status, and timestamps. Pass card_id for one card's transactions; OMIT it for every card in the account (newest first, each row tagged with its card). Use limit and status to filter. The gated views list_all_transactions and list_transactions_by_payment_method also exist; call them by name even though they aren't in the tools list.
| Name | Type | Req | Description |
|---|---|---|---|
| card_id | string | — | A card ID for that card's transactions; omit for all cards in the account. |
| limit | number | — | Max number of transactions to return (default 20) |
| offset | number | — | Skip this many (all-cards view pagination; ignored for a single card). |
| status | string | — | Filter by transaction status (e.g. PENDING, SETTLED, DECLINED, REVERSED, EXPIRED, REFUNDED) |
| Name | Type | Req | Description |
|---|---|---|---|
| count | number | — | Number of transactions returned. |
| message | string | yes | Human-readable list of transactions (or a "no transactions" note). |
| transactions | array | — | The transactions for the card, newest first. |
No examples provided.
list_withdrawal_recipients ~63
List the user's saved bank accounts for withdrawals, masked (bank name and last four only). Use a recipient's id as recipient_id with withdraw. If the list is empty, collect the user's bank details and call create_withdrawal_recipient first.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| count | number | — | Number of saved bank destinations. |
| message | string | yes | Human-readable list (or an empty-state note). |
| recipients | array | — | Saved bank destinations, masked. |
No examples provided.
manage_subscription ~341
Manage a recurring meal/grocery SUBSCRIPTION (e.g. Locale) — NOT a one-time purchase, and no payment is taken (the subscription auto-bills the card on file at the merchant). action: 'menu_search' (browse the recurring menu; items flagged inPlan are covered by the plan), 'get_skip_dates' (list skipped/paused deliveries), 'skip'/'unskip' (one upcoming delivery date), 'set_skip_dates' (replace the full skip set; [] resumes all), 'update_setting' (change a setting). Locale settings: subscription_size (meals, e.g. 8), calorie_preference (low_calorie|both|moderate), diets (array), longevity_allergens (array), ingredient_allergies (array), default_window ('9am - 6pm'|'3pm - 7pm'|'9am - 12pm'), delivery_instructions (text). Link the merchant first.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | the management action |
| date | string | — | skip/unskip: one ISO delivery date (YYYY-MM-DD) |
| dates | array | — | set_skip_dates: FULL set of ISO dates to skip ([] resumes all) |
| limit | number | — | menu_search: max items |
| merchant | string | yes | merchant slug (e.g. locale) |
| query | string | — | menu_search: term over the recurring menu (e.g. 'salmon'); '' lists everything |
| setting | string | — | update_setting: the setting key (see description) |
| value | — | — | update_setting: the new value (number, string, or array of strings) |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable result or next step. |
No examples provided.
pause_card ~140
Pause a multi-use card: temporarily blocks ALL new charges (reversible — use resume_card to unblock). Right for "stop this subscription for now" or a card the user suspects is compromised but is not sure. Only multi-use cards can be paused; single-use cards close after one charge and cannot be paused.
| Name | Type | Req | Description |
|---|---|---|---|
| approval_id | string | — | Approval id from a prior approval_required response, once the user has approved. Only for cards created through ANOTHER app: first call without it (the user is emailed an approve link), then retry wi… |
| card_id | string | yes | The card ID to pause (from list_cards or create_card). |
| Name | Type | Req | Description |
|---|---|---|---|
| cardId | string | — | The card ID. |
| message | string | yes | Human-readable result. |
| status | string | — | "paused" on success; an error discriminator otherwise (e.g. "not_multi_use", "card_not_updatable"). |
No examples provided.
read_support_chat ~29
Read the message history of a support conversation
| Name | Type | Req | Description |
|---|---|---|---|
| conversation_id | string | yes | The conversation ID |
| Name | Type | Req | Description |
|---|---|---|---|
| count | number | — | Number of messages returned. |
| message | string | yes | Human-readable rendering of the conversation history. |
| messages | array | — | The messages in the conversation, oldest first. |
| status | string | — | Outcome of the read: 'empty' when there are no messages yet, 'ok' when messages were returned. |
No examples provided.
redeem_code ~92
Redeem a promo code that adds money to the user's cash balance. Each code works once per user; the credit lands in the balance and becomes spendable within a minute or two. The gated tool list_codes shows the user's code history; call it by name even though it isn't in the tools list.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | The promo code exactly as the user provided it (case and dashes are forgiven). |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable result or next step. |
No examples provided.
redeem_rewards ~117
Redeem tokenback: the tokens' cash value (1 token = 1¢) lands on the user's rewards card as spending power. The rewards card is permanent and locked to AI-lab merchants (OpenAI, Anthropic, Gemini) — minted on first redemption, topped up after. Check get_rewards first for the balance and the minimum. Ask the user before redeeming.
| Name | Type | Req | Description |
|---|---|---|---|
| tokens | number | yes | How many tokens to redeem (1 token = 1 cent, so 500 tokens = $5.00 of wallet credit). |
| Name | Type | Req | Description |
|---|---|---|---|
| amountCents | number | — | Wallet credit in cents. Present when status is "redeemed". |
| deliveredCardId | string | — | Rewards card the value landed on, when delivery completed inline. Absent = the value sits as wallet credit (it reaches the rewards card within a few minutes when delivery is enabled). |
| deliveredCardLast4 | string | — | Last 4 digits of the rewards card, when delivered inline. |
| message | string | yes | Human-readable result. |
| redemptionId | string | — | The redemption ID. Present when status is "redeemed". |
| status | string | — | "redeemed" on success; an error discriminator otherwise (e.g. "below_minimum", "insufficient_tokens", "redemption_in_progress"). |
No examples provided.
remove_attached_card ~100
Remove (unenroll) one of the user's attached cards. Irreversible for that enrollment: any virtual cards minted against it are closed first, then the card is unenrolled at the network. ALWAYS confirm with the user before calling. Get ids from list_attached_cards. The user can re-attach the same card later with attach_card.
| Name | Type | Req | Description |
|---|---|---|---|
| attached_card_id | string | yes | The attached-card id to remove (from list_attached_cards). |
| Name | Type | Req | Description |
|---|---|---|---|
| closedCards | number | — | How many virtual cards minted against it were closed. |
| id | string | — | The removed attached-card id. |
| message | string | yes | Human-readable confirmation or guidance. |
| status | string | — | "revoked" on success. |
No examples provided.
resume_card ~89
Resume a paused multi-use card so it accepts charges again. The inverse of pause_card.
| Name | Type | Req | Description |
|---|---|---|---|
| approval_id | string | — | Approval id from a prior approval_required response, once the user has approved. Only for cards created through ANOTHER app: first call without it (the user is emailed an approve link), then retry wi… |
| card_id | string | yes | The paused card ID to resume. |
| Name | Type | Req | Description |
|---|---|---|---|
| cardId | string | — | The card ID. |
| message | string | yes | Human-readable result. |
| status | string | — | "active" on success; an error discriminator otherwise (e.g. "card_not_paused"). |
No examples provided.
revoke_connection ~73
Revoke a third-party app's access to the user's Agentcard account. Disconnects the app and invalidates its OAuth tokens; it must reconnect via OAuth to regain access. Pass the clientId shown by list_connections.
| Name | Type | Req | Description |
|---|---|---|---|
| client_id | string | yes | The OAuth client ID of the app to revoke (from list_connections). |
| Name | Type | Req | Description |
|---|---|---|---|
| clientId | string | — | The client ID that was revoked. |
| message | string | yes | Human-readable outcome. |
| revoked | number | — | Number of OAuth tokens that were revoked. |
| status | string | — | Result status: "revoked" when tokens were invalidated, "not_connected" when the app had no active access. |
No examples provided.
send_support_message ~38
Send a message in an existing support conversation
| Name | Type | Req | Description |
|---|---|---|---|
| conversation_id | string | yes | The conversation ID |
| message | string | yes | Your message |
| Name | Type | Req | Description |
|---|---|---|---|
| conversationId | string | — | The ID of the conversation the message was sent to. |
| message | string | yes | Human-readable confirmation that the message was sent. |
No examples provided.
setup_payment_method ~78
Save a payment method used ONLY to pay for flight bookings (the fare is charged to it via a hold at booking; no virtual card is minted for flights). It does NOT fund cards or the cash balance — cards are funded from the balance (see add_funds). Returns a secure checkout URL the user must open to save their card details.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| checkoutUrl | string | — | Secure Stripe checkout URL the user must open to save their payment method. |
| message | string | yes | Human-readable summary of the result. |
| stripeSessionId | string | — | Identifier of the Stripe Checkout session created for the setup. |
No examples provided.
start_kyc ~260
Begin (or resume) identity verification. Verification is CONVERSATIONAL: it starts with a photo of the user's government ID — the backend reads the printed details automatically and the user confirms every value. Only fields the ID does not carry are asked (like the SSN for US documents, or the national ID number for non-US ones); occupation/income questions are never asked. The only browser step is a short face scan at the end. Relay each step to the user as ONE SHORT message (one or two sentences — the current ask only, never the whole flow, never an unrequested link). Returns the next step, ID-photo upload options, and (for legacy hosted-flow accounts) a hosted verification URL instead.
| Name | Type | Req | Description |
|---|---|---|---|
| agreements_accepted | array | — | Keys of the User Agreements the user explicitly accepted, one by one (the full required set from the agreements list — e.g. e_sign, account_opening_privacy, card_terms, accuracy, non_solicitation). O… |
| terms_accepted | boolean | — | DEPRECATED — use agreements_accepted. Pass true once the user has explicitly agreed to the card issuer's cardholder terms in the conversation. |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable summary / next step. |
| missingFields | array | — | Fields still needed from the user. |
| nextStep | string|null | — | Conversational step: id_document | fields | terms | face_verification | review_pending | verified | rejected. |
| reason | string|null | — | Provider reason on rejection. |
| status | string | — | "started", "verified", "rejected", or "unknown". |
| uploadUrl | string | — | Browser upload page for the ID photo (1h validity). |
| verificationUrl | string | — | Face-scan page (conversational flow) or hosted verification URL (legacy flow), 48h validity. |
No examples provided.
start_phone_verification ~126
Send (or re-send) the user's one-time funding verification code (the provider verifies the phone on the user's Agentcard identity, valid 60 days). add_funds already sends this code automatically when verification is needed — call this tool only to RE-send when the code never arrived (any unexpired code still works; sends are rate-limited). Returns the masked destination (text or email) and whether a code was sent; if the phone is already verified it says so and you go straight to add_funds. After the user reads back the code, call verify_phone.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable result or next step. |
No examples provided.
start_support_chat ~31
Start a new support conversation and send the first message
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Your initial support message |
| Name | Type | Req | Description |
|---|---|---|---|
| conversationId | string | — | The ID of the newly created support conversation. Pass this to send_support_message or read_support_chat. |
| message | string | yes | Human-readable summary confirming the conversation was started. |
No examples provided.
submit_kyc_document ~525
Submit the user's ID photo for identity verification. Ways in: (a) image data you hold programmatically (e.g. the user sent the photo in this chat and your platform exposes its bytes) — pass front_base64 (and back_base64 for a license back; its barcode reads most accurately); (b) local (stdio) mode — pass file_path/back_file_path and the file is read from disk; (c) neither — you get a secure upload link to hand the user. Do NOT ask the user what kind of document it is or where it was issued — the type and country are detected automatically from the photo; only relay a question if the result says the type could not be determined. Returns the fields read off the document — SHOW THEM TO THE USER for confirmation before continuing — plus whatever is still missing. If the result says NO identity details could be read, the image did not read as an ID at all: never insist to the user that it was their ID. Supported: JPEG/PNG/WebP up to 12MB (convert iPhone HEIC first).
| Name | Type | Req | Description |
|---|---|---|---|
| back_base64 | string | — | Base64 image bytes of the license back (optional, recommended — the barcode reads most accurately). Same rule: programmatically sourced only. |
| back_file_path | string | — | Local path to the back of the license (optional, recommended). Local/stdio connections only. |
| back_mime_type | string | — | MIME type of back_base64. Defaults to image/jpeg. |
| document_type | string | — | ONLY pass this when the user themselves said what the document is ("here's my license") — otherwise omit it; the type is detected from the photo. Never ask up front. |
| file_path | string | — | Local path to the ID photo (front of license, or passport photo page). Local/stdio connections only — remote connections without image data receive an upload link instead. |
| front_base64 | string | — | Base64 image bytes of the ID front (or passport photo page). ONLY pass base64 you received programmatically from your platform (e.g. an injected chat attachment) — never type or reconstruct image byt… |
| front_mime_type | string | — | MIME type of front_base64 (image/jpeg, image/png, image/webp). Defaults to image/jpeg. |
| issuing_country | string | — | 2-letter ISO country that issued the document (e.g. US, AR). ONLY when the user volunteered it — otherwise omit; it is detected from the photo. Never ask up front. |
| Name | Type | Req | Description |
|---|---|---|---|
| extracted | object | — | Fields read from the document (confirm with the user). |
| message | string | yes | — |
| missingFields | array | — | — |
| nextStep | string|null | — | — |
| status | string | — | processed | document_expired | upload_failed | upload_link_provided |
| unreadable | boolean | — | True when the image was received but NO identity fields could be read from it — it did not read as an ID; never assert to the user that it was one. |
| uploadUrl | string | — | — |
| verificationUrl | string | — | — |
No examples provided.
submit_kyc_fields ~452
Submit identity fields for verification: the ones the ID photo didn't carry (listed by missingFields — the tax/ID number always has to be asked since IDs don't print it; call it "SSN" only for US documents and "national ID number" otherwise), corrections to extracted values the user flagged, and the User Agreements acceptance (agreements_accepted, after presenting each agreement verbatim). That number is forwarded directly to the verification provider and never stored by Agentcard. NEVER ask about occupation, income, spending volume, or account purpose — those are filled automatically and must not be asked.
| Name | Type | Req | Description |
|---|---|---|---|
| address_city | string | — | City of the residential address. |
| address_country_code | string | — | 2-letter ISO country code (e.g. US). |
| address_line1 | string | — | Residential street address, line 1 (e.g. 123 Main St). |
| address_line2 | string | — | Residential street address, line 2 — apartment, suite, or unit. Omit if none. |
| address_postal_code | string | — | Postal / ZIP code of the residential address. |
| address_region | string | — | 2-letter state code for US (e.g. CA). |
| agreements_accepted | array | — | Keys of the User Agreements the user explicitly accepted, one by one — the FULL required set from the agreements list in the previous step's result. Only pass after presenting each agreement verbatim… |
| date_of_birth | string | — | YYYY-MM-DD |
| first_name | string | — | Legal first name, exactly as printed on the ID document. |
| last_name | string | — | Legal last name, exactly as printed on the ID document. |
| phone_number | string | — | E.164 with country code, e.g. +14155551234. |
| ssn | string | — | US documents: 9-digit SSN, dashes optional. Non-US documents: the national ID / tax number printed on the ID. Forward-only — never stored. |
| terms_accepted | boolean | — | DEPRECATED — use agreements_accepted. true once the user explicitly accepted the card issuer's cardholder terms. |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | — |
| missingFields | array | — | — |
| nextStep | string|null | — | — |
| verificationUrl | string | — | Face-scan link, present once everything is collected. |
No examples provided.
submit_user_info ~182
Submit the user's phone number and terms acceptance for a virtual card. Call this after create_card returns user_info_required. Do NOT ask the user for occupation, income, or account purpose — those are never asked. Identity fields (name, date of birth, SSN / national ID, address) belong to the KYC flow: create_card tells you whether it runs conversationally (start_kyc → ID photo → face scan) or via a hosted verification_url. After phone + terms are saved, retry create_card.
| Name | Type | Req | Description |
|---|---|---|---|
| phone_number | string | yes | User's phone number in international E.164 format with a country code (e.g. +1 555 123 4567, +44 7911 123456) |
| terms_accepted | boolean | yes | Must be true — the user accepted the AgentCard cardholder terms of service |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable confirmation that the user information was saved. |
| status | string | — | Outcome of the submission: 'saved' when the user information was stored successfully. |
No examples provided.
surprise_me ~257
Buy the user something totally unexpected and very silly/stupid-fun under a small dollar cap (default $10, hard max $25). Great when the user cannot decide what to order (from DoorDash etc.) or just wants a fun surprise. It kicks off a shopping conversation that FIRST brainstorms deliberately stupid ideas, picks ONE genuinely unexpected item, builds the cart, and shows the item + exact total. It NEVER checks out by itself: the reply includes a conversation_id — relay the user's explicit confirmation ("yes, place it") through the `buy` tool on that SAME conversation_id, exactly like a normal order. Each surprise_me call starts a fresh surprise; use `buy` for all follow-ups (answers, tweaks, the confirmation).
| Name | Type | Req | Description |
|---|---|---|---|
| max_dollars | number | — | Hard spend cap in dollars, total including fees. Optional; default 10, values above 25 are clamped to 25. |
| merchant | string | — | Optional merchant hint the surprise should come from, e.g. 'doordash'. Omit to let the agent pick. |
| vibe | string | — | Optional notes/vibe from the user, e.g. "make it food", "something for my desk", "they love ducks". |
| Name | Type | Req | Description |
|---|---|---|---|
| conversation_id | string | — | The conversation id to thread back as conversation_id on the next buy call to continue the SAME order. Present on a successful assistant turn. |
| message | string | yes | The assistant's conversational turn (it may ask for the delivery address, show the cart + total, confirm, or report a placed order), or an error explanation. |
| messages | array | — | The same turn split into ordered messages for multi-bubble surfaces (each narration segment, then the final reply/confirmation). `message` is the same content consolidated; clients that show one bubb… |
| status | string | — | Discriminator for the outcome. 'assistant_turn' when the buy loop replied; 'conversation_start_failed' or 'request_failed' on errors. |
No examples provided.
update_card_limit ~218
Change a multi-use card's total spending limit. Raising it reserves the extra amount from the user's cash balance (top up with add_funds if short); lowering it frees the difference, but the new limit can never go below what the card has already spent. Single-use cards cannot be resized.
| Name | Type | Req | Description |
|---|---|---|---|
| approval_id | string | — | Approval id from a prior approval_required response, once the user has approved. Only for cards created through ANOTHER app: first call without it (the user is emailed an approve link), then retry wi… |
| card_id | string | yes | The multi-use card ID to resize. |
| new_limit_cents | number | — | Deprecated alias for spend_limit_cents. Prefer spend_limit_cents (matches the docs and the REST API). |
| spend_limit_cents | number | — | The new TOTAL spending limit in cents (minimum 100). This is the lifetime cap, not a delta: a card that spent $20 of a $50 limit, resized to 8000, can spend $60 more. |
| Name | Type | Req | Description |
|---|---|---|---|
| balanceCents | number | — | The remaining spendable balance in cents. |
| cardId | string | — | The card ID. |
| message | string | yes | Human-readable result. |
| spendLimitCents | number | — | The new total limit in cents. |
| status | string | — | "updated" on success; an error discriminator otherwise (e.g. "limit_below_spent", "insufficient_collateral"). |
No examples provided.
upgrade_plan ~154
Start a paid-plan upgrade. Choose the target plan: 'basic' ($15/mo — 15 cards/month, up to $500 per card) or 'pro' ($100/mo — 50 cards/month, up to $1,000 per card). Defaults to 'basic' if omitted. Returns a Stripe Checkout URL the user must open in their browser to complete payment. After they finish checkout, the plan updates automatically; verify with get_plan. Use only when the user explicitly wants to upgrade. To cancel a paid plan instead, the gated tool cancel_plan also exists; call it by name even though it isn't in the tools list.
| Name | Type | Req | Description |
|---|---|---|---|
| plan | string | — | Which plan to upgrade to. Defaults to 'basic'. |
| Name | Type | Req | Description |
|---|---|---|---|
| checkoutUrl | string | — | Stripe Checkout URL the user must open to complete payment. Present only when status is checkout_required. |
| message | string | yes | Human-readable summary of the upgrade outcome. |
| plan | string | — | Display label of the target plan, e.g. 'Basic' or 'Pro'. Present when the requested plan is known. |
| status | string | — | Discriminator for the outcome branch. |
No examples provided.
verify_phone ~108
Check the one-time code the user received from start_phone_verification. On success the balance is unlocked for funding (the verification stays fresh for 60 days) — call add_funds next. A wrong or expired code returns a recoverable status so you can ask the user to re-check it, or call start_phone_verification to resend.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | The one-time code the user received, as a string (keep any leading zeros — do not send it as a number). |
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | Human-readable result or next step. |
No examples provided.