US bank, savings and credit-card signup bonuses, each source-checked, with expiry dates.
Scored across 6 tools
Each tool has a stated use-case trigger, and get_bonus (full detail) vs search_bonuses (summary listing) vs compare_bonuses (side-by-side) are meaningfully separated. expiring_soon overlaps conceptually with a filtered search_bonuses, but the description explicitly carves out the timing use case, leaving only minor confusion.
Four tools follow a verb_noun pattern (get_bonus, search_bonuses, compare_bonuses), but expiring_soon is an adjective-style name and the two meta tools use a noun-prefix style (benefits_api_docs, benefits_examples). The conventions are mixed yet still readable and clearly grouped.
Six tools is well-scoped for a signup-bonus lookup domain: one search, one detail, one compare, one timing filter, plus two lightweight support tools. No tool feels redundant or inflated.
The read-only surface covers discovery (search_bonuses), detail (get_bonus), comparison (compare_bonuses), and timing (expiring_soon), which matches the domain without needing create/update/delete. Minor gaps remain, e.g. no explicit listing by bank/provider or state filter, but agents can work around these.
Use when you need field definitions, ordering guarantees or the error format before calling another tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| docs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the doc's topical scope, which helps with the go/no-go decision, but says nothing about freshness, caching, size or whether the content is static — minor behavioral gaps for a docs endpoint.
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 front-loaded sentence with no filler; the trigger condition comes first and each clause (field definitions, ordering guarantees, error format) earns its place by scoping the content.
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 zero parameters, full schema coverage, an output schema covering the return payload, and annotations covering safety, the description supplies everything needed to decide to call it. Only a note on staleness or scope limits would add more.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is 100% and the empty object schema is consistent with a no-argument docs read.
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 enumerates the concrete content the tool exposes ('field definitions, ordering guarantees or the error format'), which clarifies the resource well enough to separate it from siblings like benefits_examples, search_bonuses and get_bonus. It stops short of an explicit verb ('returns/reads the server docs') and leans on the title for the resource framing, so it is clear but not fully self-contained.
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?
It gives a clear trigger — use it 'before calling another tool' when you need field definitions, ordering rules or error format. That is actionable context, but it names no alternatives or exclusions (e.g. when the examples or search tools are preferred instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to copy a working example call instead of guessing tool arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| examples | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not say whether the examples are scoped to a tool, returned as a list, or whether the output is static or live. With annotations carrying the safety burden, the marginal behavioral content is near zero.
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 short sentence, front-loaded with the subject. It wastes no words, though the phrasing 'Use to copy...' is slightly informal and the sentence could have carried more routing information at no length cost.
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 no parameters, an output schema present, and annotations covering safety, the structured data carries most of the load, so the description is close to sufficient. What it still leaves open is the key routing question among five siblings: when an agent should call this instead of benefits_api_docs. That gap keeps it at minimum viable.
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?
There are zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to compensate for. The description's implicit warning against guessing arguments does not need to document parameters that do not exist.
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 name and title both signal a retrieval of runnable examples, and the description states the intent (copy a working example call). But the verb is soft ('use to') and the description never says what is being fetched or from where, nor does it distinguish itself from the sibling benefits_api_docs, which an agent might reasonably pick instead.
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?
It implies a situation (when you don't want to guess arguments), which is a mild use cue, but it gives no when-not guidance and never references benefits_api_docs, the obvious alternative sibling. The agent gets no rule for choosing between this and the docs tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a user is choosing between specific offers. Returns each offer's key fields plus a summary naming the highest bonus and the earliest expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | 2 to 4 bonus ids to compare, e.g. ['chase-total-checking-400', 'sofi-checking-savings-400']. |
| Name | Required | Description |
|---|---|---|
| bonuses | Yes | |
| summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds output-level behavior (the summary highlights highest bonus / earliest expiry) but says nothing about auth needs, missing-id handling, or ordering, so it adds only modest value beyond the structured fields.
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, zero filler: the usage condition comes first and the return shape second. Every clause earns its place and nothing is repeated from the schema or annotations.
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 comparison tool with a full output schema and complete parameter documentation, the description supplies the missing usage context and need not explain return values. Minor gaps remain around error behavior for invalid or non-existent ids, which keeps it below a 5.
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 the 'ids' property already documents the 2-4 range with a concrete example. The description's phrase '2-4 bonuses' merely mirrors the schema's minItems/maxItems and adds no new syntax or format meaning, so the baseline 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 states a concrete output: each offer's key fields plus a summary naming the highest bonus and earliest expiry, which makes the comparison purpose inferable even though the verb 'compare' lives in the title rather than the text. It distinguishes itself from single-record siblings like get_bonus by covering multiple offers, but it never names a 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?
'Use when a user is choosing between specific offers' gives a clear triggering scenario and implicitly contrasts with exploratory tools such as search_bonuses. It does not state when-not to use it or name the alternative for a single-offer lookup, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when timing matters — a user asking what is about to end, or whether to act now. Offers with no stated end date are never included here.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookahead window in days (default 30). |
| Name | Required | Description |
|---|---|---|
| bonuses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower, and the description adds a genuinely non-obvious inclusion policy: offers with no stated end date are excluded. That materially changes how an agent should interpret empty or partial results, which the schema does not convey.
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 short sentences with no filler, and the exclusion rule is placed last as a qualifier after the usage trigger. Slightly weak front-loading in that the first sentence leads with usage rather than stating the core action.
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 at full schema coverage, an output schema to explain returns, and annotations carrying the safety profile, the description only needed to add usage context and any interpretive caveat — both of which it does. Naming the nearest sibling alternatative is the only notable omission.
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 single 'days' parameter documents its default (30) and bounds (1-365). The description adds no additional meaning about the lookahead window, 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 never explicitly states the verb+resource ('list bonuses ending within a window'); that meaning is carried almost entirely by the name and title. The phrase 'a user asking what is about to end' implies the scope but gives no differentiation from sibling search_bonuses, which an agent could plausibly pick instead.
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?
'Use when timing matters — a user asking what is about to end, or whether to act now' gives a concrete situational trigger that clearly separates this from a general lookup. It stops short of naming alternatives (e.g. search_bonuses) or stating when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use before recommending an offer, to read its exact requirements, minimum deposit, direct-deposit rules, expiry date, state availability and the date its terms were last verified. Quote the requirements rather than paraphrasing money amounts.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Bonus id, e.g. 'chase-total-checking-400'. Use search_bonuses to find ids. |
| Name | Required | Description |
|---|---|---|
| bonus | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so an agent knows the safety profile. The description adds real value beyond that by surfacing the terms-verified date (a freshness signal) and an operational directive to quote money amounts verbatim rather than paraphrase — context annotations cannot carry. It omits failure behavior for unknown ids, keeping it from a 5.
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 with no filler: the first establishes the precondition and the payload, the second is a crisp output-handling rule. It opens with usage rather than a one-line statement of what the tool returns, so the core purpose is marginally back-loaded.
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?
An output schema exists, so return fields need not be re-explained, and readOnly annotations cover the safety profile; what remains is when to call it can't be misread. The only gap is behavior on an invalid or unknown id, which is minor for a single-param read 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?
With a single parameter at 100% schema description coverage, the schema already documents the id format and even points to search_bonuses for discovery. The description adds no parameter-level syntax or constraints beyond that, so the baseline 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 conveys a specific read operation on a single bonus offer and enumerates the fields it exposes (requirements, minimum deposit, direct-deposit rules, expiry, state availability, terms-verified date), which implicitly distinguishes it from search_bonuses/compare_bonuses. It never states the verb+resource directly ('fetch the full record for a bonus id'), leaving the purpose implied by the field list rather than declared.
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?
Gives an explicit trigger: 'Use before recommending an offer', which tells the agent when this tool belongs in a workflow. It does not name alternatives such as search_bonuses (that routing hint lives only in the id parameter schema) and offers no when-not guidance, so it stops short of full routing clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a user wants to find a US bank account, savings, credit card or brokerage signup bonus, or asks which offers are worth opening. Returns matching offers sorted by bonus value, highest first — except when balance_transfer is true, which sorts by intro window instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return. | |
| query | No | Keyword matched against bank/issuer, product name and the offer's requirement text, e.g. 'Chase', 'Sapphire' or 'balance transfer'. | |
| state | No | 2-letter US state code, e.g. 'TX'. Nationwide offers always match; regional offers match only their states. | |
| bonus_type | No | Restrict to bank account, credit card, savings or brokerage signup bonuses. | |
| balance_transfer | No | Set true to return only cards whose issuer states a 0% or intro rate on transferred balances. Results come back ordered by the length of that intro window, cheapest transfer fee first as the tie-break — NOT by bonus value, because these cards carry no signup bonus. | |
| min_bonus_amount_usd | No | Minimum bonus value in USD. For credit cards this is the estimated USD value of the points/miles bonus. | |
| direct_deposit_required | No | Filter on whether the bonus requires a qualifying direct deposit. |
| Name | Required | Description |
|---|---|---|
| bonuses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real behavioral value by disclosing the default sort order (bonus value, highest first) and the balance_transfer exception that re-sorts by intro window.
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: the first front-loads the usage trigger, the second front-loads the default return ordering before the exception. No filler and nothing buried.
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?
An output schema exists, so return fields need no explanation, and the description covers the one non-obvious output trait (result ordering). With 0 required parameters and full schema coverage, an agent has everything needed to call it, though sibling routing remains unaddressed.
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 all seven parameters are already documented in the schema, including the balance_transfer ordering rule and the direct-deposit filter. The description restates the balance_transfer sorting behavior but adds no syntax or format detail beyond the schema, so the baseline 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 states a specific verb and resource ('find a US bank account, savings, credit card or brokerage signup bonus') plus the user intent it serves ('which offers are worth opening'). It is clearly distinguishable from a generic search, but it never contrasts itself with siblings like compare_bonuses, expiring_soon or get_bonus.
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?
It gives an explicit trigger condition ('Use when a user wants to find...') rather than leaving usage implied. However, it names no exclusions or alternatives, so an agent still has to infer when compare_bonuses or expiring_soon is the better pick.
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.
search_bonuses2 fields changedInput schema / properties / balance_transferAdded value: +{
+ "description": "Set true to return only cards whose issuer states a 0% or intro rate on transferred balances. Results come back ordered by the length of that intro window, cheapest transfer fee first as the tie-break — NOT by bonus value, because these cards carry no signup bonus.",
+ "type": "boolean"
+}Input schema / properties / query / descriptionPrevious value: -"Keyword matched against bank/issuer and product name, e.g. 'Chase' or 'Sapphire'."New value: +"Keyword matched against bank/issuer, product name and the offer's requirement text, e.g. 'Chase', 'Sapphire' or 'balance transfer'."compare_bonuses5 fields changedOutput schema / properties / bonuses / items / properties / bt_fee_min_usdAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_fee_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_intro_apr_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_intro_monthsAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / requiredPrevious value: -[
- "id",
- "bank_or_issuer",
- "product_name",
- "bonus_type",
- "bonus_amount_usd",
- "bonus_max_usd",
- "bonus_points",
- "annual_fee_usd",
- "requirements",
- "min_deposit_usd",
- "direct_deposit_required",
- "expiry_date",
- "states_available",
- "application_url",
- "source_url",
- "last_verified_date",
- "offer_history",
- "verification",
- "status",
- "eligibility",
- "sponsored",
- "apply_url",
- "disclosure_url"
-]New value: +[
+ "id",
+ "bank_or_issuer",
+ "product_name",
+ "bonus_type",
+ "bonus_amount_usd",
+ "bonus_max_usd",
+ "bonus_points",
+ "annual_fee_usd",
+ "bt_intro_apr_pct",
+ "bt_intro_months",
+ "bt_fee_pct",
+ "bt_fee_min_usd",
+ "requirements",
+ "min_deposit_usd",
+ "direct_deposit_required",
+ "expiry_date",
+ "states_available",
+ "application_url",
+ "source_url",
+ "last_verified_date",
+ "offer_history",
+ "verification",
+ "status",
+ "eligibility",
+ "sponsored",
+ "apply_url",
+ "disclosure_url"
+]expiring_soon5 fields changedOutput schema / properties / bonuses / items / properties / bt_fee_min_usdAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_fee_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_intro_apr_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_intro_monthsAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / requiredPrevious value: -[
- "id",
- "bank_or_issuer",
- "product_name",
- "bonus_type",
- "bonus_amount_usd",
- "bonus_max_usd",
- "bonus_points",
- "annual_fee_usd",
- "requirements",
- "min_deposit_usd",
- "direct_deposit_required",
- "expiry_date",
- "states_available",
- "application_url",
- "source_url",
- "last_verified_date",
- "offer_history",
- "verification",
- "status",
- "eligibility",
- "sponsored",
- "apply_url",
- "disclosure_url"
-]New value: +[
+ "id",
+ "bank_or_issuer",
+ "product_name",
+ "bonus_type",
+ "bonus_amount_usd",
+ "bonus_max_usd",
+ "bonus_points",
+ "annual_fee_usd",
+ "bt_intro_apr_pct",
+ "bt_intro_months",
+ "bt_fee_pct",
+ "bt_fee_min_usd",
+ "requirements",
+ "min_deposit_usd",
+ "direct_deposit_required",
+ "expiry_date",
+ "states_available",
+ "application_url",
+ "source_url",
+ "last_verified_date",
+ "offer_history",
+ "verification",
+ "status",
+ "eligibility",
+ "sponsored",
+ "apply_url",
+ "disclosure_url"
+]get_bonus5 fields changedOutput schema / properties / bonus / properties / bt_fee_min_usdAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonus / properties / bt_fee_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonus / properties / bt_intro_apr_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonus / properties / bt_intro_monthsAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonus / requiredPrevious value: -[
- "id",
- "bank_or_issuer",
- "product_name",
- "bonus_type",
- "bonus_amount_usd",
- "bonus_max_usd",
- "bonus_points",
- "annual_fee_usd",
- "requirements",
- "min_deposit_usd",
- "direct_deposit_required",
- "expiry_date",
- "states_available",
- "application_url",
- "source_url",
- "last_verified_date",
- "offer_history",
- "verification",
- "status",
- "eligibility",
- "sponsored",
- "apply_url",
- "disclosure_url"
-]New value: +[
+ "id",
+ "bank_or_issuer",
+ "product_name",
+ "bonus_type",
+ "bonus_amount_usd",
+ "bonus_max_usd",
+ "bonus_points",
+ "annual_fee_usd",
+ "bt_intro_apr_pct",
+ "bt_intro_months",
+ "bt_fee_pct",
+ "bt_fee_min_usd",
+ "requirements",
+ "min_deposit_usd",
+ "direct_deposit_required",
+ "expiry_date",
+ "states_available",
+ "application_url",
+ "source_url",
+ "last_verified_date",
+ "offer_history",
+ "verification",
+ "status",
+ "eligibility",
+ "sponsored",
+ "apply_url",
+ "disclosure_url"
+]search_bonuses5 fields changedOutput schema / properties / bonuses / items / properties / bt_fee_min_usdAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_fee_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_intro_apr_pctAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / properties / bt_intro_monthsAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / bonuses / items / requiredPrevious value: -[
- "id",
- "bank_or_issuer",
- "product_name",
- "bonus_type",
- "bonus_amount_usd",
- "bonus_max_usd",
- "bonus_points",
- "annual_fee_usd",
- "requirements",
- "min_deposit_usd",
- "direct_deposit_required",
- "expiry_date",
- "states_available",
- "application_url",
- "source_url",
- "last_verified_date",
- "offer_history",
- "verification",
- "status",
- "eligibility",
- "sponsored",
- "apply_url",
- "disclosure_url"
-]New value: +[
+ "id",
+ "bank_or_issuer",
+ "product_name",
+ "bonus_type",
+ "bonus_amount_usd",
+ "bonus_max_usd",
+ "bonus_points",
+ "annual_fee_usd",
+ "bt_intro_apr_pct",
+ "bt_intro_months",
+ "bt_fee_pct",
+ "bt_fee_min_usd",
+ "requirements",
+ "min_deposit_usd",
+ "direct_deposit_required",
+ "expiry_date",
+ "states_available",
+ "application_url",
+ "source_url",
+ "last_verified_date",
+ "offer_history",
+ "verification",
+ "status",
+ "eligibility",
+ "sponsored",
+ "apply_url",
+ "disclosure_url"
+]compare_bonuses1 field changedOutput schema / properties / bonuses / items / properties / bonus_type / enumPrevious value: -[
- "bank_account",
- "credit_card",
- "savings"
-]New value: +[
+ "bank_account",
+ "credit_card",
+ "savings",
+ "brokerage"
+]expiring_soon1 field changedOutput schema / properties / bonuses / items / properties / bonus_type / enumPrevious value: -[
- "bank_account",
- "credit_card",
- "savings"
-]New value: +[
+ "bank_account",
+ "credit_card",
+ "savings",
+ "brokerage"
+]get_bonus1 field changedOutput schema / properties / bonus / properties / bonus_type / enumPrevious value: -[
- "bank_account",
- "credit_card",
- "savings"
-]New value: +[
+ "bank_account",
+ "credit_card",
+ "savings",
+ "brokerage"
+]search_bonuses3 fields changedInput schema / properties / bonus_type / descriptionPrevious value: -"Restrict to bank account bonuses, credit card signup bonuses, or savings account bonuses."New value: +"Restrict to bank account, credit card, savings or brokerage signup bonuses."Input schema / properties / bonus_type / enumPrevious value: -[
- "bank_account",
- "credit_card",
- "savings"
-]New value: +[
+ "bank_account",
+ "credit_card",
+ "savings",
+ "brokerage"
+]Output schema / properties / bonuses / items / properties / bonus_type / enumPrevious value: -[
- "bank_account",
- "credit_card",
- "savings"
-]New value: +[
+ "bank_account",
+ "credit_card",
+ "savings",
+ "brokerage"
+]benefits_api_docsbenefits_examplescompare_bonusesexpiring_soonget_bonussearch_bonusesLive 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
US credit card data: annual fees, credit card credits, earn rates, offers and cashback portal rates.
Search, compare and estimate rewards across US credit cards. Verified fees, APRs and bonuses.
Add one secure layer between your agents and this server.
