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

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_offers"
  }
}

Input Schema

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

Output 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 31, 2026

addedInput schema / properties / as_of

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

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

Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?