earnrate

Add a card

add_card

Adds a card the user holds to their wallet by its id from search_cards, creating the wallet if there isn't one. The reply says what the card still needs (category picks, memberships, activations); ask the user about those. Stores only the card's product id and settings, never card numbers.

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

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the implicit side effect of creating a wallet when none exists, describes post-call follow-up work the response reveals, and states a data-handling guarantee (only product id and settings stored, never card numbers). These are exactly the mutation and privacy traits an agent needs before writing.

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?

Three tight sentences, front-loaded with the core action and the wallet-creation side effect, followed by response handling and the data policy. No filler or restatement of the tool name.

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 seven-parameter mutation tool with an output schema, the description covers the missing pieces: id provenance, side effects, user-interaction expectations, and persistence scope. Return-value details can be omitted because an output schema exists.

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 bonus, picks, capSpent, activated, anniversary, and checkoutLabel are already documented in depth. The description only ties cardId back to search_cards and does not add meaning to the nested optionals, so baseline 3 applies.

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?

States a specific verb and resource (adds a card the user holds to their wallet) plus the required input's origin (id from search_cards). It is clearly distinguishable from siblings search_cards, update_card, and remove_card without opening any schema.

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?

Explains the prerequisite for invocation (obtain the id via search_cards) and instructs the agent to prompt the user about missing category picks, memberships, and activations. It does not explicitly contrast with update_card or remove_card, so the routing guidance is clear but not exhaustive.

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.