agentcard

save_preset

Save your own preset — a named set of rules (spend caps, category/merchant/place/currency/day/hour/program restrictions) you can reuse by name in set_card_preset or create_card. Saving under a name you already used adds a new version: cards already using the old one keep it, new ones get the update. Pick a name other than the built-ins (ai_labs, weekday_meals, cli_only, daily). Pass either the rule fields below or a raw privileges array.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	What the preset does when a purchase breaks any of its rules: "strict" refuses it (the default), "watch" lets it through and tells the user once.
`name`	Yes	A name for this preset, e.g. "meals-only".
`total`	No	Lifetime spend cap, in US dollars.
`only_in`	No	Comma-separated places to allow charges from: a country ("US", "Canada"), a region ("europe", "eu", "north-america", "latin-america", "apac"), or a US state ("California", "US-CA"). A region expands to its countries; a state next to a region narrows only the US, e.g. "north-america,US-CA". Example: "europe,Canada".
`per_day`	No	Spend cap per rolling 24 hours, in US dollars.
`per_week`	No	Spend cap per rolling 7 days, in US dollars.
`timezone`	No	IANA timezone for only_days/only_hours (default UTC), e.g. "America/Los_Angeles". Always shown in summaries.
`only_days`	No	Comma-separated days to allow, e.g. "mon,tue,wed" or "weekdays"/"weekends".
`only_from`	No	Comma-separated callers to allow, e.g. "cli,mcp" (cli, mcp, api, browser).
`per_month`	No	Spend cap per rolling 30 days, in US dollars.
`categories`	No	Comma-separated spend categories to allow, e.g. "meals,groceries" (meals, groceries, travel, software, ai, wellness, retail).
`currencies`	No	Comma-separated purchase currencies to allow: ISO 4217 codes or common names, e.g. "usd,eur" or "dollars,euros,pounds,yen". In strict mode a purchase in another currency is refused at checkout and a settled charge in another currency pauses the card. Checked by Agentcard at checkout and settlement, not by the card network. Unknown currencies are refused.
`only_hours`	No	An hour range to allow, e.g. "9-17" (24-hour clock; defaults to UTC without timezone).
`privileges`	No	Advanced: raw privilege objects instead of the rule fields above.
`only_merchants`	No	Comma-separated merchant name patterns to allow, e.g. "openai,anthropic".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`preset`	No
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 16, 2026

addedInput schema / properties / categories

Added value: +{
+  "description": "Comma-separated spend categories to allow, e.g. \"meals,groceries\" (meals, groceries, travel, software, ai, wellness, retail).",
+  "type": "string"
+}

addedInput schema / properties / currencies

Added value: +{
+  "description": "Comma-separated purchase currencies to allow: ISO 4217 codes or common names, e.g. \"usd,eur\" or \"dollars,euros,pounds,yen\". In strict mode a purchase in another currency is refused at checkout and a settled charge in another currency pauses the card. Checked by Agentcard at checkout and settlement, not by the card network. Unknown currencies are refused.",
+  "type": "string"
+}

addedInput schema / properties / mode

Added value: +{
+  "description": "What the preset does when a purchase breaks any of its rules: \"strict\" refuses it (the default), \"watch\" lets it through and tells the user once.",
+  "enum": [
+    "strict",
+    "watch"
+  ],
+  "type": "string"
+}

removedInput schema / properties / only_categories

Removed value: -{
-  "description": "Comma-separated spend categories to allow (strict), e.g. \"meals,groceries\" (meals, groceries, travel, software, ai, wellness, retail).",
-  "type": "string"
-}

removedInput schema / properties / only_currencies

Removed value: -{
-  "description": "Comma-separated purchase currencies to allow (strict): ISO 4217 codes or common names, e.g. \"usd,eur\" or \"dollars,euros,pounds,yen\". A purchase in another currency is refused at checkout; a settled charge in another currency pauses the card. Checked by Agentcard at checkout and settlement, not by the card network. Unknown currencies are refused.",
-  "type": "string"
-}

removedInput schema / properties / watch_categories

Removed value: -{
-  "description": "Categories in Watch mode (allow + notify on mismatch instead of refuse/pause): meals, groceries, travel, software, ai, wellness, retail. Spend caps, places, time windows, and merchant-only rules stay strict.",
-  "type": "string"
-}

removedInput schema / properties / watch_currencies

Removed value: -{
-  "description": "Purchase currencies in Watch mode (allow + notify on mismatch instead of refuse/pause), e.g. \"usd,eur\". Checked by Agentcard, not by the card network. Use only_currencies or watch_currencies, not both.",
-  "type": "string"
-}

Changed2 schema fields changedSep 9, 2026

addedInput schema / properties / only_currencies

Added value: +{
+  "description": "Comma-separated purchase currencies to allow (strict): ISO 4217 codes or common names, e.g. \"usd,eur\" or \"dollars,euros,pounds,yen\". A purchase in another currency is refused at checkout; a settled charge in another currency pauses the card. Checked by Agentcard at checkout and settlement, not by the card network. Unknown currencies are refused.",
+  "type": "string"
+}

addedInput schema / properties / watch_currencies

Added value: +{
+  "description": "Purchase currencies in Watch mode (allow + notify on mismatch instead of refuse/pause), e.g. \"usd,eur\". Checked by Agentcard, not by the card network. Use only_currencies or watch_currencies, not both.",
+  "type": "string"
+}

AddedSep 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full transparency burden. It discloses a non-obvious versioning behavior: re-saving a name adds a new version, existing cards keep the old one, and new cards get the update. It also warns against built-in names and clarifies that either rule fields or a privileges array can be passed, going beyond what the schema states.

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 three short sentences with no redundant wording. It front-loads the primary purpose, then covers versioning semantics, naming constraints, and input options in a clear, efficient order.

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?

For a 15-parameter creation tool with an output schema, the description covers all essential invocation decisions: what to pass, which names to avoid, how re-saving behaves, and the alternative input path. Return-value details are delegated to the output schema, so nothing critical for a correct call is missing.

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

Parameters4/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 already met. The description adds the crucial either/or relationship between the rule fields and the raw privileges array, which is not obvious from the schema alone. It also provides a high-level grouping of the rule fields (spend caps, restrictions) and a name constraint for the required parameter, adding meaningful semantic guidance.

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 'Save your own preset' and immediately explains that it creates a named, reusable set of rules for use in set_card_preset or create_card. It clearly distinguishes this tool from sibling tools by framing it as an authoring action rather than an assignment action, and explicitly contrasts with built-in presets.

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 explicitly states that the saved preset is reused by name in set_card_preset or create_card, signaling when this creation step is needed. It also gives a concrete constraint ('Pick a name other than the built-ins') and clarifies the two input modes. It doesn't contrast with list_presets or delete_preset, but that omission is minor for invoking this tool correctly.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?