Credit GPS — Canadian credit

Building a Canadian credit file from zero

get_newcomer_credit_path

Read-onlyIdempotent

Use this for any question about building credit as an immigrant, newcomer, international student, or temporary resident in Canada. Returns the ordered path for someone new to Canada: what to do before a SIN arrives, whether their home-country history can be imported and at which banks, how to get a first tradeline, and what accumulates after that. Supply the home country for a specific answer on credit import; coverage is partial, and several of the largest source countries for Canadian newcomers are not covered at all. Returns bundled reference material, optionally filtered or calculated from inputs; does not fetch live data or change accounts.

Input Schema

Name	Required	Description	Default
`homeCountry`	No	Country the person is arriving from, in English. Determines whether the credit-import route is open.
`monthsInCanada`	No	Roughly how long they have been in Canada, to focus the answer on the relevant phase.

Output Schema

Name	Required	Description	Default
`asOf`	Yes
`steps`	Yes
`disclosure`	Yes
`bankPrograms`	Yes
`creditImport`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 25, 2026
- removedOutput schema / properties / creditImport / properties / covered / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / creditImport / properties / covered / type
```
Added value: +[
+  "boolean",
+  "null"
+]
```
- removedOutput schema / properties / creditImport / properties / homeCountry / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / creditImport / properties / homeCountry / type
```
Added value: +[
+  "string",
+  "null"
+]
```
AddedSep 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses important behavioral limits: the answer is bundled reference material, does not fetch live data or change accounts, and credit-import coverage is partial with several major source countries missing entirely. Those coverage caveats materially affect how an agent should present and trust the output.

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 description front-loads the intended use case and the returned path before adding the coverage caveat and scope note. It is generally efficient, though the final sentence about bundled reference material and not fetching live data is somewhat boilerplate and could be integrated more tightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With two fully described optional parameters, rich annotations, and an output schema, the description supplies enough context to call the tool correctly. Its main remaining gap is sibling routing: it does not clarify when to prefer this over related planning or mechanics tools, and it barely explains how monthsInCanada shapes the answer.

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 are already documented, setting a baseline of 3. The description adds that homeCountry specifically determines whether the credit-import route is open, but monthsInCanada is only indirectly implied by the phase language and gets no additional detail.

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 states a specific verb and resource — it returns the ordered path for building a Canadian credit file as a newcomer — and enumerates the phases covered (before SIN, credit import, first tradeline, accumulation). This makes it clearly distinguishable from mechanics explainers like explain_canadian_credit_mechanics and from product lists like list_credit_building_products.

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?

It gives an explicit trigger audience — immigrants, newcomers, international students, temporary residents — and says to supply the home country for a specific import answer. However, it does not name sibling tools or clarify boundaries against related tools such as get_credit_plan, explain_canadian_credit_mechanics, or list_credit_building_products, leaving some selection ambiguity.

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?