Skip to main content
Glama

agentcard

by sh.agentcard

create_card

The one card tool: get the user a virtual debit card for a purchase. Cards are live and charged for real when used. For a FIRST-TIME user it starts by ADDING the user's OWN Visa or Mastercard — no identity verification (KYC) and no balance funding: the call returns a secure link (attach_started); send it to the user (about a minute: a one-time code from their bank plus a passkey), then call create_card again with the SAME arguments and it mints against the added card. If the user's card cannot be added (issuing_suggested), offer the fallback — an Agentcard funded from their cash balance, which requires KYC the first time — and only after the user agrees, call create_card with source "issued". Established users: the saved default decides (get_settings default_payment — their chosen added card, or the wallet balance); with no saved default, an active ADDED card wins, otherwise the cash balance. Per-call overrides: connected_card_id issues against a specific added card, source "issued" forces the cash balance, restart_setup starts a fresh add-card link. If the balance is short on the issued path, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoCard 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 subscriptions and recurring merchants. Multi-use cards can be paused (pause_card), resumed (resume_card), and resized (update_card_limit).
sourceNoForce the card to be funded from the user's cash balance (the issued path: KYC + wallet funding) even when they have an added card or would otherwise be offered the add-card flow. Use it only after the user explicitly picks the balance option. Omit for the default (an active added card wins; first-time users get the add-card flow).
expires_atNoOptional 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.
amount_centsYesCard 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 their plan — call get_plan for the limits in effect.
funds_sourceNoWhere 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_flow = the company's wallet funds the card; onramp_flow = the user's own wallet.
scope_presetNoCreate 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. Implies type 'multi_use'.
restart_setupNoSet true ONLY when the user lost or never received a pending add-card link (mints a fresh one), or wants to add ANOTHER card while one is already active. Never needed on the first call or for normal retries.
connected_card_idNoMulti-card: issue against a SPECIFIC added card (an id from the user's added cards, see list_added_cards) instead of the newest active one. Omit for the default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
last4NoLast four digits of the new card. Present only when status is "created".
cardIdNoThe new card ID. Present only when status is "created".
expiryNoCard expiry (MM/YY). Present only when status is "created".
reasonNoOn "issuing_suggested": why the card could not be added (e.g. "issuer_excluded", "commercial_card", "attach_unavailable"). On "kyc_required": why the previous identity-verification attempt failed (e.g. "document_unverified_other"), present only when a prior attempt was rejected.
sourceNo"connected" when the card was created against the user's added card. Absent for wallet-funded cards.
statusNoOutcome discriminator: "created" (card issued), "attach_started" (first-time setup — send attachUrl to the user, then call again with the same arguments once they finish), "attach_pending" (user has not finished the add-card link yet), "issuing_suggested" (the user's card could not be added — offer the balance-funded fallback, noting it requires KYC, and only then call again with source "issued"), "approval_required" (human approval needed), "approval_pending" (added-card passkey approval — send approvalUrl to the user, then retry with the same arguments in ~10s), "kyc_required" (issued path only), "user_info_required" (check missingFields: phone/terms go through submit_user_info; consent must be recorded by the connecting platform), "beta_capacity_reached", "issuing_balance_insufficient" (issued path only), "payment_method_declined", "limit_reached", "funding_in_progress" (company wallet funding underway — retry with the same arguments in ~10s), "funding_not_approved", "org_wallet_funding_required", "org_wallet_unavailable" (the company wallet backing this account is not active — the company must finish setup; do not retry immediately), or "rate_limited" (wait ~1 minute, then retry).
messageYesHuman-readable result or guidance for the next step.
attachUrlNoThe secure link the user opens to add their card. Present only when status is "attach_started".
expiresAtNoWhen the add-card link expires (ISO 8601). Present only when status is "attach_started".
approvalIdNoThe approval request ID to pass to approve_request. Present only when status is "approval_required".
cardStatusNoCard status, e.g. "active". Present only when status is "created".
approvalUrlNoThe passkey approval link to send to the user. Present only when status is "approval_pending".
balanceCentsNoCard balance in cents. Present only when status is "created".
missingFieldsNoWhat is missing when status is "user_info_required" (e.g. "termsAccepted", "consent").
balanceDollarsNoCard balance formatted as USD dollars, e.g. "12.50". Present only when status is "created".

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed9 schema fields changed
    • changedInput schema / properties / connected_card_id / description
      Previous value: -"Multi-card BYOC: issue against a SPECIFIC added card (an id from the user's added cards) instead of the newest active one. Omit for the default."New value: +"Multi-card: issue against a SPECIFIC added card (an id from the user's added cards, see list_added_cards) instead of the newest active one. Omit for the default."
    • addedInput schema / properties / restart_setup
      Added value: +{
+  "description": "Set true ONLY when the user lost or never received a pending add-card link (mints a fresh one), or wants to add ANOTHER card while one is already active. Never needed on the first call or for normal retries.",
+  "type": "boolean"
+}
    • changedInput schema / properties / source / description
      Previous value: -"Force the card to be funded from the user's cash balance even when they have an added card. Omit for the default (an active added card wins)."New value: +"Force the card to be funded from the user's cash balance (the issued path: KYC + wallet funding) even when they have an added card or would otherwise be offered the add-card flow. Use it only after the user explicitly picks the balance option. Omit for the default (an active added card wins; first-time users get the add-card flow)."
    • addedOutput schema / properties / attachUrl
      Added value: +{
+  "description": "The secure link the user opens to add their card. Present only when status is \"attach_started\".",
+  "type": "string"
+}
    • addedOutput schema / properties / expiresAt
      Added value: +{
+  "description": "When the add-card link expires (ISO 8601). Present only when status is \"attach_started\".",
+  "type": "string"
+}
    • addedOutput schema / properties / missingFields
      Added value: +{
+  "description": "What is missing when status is \"user_info_required\" (e.g. \"termsAccepted\", \"consent\").",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedOutput schema / properties / reason / description
      Previous value: -"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."New value: +"On \"issuing_suggested\": why the card could not be added (e.g. \"issuer_excluded\", \"commercial_card\", \"attach_unavailable\"). On \"kyc_required\": why the previous identity-verification attempt failed (e.g. \"document_unverified_other\"), present only when a prior attempt was rejected."
    • changedOutput schema / properties / source / description
      Previous value: -"\"connected\" when the card was created against the user's added card (see add_card). Absent for wallet-funded cards."New value: +"\"connected\" when the card was created against the user's added card. Absent for wallet-funded cards."
    • changedOutput schema / properties / status / description
      Previous value: -"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 arguments in ~10s), \"payment_method_required\", \"kyc_required\", \"user_info_required\", \"beta_capacity_reached\", \"issuing_balance_insufficient\", \"payment_method_declined\", \"limit_reached\", \"funding_in_progress\" (company wallet funding underway — retry with the same arguments in ~10s), \"funding_not_approved\", \"org_wallet_funding_required\", \"org_wallet_unavailable\" (the company wallet backing this account is not active — the company must finish setup; do not retry immediately), or \"rate_limited\" (wait ~1 minute, then retry)."New value: +"Outcome discriminator: \"created\" (card issued), \"attach_started\" (first-time setup — send attachUrl to the user, then call again with the same arguments once they finish), \"attach_pending\" (user has not finished the add-card link yet), \"issuing_suggested\" (the user's card could not be added — offer the balance-funded fallback, noting it requires KYC, and only then call again with source \"issued\"), \"approval_required\" (human approval needed), \"approval_pending\" (added-card passkey approval — send approvalUrl to the user, then retry with the same arguments in ~10s), \"kyc_required\" (issued path only), \"user_info_required\" (check missingFields: phone/terms go through submit_user_info; consent must be recorded by the connecting platform), \"beta_capacity_reached\", \"issuing_balance_insufficient\" (issued path only), \"payment_method_declined\", \"limit_reached\", \"funding_in_progress\" (company wallet funding underway — retry with the same arguments in ~10s), \"funding_not_approved\", \"org_wallet_funding_required\", \"org_wallet_unavailable\" (the company wallet backing this account is not active — the company must finish setup; do not retry immediately), or \"rate_limited\" (wait ~1 minute, then retry)."
  2. Changed3 schema fields changed
    • changedInput schema / properties / connected_card_id / description
      Previous value: -"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."New value: +"Multi-card BYOC: issue against a SPECIFIC added card (an id from the user's added cards) instead of the newest active one. Omit for the default."
    • changedInput schema / properties / source / description
      Previous value: -"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)."New value: +"Force the card to be funded from the user's cash balance even when they have an added card. Omit for the default (an active added card wins)."
    • changedOutput schema / properties / source / description
      Previous value: -"\"connected\" when the card was minted against the user's attached card (see attach_card). Absent for wallet-funded cards."New value: +"\"connected\" when the card was created against the user's added card (see add_card). Absent for wallet-funded cards."
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only state that the call is mutating, non-idempotent, and not world-reading, but the description adds substantial behavioral context: cards are 'live and charged for real', the first call only returns an attach link, the second call actually mints, KYC is only needed on the issued path, and first-party personal plans have caps while company clients do not. This is exactly the kind of behavior an agent cannot infer from annotations or the schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but nearly every sentence carries a distinct rule or branch; in a tool this stateful, the density is justified. It loses a point because it is one dense paragraph — a bulleted or section-structured breakdown of first-time vs established vs issued flows would make the same high-value rules easier for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers the decision tree: first call, second call, fallback, established users, overrides, and limit/charge consequences. It also references the helpers an agent needs for related actions (get_settings, get_plan, add_funds, list_added_cards). Since an output schema exists, not enumerating the returned card details is acceptable, and nothing necessary for calling create_card correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds high-value selection logic beyond the schema: the two-step create flow, the rule that source 'issued' requires explicit user choice, restart_setup one-line on when it is or isn't needed, and the cents/dollars hazard in amount_cents. It tells the agent which parameter to use in each user scenario moved above and beyond any individual field description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('get the user a virtual debit card') and immediately frames it as the central card-issuing tool. It goes far beyond the name by explaining that it handles first-time card addition, issuance, and fallback logic, so an agent can tell it apart from card-lifecycle siblings like close_card, pause_card, list_cards, and get_card_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing rules: first-time users get the add-card flow, established users use the saved default, 'source: issued' forces the balance path, and restart_setup is only for lost links or adding another card. It also names sibling/helper tools with their exact purpose: get_settings default_payment, get_plan for limits, add_funds for topping up, and list_added_cards for connected_card_id.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All agentcard toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, especially in areas like card management and shopping. However, the KYC flow has multiple overlapping tools (start_kyc, get_kyc_status, check_kyc_document, submit_kyc_document, submit_kyc_fields) that could confuse an agent despite detailed descriptions.

Naming Consistency4/5

Tool names consistently use snake_case with a verb_noun pattern (e.g., add_funds, create_card, list_cards). A few exceptions like surprise_me and whoami break the pattern but are still intuitive overall.

Tool Count3/5

50 tools is on the high side for a single server, but the broad domain (cards, shopping, KYC, support, settings) partially justifies it. Some tools could be merged (e.g., KYC flow tools) without losing clarity.

Completeness4/5

The tool surface covers core workflows: CRUD for cards, transactions, KYC, support, shopping, and account management. Minor gaps exist (e.g., no update_card general, no cancel order in shopping), but overall the set is comprehensive for the stated purpose.

Resources