Verified US rate, savings-gap, card, CD, and product-change tools with freshness and sources.
Scored across 16 tools
Most tools have clearly distinct purposes, targeting specific data like card offers, downgrade paths, or transfer bonuses. Minor overlap exists between get_top_rates and get_top_hysa_rates, but the latter is explicitly scoped to high-yield savings accounts, and best_move_this_week is a composite recommendation tool rather than a simple lookup.
The majority of tools follow a 'get_' prefix convention, but two tools (best_move_this_week and compare_switch_savings) deviate by using other verbs. This mixed pattern could cause some confusion about whether a tool returns data or performs an action, though the names remain readable and snake_case is consistent.
With 16 tools, the server sits at the upper boundary of the typical well-scoped range, but the count is justified by the breadth of financial domains covered—credit cards, savings, CDs, indices, and transfer bonuses. Each tool addresses a specific need, so the size feels intentional rather than excessive.
The server provides comprehensive coverage of personal finance data: card offers, fee changes, downgrade paths, reward valuations, savings rates, CD rollover rules, and transfer bonuses. Notable gaps include user profile management and direct spending categorization, but these may be outside the server's intended scope, and the core data retrieval and recommendation workflows are well covered.
Given the credit cards a user holds, rank this week's dollar-valued actions: which held card to use per spend category, welcome offers at a 12-month high on cards not held, active transfer bonuses, and (optionally) the savings-rate move beside the card move.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Card ids the user holds, in the form issuer:slug, e.g. ["chase:sapphire-preferred", "amex:gold-card"]. | |
| categories | No | Optional spend categories to rank held cards for; defaults to all nine. | |
| usedBenefits | No | Optional log of period credits already used this month; excluded from picks and counted toward renewal value. Omit to treat every credit as unused. | |
| savingsBalance | No | Optional cash balance, to include the savings-rate move beside the card moves. | |
| currentSavingsApy | No | Optional current savings APY, used with savingsBalance. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| error | No | |
| cardMoves | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| savingsMove | No | |
| verified_at | No | |
| unheldOffers | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No | |
| transferBonuses | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it ranks actions, treats welcome offers as 'at a 12-month high on cards not held,' and clarifies that the savings move is optional. It does not detail output shape, but an output schema exists, so that burden is reduced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the core action ('rank this week's dollar-valued actions') and then lists the covered categories in order of importance. No filler, no repetition of schema details, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex aggregator with 5 parameters and an output schema, the description covers the main decision dimensions: which card to use per category, welcome offers, transfer bonuses, and optional savings. It does not explicitly mention that usedBenefits is for renewal-value tracking, but the schema covers that. The only notable omission is not stating that the tool is read-only and safe to call repeatedly, though annotations already convey that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 five parameters thoroughly. The description adds the semantic link that savingsBalance and currentSavingsApy together enable the optional savings-rate move, and that usedBenefits affects renewal value. This is useful but modest; the schema carries most of the weight, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('rank'), a specific resource ('this week's dollar-valued actions'), and enumerates the exact action types covered (held-card category picks, welcome offers, transfer bonuses, savings-rate move). It clearly distinguishes itself from siblings like get_card_offers or get_transfer_bonuses, which are narrower data-retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the weekly decision aggregator: it combines card usage, welcome offers, transfer bonuses, and optionally savings. It does not explicitly state when NOT to use it or name alternatives, but the sibling list and the description's scope make the use case clear. A small gap: no explicit exclusion like 'for a single card's offers, use get_card_offers instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a user's current APY with SwitchWize's current top savings APY for a balance.
| Name | Required | Description | Default |
|---|---|---|---|
| balance | No | ||
| currentApy | Yes |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| error | No | |
| balance | No | |
| annualGap | No | |
| currentApy | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| comparisonApy | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| currentInterest | No | |
| freshnessStatus | No | |
| breakEvenFraming | No | |
| comparisonInterest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it performs a comparison, which is a mild behavioral trait, but it does not disclose the nature of the output (e.g., difference, recommendation) or any computational side effects. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the core action ('Compare') and includes the key objects and scope. Every word earns its place; it is an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, read-only), and an output schema exists, so return-value documentation is not required. However, the description omits any usage context or differentiation from siblings, and it does not explain what 'current top savings APY' means (e.g., is it the highest across all banks or within a specific category?). For a low-complexity tool this is barely adequate, but it leaves some ambiguity that could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The description references 'user's current APY' (currentApy) and 'a balance' (balance), providing basic identification, but it does not clarify units (e.g., APY as percentage, balance as dollars), constraints beyond schema ranges, or how these parameters influence the comparison. Given the low coverage, this is a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compare') and names both the resource ('user's current APY') and the reference ('SwitchWize's current top savings APY'), with the balance parameter mentioned as the scope. It clearly distinguishes from siblings like get_top_rates (which likely just returns top rates) and get_bank_gap (which might compute a gap). No ambiguity remains about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the 14 siblings. It does not mention alternatives, prerequisites, or conditions that would select this tool over, for example, get_top_hysa_rates or best_move_this_week. The context implies it is for comparing a user's rate to the top rate, but no explicit routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the annual savings gap for a balance using the current Bank Gap Index assumptions.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | No | Optional bank name for user-facing context. | |
| balance | No |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| bank | No | |
| tool | Yes | |
| error | No | |
| balance | No | |
| bankApy | No | |
| annualGap | No | |
| bankCount | No | |
| attribution | No | |
| baselineApy | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| comparisonApy | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish the tool as read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds useful context by saying the estimate uses current assumptions, signaling open-world dependence and that results may change as the underlying index assumptions change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence front-loads the verb and object, and every phrase contributes to the core meaning. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, an output schema, and simple parameters, the description plus schema gives an agent enough to call the tool safely. It is slightly less complete on parameter semantics, but the optional bank and balance constraints are in the schema, so no critical details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'balance' but only echoes the parameter name; it does not explain units, currency, or the numeric constraints (0–10,000,000). The 'bank' parameter is left entirely to the schema description, and with 50% schema coverage, the description does not fully compensate for the missing balance parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and identifies the resource ('annual savings gap for a balance'), clearly conveying what the tool computes. It also references 'current Bank Gap Index assumptions,' differentiating this from sibling get_bank_gap_index, though it does not name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like get_bank_gap_index or compare_switch_savings. The text only states what the tool does, leaving selection conditions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current SwitchWize Bank Gap Index headline value, latest release, and methodology URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| error | No | |
| label | No | |
| month | No | |
| index_id | No | |
| gapPoints | No | |
| topAvgApy | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| banksTracked | No | |
| headlineValue | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| nationalAvgApy | No | |
| freshnessStatus | No | |
| releaseArchiveUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds context by specifying the exact return contents (value, release, URL), which goes beyond the annotations. No behavioral caveats or side effects are disclosed, but none are expected for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence that immediately states the action and the exact outputs. No filler or redundancy; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with a pre-existing output schema, the description is sufficient. It names all three returned components, and the output schema handles structure. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. The description explicitly states it returns the current value, reinforcing that no input is required. Baseline for 0 params is 4, but the description adds clarity that there is nothing to configure, so a 5 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Return) and resource (SwitchWize Bank Gap Index) with clear scope (headline value, latest release, methodology URL). Distinct from siblings like get_bank_gap, which likely provides more detailed data, and get_index_dataset, which may return a full dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. It does not mention exclusions or when to prefer it over get_bank_gap, get_index_dataset, or get_rate_freshness. Usage is only implied by the tool name and description, but no explicit routing advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent verified credit-card fee and APR changes, most recent first. Each event is a diff between two confirmed snapshots of the same card.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sinceDays | No | Only changes observed within this many days. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| count | No | |
| error | No | |
| changes | No | |
| sinceDays | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds that events are diffs between confirmed snapshots and are verified, plus most-recent-first ordering. This is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The primary action and ordering are first, and the snapshot-diff detail follows.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an optional-parameter read-only list tool with an output schema, the description covers the data semantics (verified diffs) and ordering. It doesn't discuss pagination or definitions of 'fee and APR', but annotations and output schema fill most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers sinceDays with a description, but limit has no schema description. The tool description does not explain limit's semantics either, relying on 'most recent first' to imply a count cap. With 50% schema description coverage, this leaves parameter meaning mostly to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Return', resource 'verified credit-card fee and APR changes', and ordering 'most recent first'. Clearly distinct from sibling tools like get_card_offers or get_card_downgrade_path, which cover other card topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call when you need recent verified fee/APR changes. However, it does not name alternatives or state when not to use it. No explicit routing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return verified credit-card product-change (downgrade) paths and the issuer's fee-refund window: which no-fee or lower-fee card a given card can be product-changed to, and how long after the annual fee posts a refund is available on cancellation. Optionally filtered to one card id (issuer:slug); returns every verified path and window when omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | No | Optional card id (issuer:slug), e.g. chase:sapphire-reserve or capital-one:venture-x-rewards. Omit to return every verified downgrade path and fee-refund window. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| count | No | |
| error | No | |
| cardId | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| schemaVersion | Yes | |
| downgradePaths | No | |
| methodologyUrl | No | |
| feeRefundWindow | No | |
| freshnessStatus | No | |
| feeRefundWindows | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral nuance: results are 'verified', the optional filter changes the result scope, and omitting it 'returns every verified path and window.' This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the tool's output, and the second sentence states filtering behavior and the default fallback. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, rich read-only/idempotent annotations, and an existing output schema, the description covers everything an agent needs: what results are returned, how to filter, and what happens when no filter is provided. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the cardId parameter is already documented with the issuer:slug format, examples, and omit behavior. The description mostly restates this information, adding no significant meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Return verified credit-card product-change (downgrade) paths and the issuer's fee-refund window.' It also clarifies the precise subject ('which no-fee or lower-fee card a given card can be product-changed to'), which distinguishes it from sibling card-related tools without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: retrieve verified downgrade paths and fee-refund windows, optionally filtered by one card id. It does not explicitly name sibling alternatives or state when not to use this tool, but the intended query scenario is unambiguous and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current credit-card welcome-bonus offers (non-targeted, confidence-gated), each with a verified timestamp, source URL, and the card's own 12-month best.
| Name | Required | Description | Default |
|---|---|---|---|
| card | No | Optional card id (issuer:slug), slug, or name to filter to one card, e.g. chase:sapphire-preferred or Sapphire Preferred. | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| count | No | |
| error | No | |
| offers | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| totalTracked | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable context beyond annotations by specifying the output content (verified timestamp, source URL, card's own 12-month best) and the confidence-gating filter. This enriches the agent's understanding of what to expect without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core purpose and packs essential qualifiers without wasted words. Every phrase adds meaning, and it is appropriately brief for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return format is covered. Annotations handle safety. The description adds the key qualifiers (non-targeted, confidence-gated) and output fields (timestamp, URL, 12-month best). It lacks details on how the limit parameter works, but that is minor given the schema. Overall, an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'card' has a description; 'limit' only has min/max). The tool description does not compensate for the undocumented 'limit' parameter or add any semantics beyond what the schema provides. Since the description mentions nothing about parameters, it fails to help the agent understand how limit affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Return), a precise resource (current credit-card welcome-bonus offers), and important qualifiers (non-targeted, confidence-gated) that distinguish it from sibling tools like get_card_changes or get_transfer_bonuses. The mention of 'current' and '12-month best' further narrows scope, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (current, non-targeted welcome-bonus offers) but does not explicitly mention alternatives or when not to use this tool. It implies usage for welcome-bonus offers but gives no exclusions or routing to siblings like get_card_changes or get_transfer_bonuses, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return verified CD rollover rules for one bank, or every bank SwitchWize has verified: what happens automatically at maturity if the customer does nothing, the grace period, how to stop the rollover, and the early-withdrawal penalty. Each fact is sourced directly from the bank's own disclosure; an unverified field is omitted, never guessed.
| Name | Required | Description | Default |
|---|---|---|---|
| institutionId | No | Optional institution_registry id, e.g. chase, american-express, wells-fargo. Omit to return every bank SwitchWize has verified. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| count | No | |
| error | No | |
| sourceUrl | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| institutions | No | |
| institutionId | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No | |
| gracePeriodDays | No | |
| autoRenewDefault | No | |
| autoRenewDescription | No | |
| earlyWithdrawalPenalty | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful context beyond these: facts are sourced from the bank's own disclosure, and unverified fields are omitted rather than guessed. This clarifies the open-world nature of the tool without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and scope, then compresses the return-field enumeration and sourcing guarantee into the remaining text. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, a fully documented input schema, an output schema, and clear safety annotations, nothing needed to invoke the tool correctly is missing. The description also covers the epistemic contract (verified, sourced, never guessed), which is especially valuable for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents institutionId along with the omit-to-return-all behavior. The description largely restates this parameter guidance rather than adding new semantic detail, so the high-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Return verified CD rollover rules') and precisely defines scope: one bank or every bank SwitchWize has verified. It also enumerates the specific fields returned, making the purpose unambiguous and clearly distinct from all 14 sibling tools, none of which target CD rollover rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the main invocation branch (provide an institutionId or omit it to get all banks) but does not explicitly say when to choose this tool over alternatives or name a sibling it is not. Usage is implied by the tool's unique domain, but no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return how much of the latest Federal Reserve rate hike each tracked savings account has passed through to savers so far: rate before the hike, rate now, change in basis points, pass-through share, and days until the bank moved. One source per bank; each row carries its source type and observation dates. Optionally filtered to one institution id.
| Name | Required | Description | Default |
|---|---|---|---|
| institutionId | No | Optional institution_registry id, e.g. tab, ally, marcus. Omit to return every savings account measured against the latest Fed hike. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| move | No | |
| tool | Yes | |
| count | No | |
| error | No | |
| summary | No | |
| excluded | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| institution | No | |
| verified_at | No | |
| institutions | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No | |
| daysSinceAnnouncement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond annotations: results are 'so far' (time-bound), tied to the 'latest' hike, one source per bank, and each row carries source type and observation dates. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the primary result and list the returned fields without filler. Every sentence contributes either scope, measurement semantics, or row-level details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter, an output schema is present, and annotations cover safety and side-effect profile. The description adds the needed row semantics and source-uniqueness detail, so nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents the single optional parameter, including the id format and default behavior when omitted. The top-level description only restates the optional institution filter, adding no new parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a precise resource: pass-through of the latest Federal Reserve rate hike for tracked savings accounts. It enumerates the computed fields and distinguishes this from sibling tools like get_bank_gap or get_top_hysa_rates by focusing on pass-through behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: use this tool when you need latest-Fed-hike pass-through data for savings accounts, optionally restricted to one institution. It does not explicitly name alternatives or when-not-to-use cases, but the purpose is specific enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a SwitchWize index dataset summary and recent series.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| indexId | Yes | Index id, e.g. bank-gap-index, cd-spread, mma-spread, checking-gap. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| error | No | |
| label | No | |
| series | No | |
| index_id | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds minimal behavioral context beyond that—just 'summary and recent series' which hints at the return shape but not details like pagination or freshness. Given the annotations, a 3 is fair; it adds a little but not much.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, front-loaded with the verb and resource. It is not bloated, though it could be slightly more detailed without losing conciseness. It earns its place, but a bit more behavioral or usage guidance would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return value explanation is not needed. However, given the tool's complexity (2 params, one with a limit), and the existence of many sibling index/rate tools, the description is slightly sparse. It doesn't explain what 'recent series' means or how it relates to other index tools, so an agent might underuse it. It is complete enough for basic calls but not for nuanced selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: indexId is described with examples, but limit is not described in the schema. The description doesn't add meaning to limit at all, so it relies on the schema's type/constraints. For indexId, the schema already gives a description, so the tool description doesn't add extra value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('SwitchWize index dataset summary and recent series'), which is specific enough. However, it does not differentiate from siblings like get_bank_gap_index, which could be confused with an index dataset. The name includes 'index' but the description doesn't clarify that this returns a summary of many indices or a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any context on when to use this tool versus alternatives. It implies a read-only retrieval, but with siblings like get_bank_gap_index and get_rate_freshness, an agent would need more guidance on when to pick this one. No exclusions or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return public data source freshness status and affected routes.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| error | No | |
| sources | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| schemaVersion | Yes | |
| affectedRoutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the output content (freshness status and affected routes), which is useful but does not disclose other behavioral traits such as response format, potential time-sensitivity, or any dependency on external data. With annotations handling the main safety aspects, the description's additional value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-woven sentence that front-loads the primary action and result. It contains no filler or redundant phrasing, making it highly concise while still conveying the core purpose. The structure is appropriate for a tool with minimal complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although output schema exists (reducing the need to explain return values), the description leaves out essential context: it does not explain what 'category' refers to, what 'affected routes' means, or when an agent should invoke this tool relative to siblings. The tool's role in the broader workflow is unclear, making the definition incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'category' parameter with zero description coverage, and the description does not mention it at all. The agent has no idea what 'category' means, what values are acceptable, or how it affects the result. This is a critical omission because the tool's behavior is likely dependent on this parameter, and the description fails to compensate for the schema's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Return') and a precise resource ('public data source freshness status and affected routes'), which is distinct from all sibling tools that focus on rates, cards, or savings. The title 'Data Freshness' reinforces the purpose, making it easy for an agent to understand what this tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many siblings. It does not mention that it might be a prerequisite for checking data freshness before using other rate or card tools, nor does it state any exclusion criteria. An agent is left to infer the use case, which is a significant gap given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a premium credit-card Reality Score for a card and consumer segment.
| Name | Required | Description | Default |
|---|---|---|---|
| card | Yes | Card slug or name, e.g. platinum-card or Chase Sapphire Reserve. | |
| segment | No | Optional segment id, e.g. occasional-traveler, small-business-owner, balance-carrier. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| error | No | |
| result | No | |
| segment | No | |
| index_id | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the agent knows the tool is safe and side-effect free. The description adds no behavioral context beyond that—no mention of limitations, data sources, or any special considerations. Since the description carries a lower burden due to annotations, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes the key input dimensions. There is no fluff, redundancy, or unnecessary detail. It earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the return format is already defined, so the description does not need to explain it. The tool is simple (2 parameters, 1 required) and the annotations cover the safety profile. The description provides the essential purpose and inputs, which is sufficient for an agent to understand what the tool does. It lacks richer context about the nature of the score, but the output schema likely fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (card and segment) with examples, so schema coverage is 100%. The description only restates the parameter names in prose ('card and consumer segment') without adding new semantic detail, such as expected formats, value ranges, or relationships between parameters. This meets the baseline for high coverage but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return') and resource ('premium credit-card Reality Score') with the input scope ('for a card and consumer segment'). It is not a tautology and effectively conveys what the tool does. However, it does not differentiate it from siblings like get_reward_valuations or get_card_offers, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling tools. The description simply states what it does without mentioning alternatives or conditions that would lead an agent to pick this over others. An agent is left to infer from the name and output schema, which is insufficient for a set of closely related financial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return SwitchWize points/miles valuations (cents per point) per reward currency, with sample size and provisional/published status.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Optional reward currency id or name, e.g. chase-ultimate-rewards or Membership Rewards. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| count | No | |
| error | No | |
| datasetUrl | No | |
| valuations | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description does not need to restate that. It adds useful context beyond the annotations by mentioning that results include sample size and provisional/published status, which helps an agent assess data reliability. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler. The action and resource are front-loaded, followed by useful qualifiers like units and status fields, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one optional parameter, rich annotations, and an output schema, the description is complete. An agent knows what the tool returns, how to filter it, and what reliability signals to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single optional 'currency' parameter at 100% coverage, so the description does not need to repeat format details. The description adds only mild domain framing—'per reward currency'—without enriching parameter behavior beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names the exact resource ('SwitchWize points/miles valuations') with units ('cents per point') and key fields ('sample size and provisional/published status'). This clearly distinguishes it from sibling tools focused on bank rates, card offers, or index data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when reward-currency valuation data is needed—but provides no explicit when-to-use versus alternative guidance. None of the sibling tools are close enough to cause confusion, so this is a minor gap rather than a misleading one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return top high-yield savings rates with freshness and attribution metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| id | No | |
| asOf | No | |
| count | Yes | |
| rates | Yes | |
| terms | No | |
| source | No | |
| category | Yes | |
| rate_type | No | |
| attribution | No | |
| emptyReason | No | |
| generatedAt | Yes | |
| schemaVersion | Yes | |
| sourceDetails | No | |
| methodologyUrl | No | |
| freshnessStatus | Yes | |
| attributionDetails | No | |
| supportedCategories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to restate those. It adds useful context that results include freshness and attribution metadata. However, it does not disclose default behavior when the optional limit parameter is omitted, which is a minor transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning: returning data, specifying the domain, and noting metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, an output schema, and strong safety annotations, the description covers the core purpose and result characteristics. The only notable omission is the default behavior of the limit parameter, but this is a minor gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for parameter semantics, but it does not mention the limit parameter at all. The schema provides type and min/max constraints, but no meaning or default behavior. Since the limit is optional, the agent is left to infer it controls result count without guidance on default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and a specific resource ('top high-yield savings rates'), and it adds the metadata qualifier 'freshness and attribution'. This distinguishes it from the generic sibling get_top_rates, though it does not explicitly name or contrast that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the tool name and description: an agent should call this when the request involves top high-yield savings rates. However, there is no explicit guidance about when to use this tool versus alternatives like get_top_rates or get_rate_freshness, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return top SwitchWize rates for a supported category with freshness and attribution metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | Yes | Rate category, e.g. savings, cds, money-market, checking, mortgage. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| asOf | No | |
| count | Yes | |
| rates | Yes | |
| terms | No | |
| source | No | |
| category | Yes | |
| rate_type | No | |
| attribution | No | |
| emptyReason | No | |
| generatedAt | Yes | |
| schemaVersion | Yes | |
| sourceDetails | No | |
| methodologyUrl | No | |
| freshnessStatus | Yes | |
| attributionDetails | No | |
| supportedCategories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description carries a lower burden. It adds that the results include freshness and attribution metadata, which is useful, but it does not mention pagination, default limit behavior, or what happens for unsupported categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource, followed by the scope and metadata. There is no filler or redundant phrasing; every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with an output schema and comprehensive safety annotations, the description gives a solid picture. Minor additions such as noting category validation or limit defaults would improve completeness, but nothing essential is missing for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the category parameter has a schema description; the limit parameter has none, and the tool description never mentions limit semantics. The phrase 'supported category' adds little beyond the schema's examples, so the undocumented limit parameter remains a real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Return') and a specific resource ('top SwitchWize rates'), scoped to 'a supported category' and including freshness/attribution metadata. It is clearly a ranking/rates tool, but it does not explicitly differentiate itself from the sibling get_top_hysa_rates, so an agent may still wonder whether to use this or the more specific sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_top_hysa_rates or get_rate_freshness. The description only says what the tool returns, with no exclusions, prerequisites, or routing hints, despite a sibling list with several overlapping tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current point-transfer bonuses across tracked bank-to-partner routes, each with a verified timestamp, source URL, and best-ever-for-route when real history exists.
| Name | Required | Description | Default |
|---|---|---|---|
| program | No | Optional program id or name to filter routes by source or destination, e.g. chase-ultimate-rewards or Flying Blue. |
| Name | Required | Description |
|---|---|---|
| asOf | No | ISO timestamp of the underlying data this response reflects. |
| tool | Yes | |
| count | No | |
| error | No | |
| routes | No | |
| datasetUrl | No | |
| attribution | No | |
| generatedAt | Yes | ISO timestamp this response was computed at. |
| verified_at | No | |
| schemaVersion | Yes | |
| methodologyUrl | No | |
| freshnessStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by disclosing that results include a verified timestamp, source URL, and best-ever-for-route only when real history exists, giving agents insight into data provenance and conditional completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It opens with the action and resource, then adds relevant data-quality detail without digression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one optional parameter, full schema coverage, and an output schema. The description supplies the non-structured context an agent needs, such as verified timestamps, source URLs, and best-ever conditional logic, making it complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the single optional program parameter is fully documented in the schema with example values (“chase-ultimate-rewards or Flying Blue”). The description does not add extra parameter-level meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (“Return”), a precise resource (“current point-transfer bonuses across tracked bank-to-partner routes”), and the key data fields returned. This clearly distinguishes it from all 14 siblings, none of which target transfer bonuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description immediately conveys when to use the tool: whenever current point-transfer bonuses for bank-to-partner routes are needed, with optional filtering by program. It does not explicitly name alternatives or exclusions, but the domain is distinct enough among siblings that usage intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_fed_hike_pass_throughbest_move_this_week1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}compare_switch_savings1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_bank_gap1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_bank_gap_index1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_card_changes1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_card_downgrade_path1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_card_offers1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_cd_rollover_rules1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_index_dataset1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_rate_freshness1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_reality_score1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_reward_valuations1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}get_transfer_bonuses1 field changedOutput schema / properties / error / properties / retryableAdded value: +{
+ "type": "boolean"
+}best_move_this_week2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "cardMoves": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "savingsMove": {
+ "additionalProperties": true,
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "transferBonuses": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unheldOffers": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]compare_switch_savings2 fields changedOutput schema / propertiesAdded value: +{
+ "annualGap": {
+ "type": "number"
+ },
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "balance": {
+ "type": "number"
+ },
+ "breakEvenFraming": {
+ "type": "string"
+ },
+ "comparisonApy": {
+ "type": "number"
+ },
+ "comparisonInterest": {
+ "type": "number"
+ },
+ "currentApy": {
+ "type": "number"
+ },
+ "currentInterest": {
+ "type": "number"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_bank_gap2 fields changedOutput schema / propertiesAdded value: +{
+ "annualGap": {
+ "type": "number"
+ },
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "balance": {
+ "type": "number"
+ },
+ "bank": {
+ "type": [
+ "object",
+ "string",
+ "null"
+ ]
+ },
+ "bankApy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "bankCount": {
+ "type": "number"
+ },
+ "baselineApy": {
+ "type": "number"
+ },
+ "comparisonApy": {
+ "type": "number"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_bank_gap_index2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "banksTracked": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "gapPoints": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "headlineValue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "index_id": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "month": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "nationalAvgApy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "releaseArchiveUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "topAvgApy": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_card_changes2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "changes": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "number"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "sinceDays": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_card_downgrade_path2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "cardId": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "downgradePaths": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "feeRefundWindow": {
+ "additionalProperties": true,
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "feeRefundWindows": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_card_offers2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "count": {
+ "type": "number"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "offers": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "totalTracked": {
+ "type": "number"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_cd_rollover_rules2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "autoRenewDefault": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "autoRenewDescription": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "earlyWithdrawalPenalty": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "gracePeriodDays": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "institutionId": {
+ "type": "string"
+ },
+ "institutions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "sourceUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_index_dataset2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "index_id": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "series": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_rate_freshness2 fields changedOutput schema / propertiesAdded value: +{
+ "affectedRoutes": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tool": {
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_reality_score2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "index_id": {
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "segment": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_reward_valuations2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "count": {
+ "type": "number"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "valuations": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]get_top_hysa_rates2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "type": "string"
+ },
+ "attributionDetails": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "category": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "emptyReason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "rate_type": {
+ "enum": [
+ "APY",
+ "APR"
+ ],
+ "type": "string"
+ },
+ "rates": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "sourceDetails": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "supportedCategories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "terms": {
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "category",
+ "count",
+ "generatedAt",
+ "freshnessStatus",
+ "rates"
+]get_top_rates2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "type": "string"
+ },
+ "attributionDetails": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "category": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "emptyReason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "rate_type": {
+ "enum": [
+ "APY",
+ "APR"
+ ],
+ "type": "string"
+ },
+ "rates": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "sourceDetails": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "supportedCategories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "terms": {
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "category",
+ "count",
+ "generatedAt",
+ "freshnessStatus",
+ "rates"
+]get_transfer_bonuses2 fields changedOutput schema / propertiesAdded value: +{
+ "asOf": {
+ "description": "ISO timestamp of the underlying data this response reflects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "attribution": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "count": {
+ "type": "number"
+ },
+ "datasetUrl": {
+ "type": "string"
+ },
+ "error": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "suggestions": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "freshnessStatus": {
+ "enum": [
+ "fresh",
+ "aging",
+ "stale",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "generatedAt": {
+ "description": "ISO timestamp this response was computed at.",
+ "type": "string"
+ },
+ "methodologyUrl": {
+ "type": "string"
+ },
+ "routes": {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / requiredAdded value: +[
+ "schemaVersion",
+ "tool",
+ "generatedAt"
+]best_move_this_week1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}compare_switch_savings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_bank_gap1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_bank_gap_index1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_card_changes1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_card_downgrade_path1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_card_offers1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_cd_rollover_rules1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_index_dataset1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_rate_freshness1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_reality_score1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_reward_valuations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_top_hysa_rates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_top_rates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_transfer_bonuses1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}get_card_downgrade_pathget_cd_rollover_rulesbest_move_this_weekget_card_changesget_card_offersget_reward_valuationsget_transfer_bonusescompare_switch_savingsget_bank_gapget_bank_gap_indexget_index_datasetget_rate_freshnessget_reality_scoreget_top_hysa_ratesget_top_ratesLive US savings, CD, mortgage & HELOC rates with source + timestamp on every figure.
Live US mortgage, auto, HELOC, personal & deposit rates with evidence, plus who can join each lender
Source-linked US credit-union deposit rates and membership context. Request a key via our site.
Search, compare and estimate rewards across US credit cards. Verified fees, APRs and bonuses.
Add one secure layer between your agents and this server.
