BLIA — Bank Product Terms

List account benefits

list_benefits

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / cohort / description

Previous 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."

Changed1 schema field changedOct 20, 2026

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"
+}

First observedOct 20, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All BLIA — Bank Product Terms tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?