Credit GPS — Canadian credit

Find your statement closing date

find_statement_close_date

Read-onlyIdempotent

Use this whenever someone does not know their statement closing date, or gives a payment due date and asks what to pay. Returns the ways to find the closing date of a Canadian credit card, the date every other tool here depends on and the one most people have never been shown. Give a payment due date and it also derives an estimate, because federally regulated issuers must allow at least a 21-day interest-free grace period measured from the close. It looks nothing up on any account; the estimate is arithmetic on the date supplied. Returns bundled reference material, optionally filtered or calculated from inputs; does not fetch live data or change accounts.

Input Schema

Name	Required	Description	Default
`issuer`	No	The issuer, if known, e.g. "TD". Only used to tailor the wording — there is no per-issuer date table, because none is published.
`dueDate`	No	A known payment due date, yyyy-mm-dd. Supplying it produces a derived estimate of the closing date.

Output Schema

Name	Required	Description	Default
`asOf`	Yes
`methods`	Yes
`graceDays`	Yes
`disclosure`	Yes
`derivedCloseDate`	Yes
`derivedFromDueDate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 25, 2026
- removedOutput schema / properties / derivedCloseDate / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / derivedCloseDate / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / derivedFromDueDate / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / derivedFromDueDate / type
```
Added value: +[
+  "string",
+  "null"
+]
```
First observedSep 1, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, the description discloses that nothing is looked up on any account, the estimate is pure arithmetic on the supplied date, no per-issuer table exists, and it returns bundled reference material rather than live data. That is substantive behavioral context an agent cannot get from the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The usage condition is front-loaded, which is good, but the text contains redundancy: 'looks nothing up on any account' is repeated later as 'does not fetch live data or change accounts,' and 'Returns bundled reference material, optionally filtered or calculated from inputs' reads as boilerplate. Some flowery phrasing ('the one most people have never been shown') costs space without adding decision-relevant information.

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 available and annotations covering the safety profile, the description fills the remaining gaps: when to call it, what it does and does not look up, and how the due-date estimate is derived. Nothing essential for correct invocation is missing.

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 coverage is 100%, so both parameters are already documented. The description still adds meaning by clarifying that supplying a due date produces a derived estimate via the 21-day grace-period rule, reinforcing why the parameter matters rather than just what it is.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns the ways to find the closing date of a Canadian credit card, and explains that the date is a dependency for other tools. However, it never names the obvious sibling (get_statement_calendar) or explains how this differs from it, so sibling differentiation is only implied.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger conditions are given: 'whenever someone does not know their statement closing date, or gives a payment due date and asks what to pay.' There is no when-not-to-use guidance or named alternative, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Credit GPS — Canadian credit 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?