Skip to main content
Glama

card_create

Create a new card; handles SCA by polling inline (default 30s) and falls back to a structured pending response for caller to complete authentication via session token.

Instructions

Create a new card. SCA: this operation may require Strong Customer Authentication; the tool polls inline by default (wait=30s) and falls back to a structured pending response so the caller can continue via sca_session_show + sca_session_token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoMaximum seconds (0-120) to poll inline for SCA approval before returning a structured pending response. Use false or 0 for a pure two-step flow (return immediately on SCA required). Default 30.
holder_idYesCardholder membership ID
atm_optionNoEnable ATM withdrawals
card_levelYesCard level
categoriesNoAllowed merchant categories
nfc_optionNoEnable contactless payments
active_daysNoActive weekdays (1=Mon, 7=Sun)
card_designNoCard design identifier
initiator_idYesOrder initiator membership ID
online_optionNoEnable online payments
type_of_printNoPrint type (Plus cards only)
foreign_optionNoEnable international payments
pre_expires_atNoFlash card validity end (ISO 8601)
atm_daily_limitNoDaily ATM withdrawal limit (EUR)
bank_account_idYesBank account ID
organization_idYesOrganization ID
ship_to_businessNoShip card to organization address
atm_monthly_limitNoMonthly ATM withdrawal limit (EUR)
sca_session_tokenNoSCA session token from a prior call to bind a previously approved SCA challenge to this retry. When set, no polling occurs and the operation runs exactly once with the token attached.
payment_daily_limitNoDaily payment limit (EUR)
payment_monthly_limitNoMonthly payment limit (EUR)
atm_daily_limit_optionNoEnable daily ATM limit
payment_lifespan_limitNoTotal spending cap (flash cards, EUR)
payment_transaction_limitNoPer-transaction limit (EUR)
payment_daily_limit_optionNoEnable daily payment limit
payment_transaction_limit_optionNoEnable per-transaction limit
Behavior4/5

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

Without annotations, the description carries full burden. It discloses SCA requirements, polling behavior (default wait=30s), and fallback to a pending response with guidance on how to continue using sca_session_show and sca_session_token. This provides good insight into the tool's behavior beyond the basic definition.

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

Conciseness5/5

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

The description is extremely concise: two sentences that immediately state the purpose and then add key behavioral detail. No unnecessary words; every sentence adds value.

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

Completeness3/5

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

Given the complexity (26 parameters, no output schema, no annotations), the description is incomplete. It lacks information about the return value, prerequisites, or typical workflow beyond SCA handling. The polling detail is good, but more context is needed for a tool that creates a financial instrument.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 26 parameters. The description adds no parameter-specific information beyond what's in the schema. Baseline score of 3 is appropriate.

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 clearly states the tool creates a new card, using specific verb-resource pair. It adds detail about SCA and polling, which distinguishes it from related tools like card_bulk_create that handle bulk operations.

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

Usage Guidelines4/5

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

The description explains when SCA may be required and how to handle it via polling or two-step flow. It does not explicitly contrast with sibling tools like card_bulk_create, but the context for the tool's single-card creation is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexey-pelykh/qontoctl'

If you have feedback or need assistance with the MCP directory API, please join our Discord server