Bank account terms as banks publish them, dated: fees, waivers, offers. Read-only. Canada today.
Scored across 5 tools
Each tool targets a distinct scope: full inventory (list_bank_products), single-account terms (get_product_terms), multi-account fee comparison (compare_products), perks (list_benefits) and welcome offers (list_offers). The descriptions explicitly cross-reference each other with routing guidance (e.g. compare_products vs get_product_terms, perks vs welcome offers), leaving no realistic overlap.
All names use consistent snake_case verb_noun form (compare_products, get_product_terms, list_bank_products, list_benefits, list_offers). Verbs are consistently chosen (list for enumerations, get for a single fetch, compare for a multi-item analysis).
Five tools is well-scoped for a read-only product-terms reference: one discovery tool, one detail tool, one comparison tool, and two distinct perk/offer tools. No redundant entries and no obvious missing bucket that would justify adding more.
The surface covers the full read-only domain: discovering products, fetching detailed terms with rule logic, side-by-side comparison, ongoing benefits, and welcome offers, including explicit handling of unknown/not-published data. There are no dead ends for the stated purpose since create/update/delete are not meaningful for a static published snapshot.
Use this when the user wants to compare accounts, within one bank or across banks. One call returns, for each product: monthly fee, annual fee before waivers, included transactions (checked against monthly_transactions if given), minimum balance, NSF fee, the fee-waiver conditions (summary and logic), e-transfer and ATM terms, and what is missing -- plus a ranking by monthly fee with the annual difference to the lowest. It never applies a waiver to the customer's balances: it gives the conditions so they can be checked. Products whose fee BLIA has not published are listed as not_ranked, never ranked as free. The ranking uses published monthly fee and nothing else. For one account's complete terms and rule logic use get_product_terms.
| Name | Required | Description | Default |
|---|---|---|---|
| cohort | No | Customer group the terms apply to. Default "current" (the standard offer). Other groups a product carries (e.g. "senior_60_plus") are listed per product as variants; pass one to get that group's terms. | |
| channel | No | How the account is opened. Default "any" (terms that apply whatever the channel). | |
| province | No | Two-letter province code. Default "ALL". | |
| product_slugs | Yes | 2 to 10 product_slugs from list_bank_products, from one or several banks. | |
| monthly_transactions | No | Optional: the customer's typical debit transactions per month, checked against each product's included transactions. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | When the snapshot was built, ISO 8601 UTC. |
| coverage | Yes | What BLIA does and does not cover: product classes, institutions, kinds of information. |
| freshness | Yes | |
| disclaimer | Yes | BLIA's disclaimer, verbatim. Include it when relaying values. |
| not_ranked | Yes | Products left out of the ranking and why; never ranked as free. |
| coverage_scope | Yes | The product class, institutions and lineup completeness the snapshot covers. |
| staleness_days | Yes | Whole days since as_of. |
| publication_seq | Yes | Publication number of the snapshot being served. |
| freshness_warning | No | Repeats freshness.guidance when the snapshot is not current. |
| ranking_by_monthly_fee | Yes | Products with a published CAD monthly fee, cheapest first, ties by product_slug. Nothing else affects the order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds genuine behavioral context: it never applies waivers to balances, unpublished-fee products are surfaced as not_ranked rather than assumed free, and the ranking uses published monthly fee only. These are exactly the semantics an agent cannot infer from 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?
Front-loaded with the trigger condition, then a dense enumeration of return fields and ranking behavior, ending with the alternative tool. It is long and list-heavy but nearly every clause carries information; slight trimming of the return-field enumeration is possible since an output schema exists.
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 multi-product comparison tool with an output schema and full annotation coverage, the description supplies the remaining essentials: the waiver non-application caveat, the not_ranked edge case, and the ranking basis. Nothing an agent needs to invoke 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?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly; the description only echoes monthly_transactions being checked against included transactions. It adds no meaning for cohort, channel, or province beyond what the schema states, 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?
States a specific verb and resource ('compare accounts, within one bank or across banks') and enumerates exactly what each product comparison returns. It explicitly differentiates itself from the sibling get_product_terms, so an agent can choose between them without opening either schema.
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?
Opens with an explicit trigger ('Use this when the user wants to compare accounts') and closes with a named alternative plus its selecting condition ('For one account's complete terms and rule logic use get_product_terms'). Both when-to-use and when-to-use-something-else are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about one account's fees, included transactions, minimum balance, fee waiver conditions, e-transfer or ATM costs, or deposit insurance. Returns each published term with its value and effective date; a rule comes with its plain-language summary AND its logic (default outcome plus conditions with thresholds, e.g. the balance that waives the monthly fee). Says which customer-group variant was used, which others exist, which questions the terms answer (answerability) and exactly what is not published (before_acting). not_published and unresolved mean unknown, never zero. Free tier: no source quote, content hash, provenance tier or corroboration status. For several accounts side by side use compare_products; for perks or welcome offers across accounts use list_benefits or list_offers. BLIA holds one current snapshot, so it cannot say what a fee was or will be.
| Name | Required | Description | Default |
|---|---|---|---|
| cohort | No | Customer group the terms apply to. Default "current" (the standard offer). Other groups a product carries (e.g. "senior_60_plus") are listed per product as variants; pass one to get that group's terms. | |
| channel | No | How the account is opened. Default "any" (terms that apply whatever the channel). | |
| province | No | Two-letter province code. Default "ALL". | |
| attributes | No | Limit to these attributes, e.g. monthly_fee, transaction_limit, minimum_balance, nsf_fee, etransfer_rules, atm_rules. Omit for all. | |
| product_slug | Yes | A product_slug from list_bank_products, e.g. td-every-day-chequing-account |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | When the snapshot was built, ISO 8601 UTC. |
| coverage | Yes | What BLIA does and does not cover: product classes, institutions, kinds of information. |
| freshness | Yes | |
| disclaimer | Yes | BLIA's disclaimer, verbatim. Include it when relaying values. |
| coverage_scope | Yes | The product class, institutions and lineup completeness the snapshot covers. |
| staleness_days | Yes | Whole days since as_of. |
| publication_seq | Yes | Publication number of the snapshot being served. |
| freshness_warning | No | Repeats freshness.guidance when the snapshot is not current. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds meaningful context beyond that: rule logic and thresholds, answerability, before_acting, and the free-tier omission of source quote, hash, provenance and corroboration. It also flags that not_published and unresolved mean unknown rather than zero, which prevents a costly misreading.
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?
Front-loaded with the usage trigger and return contents, and every clause carries information. The single dense paragraph is slightly overloaded with the answerability/before_acting/free-tier details, but none of it is filler.
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?
Output schema exists and the description still adds what the schema cannot convey: the semantics of not_published/unresolved, the free-tier limitations, and the snapshot-only scope. An agent has everything needed to call it and interpret the result.
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 product_slug, cohort, channel, province and attributes. The description adds no syntax or format detail beyond what those parameter descriptions provide; 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?
States a specific verb and resource ('published terms for one product') and enumerates the concrete content returned: fee values, effective dates, rule logic, cohort variants, answerability and not-published gaps. Siblings are named so the agent can distinguish it from compare_products and list_benefits/list_offers.
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?
Opens with an explicit trigger ('Use this when the user asks about one account's fees, included transactions, minimum balance...') and routes elsewhere for adjacent cases: compare_products for multiple accounts side by side, list_benefits/list_offers for perks. It also states a when-not constraint: BLIA holds one snapshot, so it cannot answer historical or future fee questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this first when the user asks about Canadian bank accounts (currently chequing at the banks listed in coverage), or which accounts a bank offers. Returns every product in BLIA's snapshot with its product_slug, its variants (customer groups such as seniors, each with its eligibility note), the attributes published, and completeness. coverage says what BLIA does and does not cover; an empty result always says why. Free tier: published values only -- no source citation, provenance tier or corroboration status. Not for fees or rules: take a product_slug from here to get_product_terms or compare_products.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | product_slug returned as next_cursor by a prior call | |
| province | No | Province: a two-letter code (ON, QC, ...) or a name such as Ontario or Québec; omit for all provinces. | |
| page_size | No | Up to 50 products per page. | |
| institution | No | Institution id as listed in coverage.institutions_covered (bmo, cibc, rbc, scotia, td: the Big 5); a common or legal name such as BMO, RBC, Scotiabank or Royal Bank of Canada also resolves. Omit for all. | |
| product_class | No | Product class. Only "chequing" is covered today. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | When the snapshot was built, ISO 8601 UTC. |
| coverage | Yes | What BLIA does and does not cover: product classes, institutions, kinds of information. |
| freshness | Yes | |
| disclaimer | Yes | BLIA's disclaimer, verbatim. Include it when relaying values. |
| coverage_scope | Yes | The product class, institutions and lineup completeness the snapshot covers. |
| staleness_days | Yes | Whole days since as_of. |
| publication_seq | Yes | Publication number of the snapshot being served. |
| freshness_warning | No | Repeats freshness.guidance when the snapshot is not current. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds real context: each product carries product_slug, variants with eligibility notes, attributes, and completeness, plus the notable constraint that free tier returns published values only with no provenance/corroboration, and empty results always explain why. It does not mention result-set size or pagination behaviour in prose, which is the one remaining 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?
Front-loaded with the selection trigger, then return shape, then exclusions — a sensible ordering with no filler sentences. It is dense to the point of being slightly run-on, packing snapshot semantics, coverage and free-tier limits into one clause-heavy block.
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, yet the description still summarises the payload shape and, more importantly, flags the free-tier field omissions and the empty-result explanation — the two things an agent could otherwise misread as errors. Nothing needed 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?
Schema description coverage is 100%, so cursor, province, page_size, institution and product_class are already fully documented with formats and examples. The description adds only indirect meaning (that product_class is effectively chequing-only via "currently chequing") and otherwise defers to the schema, which is the expected baseline.
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 and resource (list published Canadian banking products) and pins the scope: chequing only, at banks in coverage. It also distinguishes itself from siblings by naming get_product_terms and compare_products as the path for fees and rules, so an agent can route without opening other 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?
"Use this first when the user asks about Canadian bank accounts..." gives an explicit entry-point condition, and "Not for fees or rules" gives the explicit exclusion plus the named alternatives. Both the when and the when-not are stated rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which accounts include a perk or benefit -- a credit card annual fee rebate, a safe deposit box, free drafts or cheques, rewards points, a borrowing rate discount. With benefit set, returns includes / does_not_include / not_recorded across products; without it, every tracked benefit per product. not_recorded is unknown, never 'not included'. A benefit with basis 'bank_default' is the bank's standard terms for all accounts (no product-specific benefit recorded): say so rather than calling it a feature of the plan. Ongoing perks only; welcome offers are in list_offers, and fees and waiver rules in get_product_terms.
| Name | Required | Description | Default |
|---|---|---|---|
| cohort | No | Customer group the terms apply to. Default "current" (the standard offer). Other groups a product carries (e.g. "senior_60_plus") are listed per product as variants; pass one to get that group's terms. | |
| benefit | No | One benefit, e.g. safe_deposit_box, credit_card_annual_fee_rebate, bank_drafts. Omit for every benefit BLIA tracks. | |
| province | No | Province: a two-letter code or a name such as Ontario. A benefit priced differently in that province is answered with its price there. Default "ALL". | |
| institution | No | Institution id (bmo, cibc, rbc, scotia, td: the Big 5) or a common or legal name such as BMO, RBC or Scotiabank. Omit for all. | |
| product_class | No | Product class. Only "chequing" is covered today. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | When the snapshot was built, ISO 8601 UTC. |
| coverage | Yes | What BLIA does and does not cover: product classes, institutions, kinds of information. |
| freshness | Yes | |
| disclaimer | Yes | BLIA's disclaimer, verbatim. Include it when relaying values. |
| coverage_scope | Yes | The product class, institutions and lineup completeness the snapshot covers. |
| staleness_days | Yes | Whole days since as_of. |
| publication_seq | Yes | Publication number of the snapshot being served. |
| freshness_warning | No | Repeats freshness.guidance when the snapshot is not current. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description goes well beyond them by explaining response semantics (includes/does_not_include/not_recorded), clarifying that not_recorded means unknown rather than excluded, and warning that 'bank_default' basis reflects standard bank terms rather than a product feature. That is genuinely valuable interpretive context.
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?
Front-loaded with the trigger condition and packed with high-value rules; every sentence earns its place. It is a single dense run-on paragraph, so scanability suffers slightly compared to a more segmented structure.
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 format need not be described, and all five parameters are documented in the schema. The description covers the non-obvious interpretive traps (basis 'bank_default', not_recorded semantics) and excludes adjacent concerns by pointing to list_offers and get_product_terms.
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%, so the baseline is 3, but the description adds meaning the schema does not: it explains the functional difference between supplying 'benefit' (returns includes/does_not_include/not_recorded across products) versus omitting it (every tracked benefit per product). Cohort, province and institution semantics are left to the schema, which documents them adequately.
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?
Opens with a specific triggering condition and resource ('which accounts include a perk or benefit'), reinforced with concrete examples (annual fee rebate, safe deposit box, rewards points). It is clearly separable from siblings like list_offers and get_product_terms, which are named outright.
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?
Explicit when-to-use plus explicit routing rules: welcome offers go to list_offers, fees and waiver rules go to get_product_terms, and the ongoing-perks-only scope is stated. Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which accounts have a welcome or sign-up offer, what an offer gives, or what they must do to get it. Returns each recorded offer with what you get (cash and any non-cash part, e.g. a membership), the qualifying conditions (each as a plain sentence), conditions_status, and the end date or that none is stated. conditions_status not_recorded means the conditions are unknown, never that there are none. A product with no recorded offer may still have one: say BLIA records none. Welcome offers only, which end; ongoing plan perks are in list_benefits, and fees and waiver rules in get_product_terms.
| Name | Required | Description | Default |
|---|---|---|---|
| institution | No | Institution id (bmo, cibc, rbc, scotia, td: the Big 5) or a common or legal name such as BMO, RBC or Scotiabank. Omit for all. | |
| product_class | No | Product class. Only "chequing" is covered today. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | When the snapshot was built, ISO 8601 UTC. |
| coverage | Yes | What BLIA does and does not cover: product classes, institutions, kinds of information. |
| freshness | Yes | |
| disclaimer | Yes | BLIA's disclaimer, verbatim. Include it when relaying values. |
| coverage_scope | Yes | The product class, institutions and lineup completeness the snapshot covers. |
| staleness_days | Yes | Whole days since as_of. |
| publication_seq | Yes | Publication number of the snapshot being served. |
| freshness_warning | No | Repeats freshness.guidance when the snapshot is not current. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, but the description adds genuine data-quality caveats: conditions_status='not_recorded' means unknown rather than absent, and an unlisted product may still have an offer, so the agent should say 'BLIA records none' rather than implying the offer does not exist. That is useful behavioral context beyond the 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 usage trigger is front-loaded and every sentence carries information, including the caveat about unrecorded offers. It is dense rather than bloated, though the 'say BLIA records none' phrasing is slightly abrupt and the return-value listing is longer than strictly needed given the output schema exists.
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 an output schema present, full parameter coverage, and complete safety annotations, the description only needs to handle routing and the data-completeness caveats, and it does both. Nothing needed to call this tool 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?
Schema description coverage is 100%, so both parameters (institution, product_class) are already fully documented in the schema. The description adds no syntax, format, or constraint detail beyond it, making the baseline 3 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 resource (welcome/sign-up offers) and states exactly what each record contains: cash/non-cash value, qualifying conditions, conditions_status, and end date. It explicitly separates itself from list_benefits (ongoing perks) and get_product_terms (fees/waivers), so an agent can route correctly.
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 opening clause gives concrete triggering questions ('which accounts have a welcome or sign-up offer', 'what an offer gives', 'what they must do to get it') and the closing sentence names the alternatives and their domains. Both when-to-use and when-to-look-elsewhere are explicit.
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.
compare_products1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "coverage": {
+ "additionalProperties": true,
+ "description": "What BLIA does and does not cover: product classes, institutions, kinds of information.",
+ "properties": {},
+ "type": "object"
+ },
+ "coverage_scope": {
+ "description": "The product class, institutions and lineup completeness the snapshot covers.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "BLIA's disclaimer, verbatim. Include it when relaying values.",
+ "type": "string"
+ },
+ "freshness": {
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "guidance": {
+ "description": "What to say and what to confirm with the institution at this age.",
+ "type": "string"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ },
+ "status": {
+ "description": "How old the snapshot is: current up to 30 days, aging up to 90, then stale.",
+ "enum": [
+ "current",
+ "aging",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "staleness_days",
+ "as_of",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ "freshness_warning": {
+ "description": "Repeats freshness.guidance when the snapshot is not current.",
+ "type": "string"
+ },
+ "not_ranked": {
+ "description": "Products left out of the ranking and why; never ranked as free.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "product_slug": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "product_slug",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "publication_seq": {
+ "description": "Publication number of the snapshot being served.",
+ "type": "integer"
+ },
+ "ranking_by_monthly_fee": {
+ "description": "Products with a published CAD monthly fee, cheapest first, ties by product_slug. Nothing else affects the order.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "product_slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "product_slug"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "as_of",
+ "publication_seq",
+ "staleness_days",
+ "coverage_scope",
+ "coverage",
+ "disclaimer",
+ "freshness",
+ "ranking_by_monthly_fee",
+ "not_ranked"
+ ],
+ "type": "object"
+}get_product_terms1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "coverage": {
+ "additionalProperties": true,
+ "description": "What BLIA does and does not cover: product classes, institutions, kinds of information.",
+ "properties": {},
+ "type": "object"
+ },
+ "coverage_scope": {
+ "description": "The product class, institutions and lineup completeness the snapshot covers.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "BLIA's disclaimer, verbatim. Include it when relaying values.",
+ "type": "string"
+ },
+ "freshness": {
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "guidance": {
+ "description": "What to say and what to confirm with the institution at this age.",
+ "type": "string"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ },
+ "status": {
+ "description": "How old the snapshot is: current up to 30 days, aging up to 90, then stale.",
+ "enum": [
+ "current",
+ "aging",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "staleness_days",
+ "as_of",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ "freshness_warning": {
+ "description": "Repeats freshness.guidance when the snapshot is not current.",
+ "type": "string"
+ },
+ "publication_seq": {
+ "description": "Publication number of the snapshot being served.",
+ "type": "integer"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "as_of",
+ "publication_seq",
+ "staleness_days",
+ "coverage_scope",
+ "coverage",
+ "disclaimer",
+ "freshness"
+ ],
+ "type": "object"
+}list_bank_products1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "coverage": {
+ "additionalProperties": true,
+ "description": "What BLIA does and does not cover: product classes, institutions, kinds of information.",
+ "properties": {},
+ "type": "object"
+ },
+ "coverage_scope": {
+ "description": "The product class, institutions and lineup completeness the snapshot covers.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "BLIA's disclaimer, verbatim. Include it when relaying values.",
+ "type": "string"
+ },
+ "freshness": {
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "guidance": {
+ "description": "What to say and what to confirm with the institution at this age.",
+ "type": "string"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ },
+ "status": {
+ "description": "How old the snapshot is: current up to 30 days, aging up to 90, then stale.",
+ "enum": [
+ "current",
+ "aging",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "staleness_days",
+ "as_of",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ "freshness_warning": {
+ "description": "Repeats freshness.guidance when the snapshot is not current.",
+ "type": "string"
+ },
+ "publication_seq": {
+ "description": "Publication number of the snapshot being served.",
+ "type": "integer"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "as_of",
+ "publication_seq",
+ "staleness_days",
+ "coverage_scope",
+ "coverage",
+ "disclaimer",
+ "freshness"
+ ],
+ "type": "object"
+}list_benefits1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "coverage": {
+ "additionalProperties": true,
+ "description": "What BLIA does and does not cover: product classes, institutions, kinds of information.",
+ "properties": {},
+ "type": "object"
+ },
+ "coverage_scope": {
+ "description": "The product class, institutions and lineup completeness the snapshot covers.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "BLIA's disclaimer, verbatim. Include it when relaying values.",
+ "type": "string"
+ },
+ "freshness": {
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "guidance": {
+ "description": "What to say and what to confirm with the institution at this age.",
+ "type": "string"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ },
+ "status": {
+ "description": "How old the snapshot is: current up to 30 days, aging up to 90, then stale.",
+ "enum": [
+ "current",
+ "aging",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "staleness_days",
+ "as_of",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ "freshness_warning": {
+ "description": "Repeats freshness.guidance when the snapshot is not current.",
+ "type": "string"
+ },
+ "publication_seq": {
+ "description": "Publication number of the snapshot being served.",
+ "type": "integer"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "as_of",
+ "publication_seq",
+ "staleness_days",
+ "coverage_scope",
+ "coverage",
+ "disclaimer",
+ "freshness"
+ ],
+ "type": "object"
+}list_offers1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "coverage": {
+ "additionalProperties": true,
+ "description": "What BLIA does and does not cover: product classes, institutions, kinds of information.",
+ "properties": {},
+ "type": "object"
+ },
+ "coverage_scope": {
+ "description": "The product class, institutions and lineup completeness the snapshot covers.",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "BLIA's disclaimer, verbatim. Include it when relaying values.",
+ "type": "string"
+ },
+ "freshness": {
+ "additionalProperties": true,
+ "properties": {
+ "as_of": {
+ "description": "When the snapshot was built, ISO 8601 UTC.",
+ "type": "string"
+ },
+ "guidance": {
+ "description": "What to say and what to confirm with the institution at this age.",
+ "type": "string"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ },
+ "status": {
+ "description": "How old the snapshot is: current up to 30 days, aging up to 90, then stale.",
+ "enum": [
+ "current",
+ "aging",
+ "stale"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "staleness_days",
+ "as_of",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ "freshness_warning": {
+ "description": "Repeats freshness.guidance when the snapshot is not current.",
+ "type": "string"
+ },
+ "publication_seq": {
+ "description": "Publication number of the snapshot being served.",
+ "type": "integer"
+ },
+ "staleness_days": {
+ "description": "Whole days since as_of.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "as_of",
+ "publication_seq",
+ "staleness_days",
+ "coverage_scope",
+ "coverage",
+ "disclaimer",
+ "freshness"
+ ],
+ "type": "object"
+}compare_productsget_product_termslist_bank_productslist_benefitslist_offersRead-only banking and personal finance for AI agents: accounts, transactions, spending, budgets.
Read-only Canadian GST/HST rates, small-supplier check and CRA allowance rates, with CRA sources.
Live US savings, CD, mortgage & HELOC rates with source + timestamp on every figure.
US bank, savings and credit-card signup bonuses, each source-checked, with expiry dates.
Add one secure layer between your agents and this server.
