earnrate

Update a card

update_card

DestructiveIdempotent

Changes settings on a card already in the wallet: its category picks for this period, checkout label, anniversary or activated categories. Picks for the current period are merged with the ones already saved. Use it when the user picks new categories, such as each quarter on U.S. Bank Cash+.

Input Schema

Name	Required	Description
`bonus`	No	A welcome bonus the user is working toward, so purchases recorded on this card count toward it and answers can favor it. Ask when they opened the account; spending needed and the deadline default to the card's published offer. null stops tracking it.
`picks`	No	For cards where the cardholder picks bonus categories: choice id → option ids, from search_cards, e.g. {"five-percent": ["tv-internet-streaming", "fast-food"]}. Saved for the current period. Ask the user; don't guess.
`cardId`	Yes	The card id from search_cards, e.g. chase-sapphire-preferred.
`capSpent`	No	Dollars already spent this period on a capped bonus, for a card the user starts tracking partway through: cap key (as list_wallet shows it) → dollars, e.g. {"five-percent-quarterly": 400}. Ask; recorded purchases add to it from then on.
`activated`	No	Rule ids the user has activated with the issuer, such as rotating categories. Replaces the current list.
`anniversary`	No	The account's anniversary as MM-DD, for cards whose cap resets on it.
`checkoutLabel`	No	How the card appears at checkout or in a browser wallet, e.g. "Amex Gold". Optional; null goes back to the card's own name.

Output Schema

Name	Required	Description	Default
`notes`	Yes
`cardIds`	Yes
`created`	Yes
`message`	Yes
`memberships`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 1, 2026

addedInput schema / properties / capSpent

Added value: +{
+  "additionalProperties": {
+    "minimum": 0,
+    "type": "number"
+  },
+  "description": "Dollars already spent this period on a capped bonus, for a card the user starts tracking partway through: cap key (as list_wallet shows it) → dollars, e.g. {\"five-percent-quarterly\": 400}. Ask; recorded purchases add to it from then on.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedInput schema / properties / checkoutLabel / anyOf

Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / checkoutLabel / description

Previous value: -"How the card appears at checkout or in a browser wallet, e.g. \"Amex Gold\". Optional."New value: +"How the card appears at checkout or in a browser wallet, e.g. \"Amex Gold\". Optional; null goes back to the card's own name."

removedInput schema / properties / checkoutLabel / minLength
```
Removed value: -1
```
removedInput schema / properties / checkoutLabel / type
```
Removed value: -"string"
```

First observedOct 31, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The description adds useful behavior beyond the annotations by explaining that current-period picks are merged with saved picks rather than replacing them. However, with destructiveHint=true, it does not disclose which fields are overwritten or reset, such as activated categories replacing the current list or bonus tracking being stopped with null.

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 two compact sentences. It front-loads the purpose and field scope, then adds the merge behavior and a concrete use case without wasted text.

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?

The description covers the main category-pick use case and one important merge behavior, and the rich schema plus output schema reduce the burden on the description. However, it omits the bonus and capSpent update capabilities entirely and does not flag the destructive overwrite behavior that agents should be aware of for a mutation 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 schema already carries the parameter semantics. The description adds a meaningful merge rule for picks, but it does not cover the bonus or capSpent parameters and mostly repeats the field names already documented in the schema.

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

Purpose4/5

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

The description states a specific verb and resource: it changes settings on a card already in the wallet. It enumerates several updatable fields and implicitly distinguishes the tool from add_card/remove_card by specifying an existing wallet card, though it does not explicitly name alternatives.

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?

It gives a clear when-to-use condition: when the user picks new categories, such as quarterly category selection. It does not state when not to use it or name sibling alternatives for related operations.

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

All earnrate 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.