BLIA — Bank Product Terms

List published welcome offers

list_offers

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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.

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 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.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?