Bank account terms as banks publish them, dated: fees, waivers, offers. Read-only. Canada today.
Scored across 5 tools
Each tool has a clearly distinct purpose, and the descriptions explicitly hand off to each other (e.g. compare_products says to use get_product_terms for one account's full terms; list_benefits and list_offers each say where perks vs. welcome offers live). Compare vs. single-term lookup is the only potentially confusable pair, and the boundary (side-by-side vs. one account) is stated outright.
All five names are snake_case verb_noun (compare_products, get_product_terms, list_bank_products, list_benefits, list_offers). The verb set is small and used predictably: list_ for enumeration, get_ for single-resource detail, compare_ for multi-resource.
Five tools is well within the well-scoped range, and each covers a distinct slice of the domain (discovery, terms/rules, side-by-side comparison, perks, offers). Nothing looks like filler, and there is no missing everyday operation that would need an extra tool.
The surface covers the full read-only lifecycle: discover products, fetch one product's terms and rules, compare across products, plus benefits and offers. Minor gaps remain — there is no way to enumerate tracked benefits or coverage dimensions except via an error on an unknown name or via list_bank_products — but agents can work around these.
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: monthly_transactions adds a separate ranking_at_usage and the included-transactions check, and never changes ranking_by_monthly_fee. 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. Case and punctuation are ignored. | |
| channel | No | How the account is opened. Default "any" (terms that apply whatever the channel). | |
| province | No | Province: a two-letter code (ON, QC, ...) or a name such as Ontario or Québec. 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?
The description adds substantial behavior beyond the annotations: it lists returned fields, explains that waivers are never applied to customer balances, states that unpublished-fee products are not_ranked rather than free, and clarifies that monthly_transactions adds a separate ranking without changing ranking_by_monthly_fee. These details are operationally important and go well beyond readOnly/idempotent hints.
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 front-loaded with the primary use case and then enumerates return contents and ranking rules efficiently. Though dense, every sentence carries decision-relevant information for correct tool selection and interpretation.
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, annotations, and full parameter schema, the description supplies the remaining behavioral context an agent needs: what is returned, how rankings work, how unpublished fees are handled, and when to use the sibling tool instead. Nothing essential for correct invocation appears 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 coverage is 100%, so the schema already documents all five parameters. The description nevertheless adds meaningful semantic context for monthly_transactions by explaining it checks included transactions and creates a separate ranking_at_usage without altering ranking_by_monthly_fee; product_slugs are implicitly tied to list_bank_products. It adds less for cohort, channel, and province beyond what the schema says.
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 and resource ("compare accounts") and enumerates exactly what one call returns, including fees, rankings, variants, and missing data. It clearly distinguishes this from get_product_terms by saying that tool is for a single account's complete terms and rule logic.
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 explicitly states when to use it: "when the user wants to compare accounts, within one bank or across banks." It also names the alternative for a different need: "For one account's complete terms and rule logic use get_product_terms." This gives an agent clear routing guidance.
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). cohort, province and channel pick the variant (defaults current, ALL and any, echoed in defaults_applied; cohort ignores case and punctuation, so "Senior 60+" finds senior_60_plus). If none matches, no_variant_matched lists available_cohorts: a problem with the query, not missing data. An unknown product_slug returns an error naming the nearest published slugs. 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. as_of (YYYY-MM-DD) answers for a past date from the rows BLIA holds, each with its effective dates and whether the bank stated them; before BLIA's earliest record it says no_record_before. BLIA cannot say what a fee will be.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Optional past date, YYYY-MM-DD: the terms in force that day, e.g. the day a mortgage funded. A date before BLIA's earliest record answers no_record_before, never a value. Omit for today's terms. | |
| 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. Case and punctuation are ignored. | |
| channel | No | How the account is opened. Default "any" (terms that apply whatever the channel). | |
| province | No | Province: a two-letter code (ON, QC, ...) or a name such as Ontario or Québec. Default "ALL". | |
| attributes | No | Limit to these attributes (at most 40), 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?
Goes well beyond the readOnly/idempotent annotations: it discloses error behavior (unknown product_slug returns an error naming nearest slugs), the no_variant_matched diagnostic (query problem, not missing data), the semantics of not_published/unresolved (unknown, never zero), free-tier data limitations, and the as_of/no_record_before behavior. These are exactly the behavioral traits an agent needs to avoid misinterpreting results.
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?
It is front-loaded with the usage condition, which is good, but the body is a single dense run-on paragraph packing variant selection, error semantics, free-tier limits, as_of, and a disclaimer. Each clause carries information, yet the lack of structure makes it hard to parse quickly and risks the agent skimming past important caveats.
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 six parameters, an output schema, and the complexity of variant selection and date-scoped queries, the description covers everything an agent needs: input semantics, error/diagnostic behavior, free-tier limitations, and the explicit scope boundary ('BLIA cannot say what a fee will be'). Return-format details are appropriately left to the output schema.
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. The description adds meaning beyond the schema by explaining that cohort/province/channel jointly select the variant, that defaults are echoed in defaults_applied, that cohort matching ignores case and punctuation ('Senior 60+' finds senior_60_plus), and the as_of interpretation. This is useful reinforcement but largely restates what the schema already documents.
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 opening sentence names the specific verb (get published terms) and resource (one product's terms) and enumerates the concrete questions it answers (fees, minimum balance, fee waivers, e-transfer/ATM costs, deposit insurance). It is clearly distinguishable from siblings by explicitly delegating multi-account comparison and perks to 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?
Explicitly states when to use it ('when the user asks about one account's fees...') and names alternatives with the condition that selects them: compare_products for several accounts side by side, list_benefits/list_offers for perks and welcome offers. It also handles the when-not case (unknown product, no variant matched) with routing to available_cohorts.
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. Filters combine. Pages hold up to 50 products; pass next_cursor as cursor for the next page (null on the last). 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 declare readOnly/idempotent/non-destructive, but the description adds substantial behavior: pagination mechanics (50 per page, next_cursor, null on last page), filter combination behavior, an empty-result-always-explains guarantee, and free-tier limitations (no source citation, provenance tier or corroboration status). This is meaningful context beyond the annotation profile.
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?
Information is front-loaded with the primary use case first, then return shape, then paging/tier limits, then exclusions. Dense but every clause carries distinct operational information; slightly packed but not padded.
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?
Even though an output schema exists (relieving the need to document returns), the description still summarizes return fields, coverage semantics, empty-result behavior, pagination, and free-tier constraints. Nothing an agent needs to invoke this 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by noting 'Filters combine' and by explaining the cursor handoff ('pass next_cursor as cursor for the next page'), which is behavioral rather than just restating field definitions.
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?
Names a specific verb and resource ('List published Canadian banking products') and immediately scopes it ('Canadian bank accounts, currently chequing at the banks listed in coverage'). It also distinguishes itself from siblings by naming get_product_terms and compare_products as the tools for fees and 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?
Explicit 'Use this first when the user asks about...' guidance, plus a clear exclusion: 'Not for fees or rules: take a product_slug from here to get_product_terms or compare_products.' The when, when-not, and alternative are all stated.
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. An unknown benefit name returns an error listing the benefits BLIA tracks. 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. Case and punctuation are ignored. | |
| 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 only cover the safety profile (readOnly/idempotent/non-destructive), and the description adds substantial behavior beyond that: the includes / does_not_include / not_recorded tri-state, the rule that not_recorded means unknown rather than 'not included', the 'bank_default' basis meaning bank-wide standard terms rather than a product feature, and that an unknown benefit name errors out with the list of tracked benefits. These are exactly the interpretation pitfalls an agent would otherwise get wrong.
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 trigger condition is front-loaded in the first clause, and the remaining sentences each carry a distinct, non-redundant rule (return shape, not_recorded semantics, bank_default caveat, error behavior, sibling routing). No filler or restatement of the title.
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 formatting need not be explained, and the description still covers what an agent must know to call it correctly: scope (ongoing perks only), the meaning of a low-confidence result, error behavior, and where the adjacent concepts live. Nothing material is missing for a zero-required-parameter, read-only listing 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%, so the baseline is 3, but the description adds real semantics the schema does not: with 'benefit' set the result is the three-way include/exclude/unrecorded breakdown per product, and omitting it returns every tracked benefit per product. That materially changes how the parameter should be used, though cohort/province/institution semantics still live only in the schema.
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 concrete verb and resource ('which accounts include a perk or benefit') and enumerates the exact benefit types covered (annual fee rebate, safe deposit box, drafts, rewards points, rate discount). It explicitly separates itself from siblings by naming list_offers for welcome offers and get_product_terms for fees/waivers, so an agent can route 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?
Gives an explicit trigger ('Use this when the user asks which accounts include a perk or benefit') and names the two alternative tools with the condition that selects each (welcome offers -> list_offers, fee/waiver rules -> get_product_terms). It also states the scope exclusion 'Ongoing perks only', which prevents misuse for sign-up offers.
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. Both filters are optional; omit them for every recorded offer. as_of (YYYY-MM-DD) lists the offers in force on a past date, superseded ones included. 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 |
|---|---|---|---|
| as_of | No | Optional past date, YYYY-MM-DD: the offers in force that day, superseded ones included. Omit for today's offers. | |
| 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 declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real domain behavior beyond that: conditions_status=not_recorded means unknown, never 'no conditions', and a product with no recorded offer may still have one. However, it says nothing about result volume, ordering, or pagination behavior for a list endpoint, so with annotations carrying the safety load this lands squarely at adequate-plus rather than 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?
Trigger condition and return shape are front-loaded, and the caveats about conditions_status and missing offers are placed before the routing sentence. It is dense but nearly every sentence carries distinct information; only the as_of restatement slightly duplicates the schema and could be trimmed.
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 summarizes the returned fields and their semantics, and it covers the two failure modes an agent would otherwise get wrong (unknown vs. absent conditions, unrecorded offer vs. no offer). Scope boundaries to list_benefits and get_product_terms close the remaining gap for a three-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?
Schema coverage is 100%, so all three parameters are already documented in the schema. The description reinforces key semantics — both filters optional, omit for all, as_of is a past date with superseded offers included, and results are welcome offers only — but adds little beyond what the schema's own descriptions already say. 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?
Opens with a specific trigger verb and resource (welcome/sign-up offers per account) and states exactly what is returned: cash and non-cash value, qualifying conditions, conditions_status, end date. It also explicitly separates itself from list_benefits (ongoing perks) and get_product_terms (fees/waivers), so the agent can discriminate among siblings without opening 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 first sentence names the user intents that select this tool ('which accounts have a welcome or sign-up offer', 'what an offer gives', 'what they must do to get it'). It also gives explicit exclusions with named alternatives (list_benefits for ongoing perks, get_product_terms for fees), plus the exact condition for using as_of — a past in-force date including superseded offers.
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_product_terms1 field changedInput schema / properties / as_ofAdded value: +{
+ "description": "Optional past date, YYYY-MM-DD: the terms in force that day, e.g. the day a mortgage funded. A date before BLIA's earliest record answers no_record_before, never a value. Omit for today's terms.",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}list_offers1 field changedInput schema / properties / as_ofAdded value: +{
+ "description": "Optional past date, YYYY-MM-DD: the offers in force that day, superseded ones included. Omit for today's offers.",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}compare_products2 fields changedInput schema / properties / cohort / descriptionPrevious value: -"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."New value: +"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. Case and punctuation are ignored."Input schema / properties / province / descriptionPrevious value: -"Two-letter province code. Default \"ALL\"."New value: +"Province: a two-letter code (ON, QC, ...) or a name such as Ontario or Québec. Default \"ALL\"."get_product_terms3 fields changedInput schema / properties / attributes / descriptionPrevious value: -"Limit to these attributes, e.g. monthly_fee, transaction_limit, minimum_balance, nsf_fee, etransfer_rules, atm_rules. Omit for all."New value: +"Limit to these attributes (at most 40), e.g. monthly_fee, transaction_limit, minimum_balance, nsf_fee, etransfer_rules, atm_rules. Omit for all."Input schema / properties / cohort / descriptionPrevious value: -"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."New value: +"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. Case and punctuation are ignored."Input schema / properties / province / descriptionPrevious value: -"Two-letter province code. Default \"ALL\"."New value: +"Province: a two-letter code (ON, QC, ...) or a name such as Ontario or Québec. Default \"ALL\"."list_benefits1 field changedInput schema / properties / cohort / descriptionPrevious value: -"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."New value: +"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. Case and punctuation are ignored."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_offersA household's bank accounts and the context behind them, for any AI. Read-only to banks.
UK current-account switching offers from each bank's own terms, and a planner for which fit.
Czech savings accounts and term deposits: effective rates, net yield and conditions. Read-only.
Read-only Canadian GST/HST rates, small-supplier check and CRA allowance rates, with CRA sources.
Add one secure layer between your agents and this server.