agentcard

update_card_limit

Idempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`card_id`	Yes	The multi-use card ID to resize.
`approval_id`	No	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 with it.
`new_limit_cents`	No	Deprecated alias for spend_limit_cents. Prefer spend_limit_cents (matches the docs and the REST API).
`spend_limit_cents`	No	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.

Output Schema

TableJSON Schema

Name	Required	Description
`cardId`	No	The card ID.
`status`	No	"updated" on success; an error discriminator otherwise (e.g. "limit_below_spent", "insufficient_collateral").
`message`	Yes	Human-readable result.
`balanceCents`	No	The remaining spendable balance in cents.
`spendLimitCents`	No	The new total limit in cents.

Schema Changelog

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

First observedJul 28, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already set readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds key behaviors: raising reserves extra balance, lowering frees difference, limit floor of current spent, and the need for approval_id with cross-app cards. No contradictions with annotations.

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 one concise paragraph starting with the main action, then effects, then restrictions. Every sentence adds value without waste. Minor improvement could be shorter phrasing but overall well-structured.

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

Completeness4/5

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

Given the tool has 4 parameters, 1 required, and an output schema, the description covers the core behavior, special case of approval_id, and single-use restriction. It omits edge cases like what happens if limit unchanged but balance affected, but output schema likely covers return. Adequate for an update tool.

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 baseline is 3. The description provides a high-level overview but does not add meaningful detail beyond what the schema already describes for each parameter (e.g., card_id, approval_id, etc.).

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 uses the verb 'Change' with the specific resource 'multi-use card's total spending limit', clearly distinguishing it from siblings like close_card or pause_card. It also explicitly states that single-use cards cannot be resized, further differentiating tool scope.

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 to use the tool (to adjust spending limit), provides context for raising (needs balance, use add_funds if short) and lowering (frees balance, cannot go below spent), and warns against use with single-use cards. However, it does not explicitly compare to other card modification tools.

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

All agentcard tools Inspect

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

Need Help?