Transita MCP

Points calculator

transita_points_calculator

Read-onlyIdempotent

Score a profile on one points test: Canada Express Entry CRS ('crs'), Australia SkillSelect ('au'), the German Chancenkarte ('chancenkarte') or New Zealand's Skilled Migrant Category ('nz_smc'). Returns the score, a line-by-line breakdown and the threshold to compare it with. Same logic as the calculators on transita.app. An estimate, not an official assessment.

Input Schema

Name	Required	Description
`age`	Yes	Age in years, e.g. 29. Needed by every system.
`system`	Yes	Which points test, e.g. 'crs'.
`married`	No	CRS: true if a spouse or common-law partner comes to Canada too, e.g. false.
`education`	Yes	Highest completed education, e.g. 'bachelor'. Needed by every system.
`income_usd`	No	Gross yearly income in US dollars, e.g. 90000. Used by 'nz_smc'.
`prior_stay`	No	Chancenkarte: spent 6 months legally in Germany in the last 5 years, e.g. false.
`work_years`	No	Years of skilled work, e.g. 4. Needed for 'au' and 'chancenkarte', optional for 'nz_smc'.
`au_subclass`	No	SkillSelect subclass for 'au', e.g. 'au-190'. Default 'au-189'.
`german_level`	No	Chancenkarte: German level, e.g. 'A2'.
`english_level`	No	Chancenkarte: English level, e.g. 'C1'.
`canadian_study`	No	CRS: post-secondary credential earned in Canada, e.g. 'one_or_two_year'.
`in_destination`	No	True if the person already lives in the destination ('au' or 'nz_smc'), e.g. false.
`partner_applies`	No	Chancenkarte: a spouse or partner who also qualifies applies too, e.g. false.
`spouse_education`	No	CRS: the spouse's highest education, e.g. 'bachelor'.
`sibling_in_canada`	No	CRS: a brother or sister lives in Canada as a citizen or permanent resident, e.g. false.
`first_language_clb`	No	CRS: first official language level as a CLB, e.g. 9. Needed for 'crs'.
`foreign_work_years`	No	CRS: years of skilled work outside Canada, e.g. 3.
`canadian_work_years`	No	CRS: years of skilled work in Canada, e.g. 1.
`partial_recognition`	No	Chancenkarte: Germany partly recognised the qualification, e.g. false.
`second_language_clb`	No	CRS: second official language CLB, 0 for none, e.g. 5.
`shortage_occupation`	No	Chancenkarte: the qualification is in a German shortage occupation, e.g. true.
`spouse_language_clb`	No	CRS: the spouse's first official language CLB, e.g. 7.
`provincial_nomination`	No	CRS: holds a provincial nomination, e.g. false.
`spouse_canadian_work_years`	No	CRS: the spouse's years of skilled work in Canada, e.g. 0.
`certificate_of_qualification`	No	CRS: holds a Canadian trade certificate of qualification, e.g. false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 2, 2026
- addedInput schema / properties / spouse_education / $ref
```
Added value: +"#/properties/education"
```
- removedInput schema / properties / spouse_education / enum
```
Removed value: -[
-  "high_school",
-  "associate",
-  "bachelor",
-  "master",
-  "phd",
-  "professional"
-]
```
- removedInput schema / properties / spouse_education / type
```
Removed value: -"string"
```
AddedOct 26, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds value by disclosing the return shape (score, line-by-line breakdown, threshold) and the estimate-not-official caveat. That caveat is the key behavioral fact an agent needs when relaying results to a user.

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

Conciseness5/5

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

Three sentences, front-loaded with the action and the system choices, then what comes back, then the caveat. No repetition of schema content and every sentence carries distinct information.

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 no output schema, the description correctly summarizes the return value, and the schema itself flags which parameters each system needs. The only minor gap is that it never notes only three parameters are required, leaving the agent to infer that much of the 25-parameter surface is optional per system.

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% with 25 well-annotated parameters, including per-system applicability notes and examples, so the schema does the heavy lifting. The description only restates the system enum values and adds no syntax, defaults, or cross-parameter rules beyond that, which is the baseline 3 case.

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?

States a specific verb and resource ('Score a profile on one points test') and enumerates all four systems with their exact enum keys, so the agent can map intent to parameter value directly. No sibling tool offers scoring, and the enumerations make the boundary unambiguous.

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?

Clear context: use this when a user wants a points-test score for one of four named systems, and it explicitly frames the output as an estimate rather than an official assessment. It does not name an alternative tool (e.g. transita_match_visas) or state when not to use it, so it falls short of full routing guidance.

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

All Transita MCP 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?