Skip to main content
Glama

Credit GPS — Canadian credit

Building a Canadian credit file from zero

newcomer_credit_path
Read-only

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 to get a specific answer on credit import — coverage is partial, and several of the largest source countries for Canadian newcomers are not covered at all. Use this for any question about building credit as an immigrant, newcomer, international student, or temporary resident in Canada.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
homeCountryNoCountry the person is arriving from, in English. Determines whether the credit-import route is open.
monthsInCanadaNoRoughly how long they have been in Canada, to focus the answer on the relevant phase.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
asOfYes
stepsYes
disclosureYes
bankProgramsYes
creditImportYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only safety, and the description adds meaningful behavior: credit-import coverage is partial and several largest source countries are not covered at all. This is valuable transparency about limitations beyond what annotations or schema provide.

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 is compact and front-loaded with the core purpose, followed by the key parameter caveat and the usage directive. It is slightly dense but every sentence carries useful information, so it earns a solid score without being wasteful.

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 an output schema present, the description does not need to explain return values. It covers scope, audience, phases, and a significant limitation. The only notable gap is not situating this tool among the many siblings, such as canadian_credit_mechanics or credit_plan, but the newcomer focus is distinctive enough.

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%, which sets a baseline of 3. The description adds extra value by warning that home-country coverage is partial and not available for all large source countries, giving the agent a more realistic expectation when the homeCountry parameter is supplied.

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?

The description clearly defines the tool as an 'ordered path' for newcomers and lists the covered phases: pre-SIN actions, home-country credit import, first tradeline, and subsequent accumulation. It identifies the target audience explicitly, which helps distinguish it from generic sibling tools, though it does not name or contrast any sibling directly.

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?

The final sentence gives explicit when-to-use guidance: 'Use this for any question about building credit as an immigrant, newcomer, international student, or temporary resident in Canada.' It provides clear context but does not state exclusions or point to alternative tools, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct Canadian credit question, from mechanics to calculators. Overlapping payment/utilization tools are clearly separated by current status (reported_snapshot), what-if (simulate_paydown), and recommendation (next_move). No two tools would return the same answer to the same query.

Naming Consistency4/5

Names are consistently snake_case and descriptive, but they mix noun phrases (close_card_impact, reported_snapshot) with verb-led phrases (find_statement_close_date, simulate_paydown). The pattern is readable and predictable, with minor grammatical inconsistency.

Tool Count4/5

At 16 tools the server is one over the ideal 3-15 range, but each tool covers a distinct topic or calculation. The count feels heavy yet justified by the breadth of Canadian credit mechanics and calculators.

Completeness4/5

The surface covers foundational mechanics, retention, missed payments, newcomers, products, statement timing, and several calculators, so core workflows are supported. Obvious gaps remain around disputes, fraud alerts, and authorized-user questions, but these are workarounds rather than dead ends.

Resources