Visa eligibility matcher and immigration intelligence for MCP-compatible AI assistants. Scores ~45 visa pathways across 8 countries with country comparisons, document checklist previews, and curated nationality guides. Every match linked back to the official government source.
Scored across 11 tools
Most tools are cleanly separated by action+resource: catalogue browsing (list_visas), single-record detail (visa_details), profile matching (match_visas), multi-path comparison (compare_visas), and per-country aggregation (country_overview). The closest pair is list_visas vs. search_by_nationality and match_visas, but the descriptions make the entry condition (no profile / citizenship only / full profile) explicit enough to choose correctly.
Every tool uses the same prefixed snake_case verb_noun pattern (transita_list_visas, transita_visa_details, transita_rule_changes). Verbs are meaningful and non-redundant across the set.
11 tools sit in the well-scoped range, and each maps to a distinct user need in the relocation-research domain (discovery, matching, scoring, status, cost, rankings, rule monitoring). No obvious filler or near-duplicate entries.
The surface covers the full advisory lifecycle: browse, detail, match, compare, points scoring, intake status, cost of living, city rankings, and rule-change monitoring, plus a nationality-first entry point. Gaps are minor — there is no tool to save/track a chosen route (it is punted to the website) and no city-level detail beyond rankings and rent ranges, but agents can work around both.
Compare 2 or 3 visa pathways side by side: processing time, cost, validity and PR route for each, then which one is quickest to process, which costs least and which lead to permanent residency.
| Name | Required | Description | Default |
|---|---|---|---|
| visa_ids | Yes | 2 or 3 Transita visa ids, e.g. ['us-o1a', 'de-blue-card']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuinely new behavioral detail: the fields being compared (processing time, cost, validity, PR route) and the derived verdicts (quickest, cheapest, leads to PR), which tells the agent what the response will contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and the compared dimensions, with the derived answers appended in priority order. Every clause carries information; only the long trailing list of 'which one...' clauses adds slight density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a single-parameter read with no output schema, so the description must convey the return shape — it does so by enumerating the four compared attributes plus the three computed verdicts. Nothing an agent needs in order to decide and call correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented, including the 2-3 item constraint and an example. The description's '2 or 3 visa pathways' only echoes the minItems/maxItems already in the schema, adding no new syntax or format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (compare visa pathways) and pins the scope to exactly 2 or 3 entries, which matches the schema bounds. It does not explicitly contrast with the nearest sibling, transita_visa_details (single-visa lookup) or transita_match_visas, so an agent must infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'compare ... side by side', which makes the multi-visa case obvious, but the description never says when NOT to use it or which sibling to reach for instead (e.g. visa_details for one visa, match_visas for finding candidates). Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monthly budget and rent ranges in US dollars for the cities Transita profiles, filtered by country or city. Figures are editorial estimates from public sources, each with its review date and sources. Use them for orientation, then check local listings.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name or slug, e.g. 'Berlin' or 'new-york'. | |
| country | No | Lowercase destination country code, e.g. 'de', 'ca' or 'uk'. 'gb' also works for the UK. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive, and closed-world nature of the tool. The description adds meaningful context beyond annotations by stating that figures are editorial estimates from public sources, include review dates and sources, and are not authoritative for decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no waste. It front-loads what the tool returns, then adds provenance and a practical caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with two optional, fully documented parameters and no output schema, the description is complete enough to call the tool correctly. It explains the returned data, filtering options, provenance, and the intended caution about using estimates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters, including examples for city and country codes. The description reinforces that filtering is by country or city but does not add syntax or format details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource: monthly budget and rent ranges in US dollars for cities Transita profiles. It explicitly names the filtering dimensions, country or city, which distinguishes it from the visa-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: figures are for orientation and should be checked against local listings. However, it does not explicitly state when not to use this tool or name a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get summary data for a destination country: number of visa pathways, EU member status, score dimensions, drawbacks, top cities with rent ranges, and PR/citizenship timelines.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Lowercase destination country code, e.g. 'de', 'ca' or 'uk'. 'gb' also works for the UK. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, idempotent read, and the description adds valuable return-content detail: visa pathway counts, EU status, score dimensions, drawbacks, cities with rent ranges, and PR/citizenship timelines. It does not describe error behavior or what happens for unsupported countries, but it adds substantial context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a compact list of return contents; every item adds useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description responsibly enumerates the main returned data categories, and the sole parameter is fully documented in the schema. It still leaves minor gaps around error handling, data freshness, and the exact response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema fully documents the country_code format and UK alias behavior. The description adds only the phrase "destination country" and no additional parameter constraints, which is adequate but not enriching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get summary data for a destination country") and enumerates the overview contents, making the tool's scope clear. It does not explicitly distinguish itself from siblings such as transita_visa_details or transita_cost_of_living, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what data is returned but gives no explicit guidance on when to choose this overview versus sibling tools like transita_compare_visas, transita_cost_of_living, or transita_visa_details. Usage is only weakly implied by the word "summary".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the visa catalogue without a profile. Filter by country, category or whether the route leads to permanent residency. Each row gives the id, name, country, government fee, processing time and PR route, so you can pick ids for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most rows to return, e.g. 20. Default 50. | |
| country | No | Lowercase destination country code, e.g. 'de', 'ca' or 'uk'. 'gb' also works for the UK. | |
| category | No | Visa category, e.g. 'skilled_worker', 'digital_nomad' or 'student'. | |
| leads_to_pr | No | True for routes that lead to permanent residency, false for those that do not, e.g. true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety bar is lower. The description adds useful context the annotations do not: the catalogue is not scoped to a user profile and each row returns id, name, country, fee, processing time and PR route.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The core action and scope lead, followed by filtering options and then return content, which is the right ordering for an agent deciding whether to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 compensates by naming the returned fields, and it covers all filter dimensions. Only the limit/pagination behavior and the distinction from search/match siblings are left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter meaning is already fully documented, including the country code format and defaults. The description only restates the three filter dimensions and omits the limit parameter, adding no syntax or edge-case detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Browse the visa catalogue') plus a distinguishing scope qualifier ('without a profile'), which separates it from profile-based siblings like transita_match_visas. An agent can identify the tool's function immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'without a profile' hints that profile-driven matching belongs to a different tool, and 'so you can pick ids for the other tools' gives a downstream purpose. No sibling is named and no explicit when-not condition is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the visa routes a person qualifies for from their profile. Returns the top matches ranked by estimated eligibility, with timeline, cost, official sources and a link to track the chosen route on transita.app. EU citizens see freedom-of-movement options first. Read-only: nothing is stored. Scores are estimates, not legal advice or a decision.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years, e.g. 31. | |
| goal | No | Main reason for moving, e.g. 'work_tech'. | |
| timeline | No | When the person wants to move, e.g. '1year'. | |
| wants_pr | No | True to keep only routes that lead to permanent residency, e.g. true. | |
| education | No | Highest completed education, e.g. 'master'. | |
| income_usd | No | Gross yearly income in US dollars, e.g. 85000. | |
| work_field | No | Main field of work, e.g. 'software engineering' or 'nursing'. | |
| work_years | No | Total years of full-time work experience, e.g. 5. | |
| citizenship | Yes | Nationality as a word or country name, e.g. 'Indian' or 'India'. | |
| language_test | No | English test result in that test's own scale, e.g. {test: 'ielts', listening: 8, reading: 7.5, writing: 7, speaking: 7}. Sharpens routes with a language bar. | |
| current_country | No | Country the person lives in now, e.g. 'United Arab Emirates'. | |
| target_countries | No | Destination country codes to focus on, e.g. ['de', 'nl']. Leave out to search all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond annotations: results are ranked by estimated eligibility, ordering favors EU freedom-of-movement routes, and scores are explicitly estimates rather than legal advice or a decision. 'Read-only: nothing is stored' largely restates readOnlyHint, but the ranking caveat and EU ordering rule are genuine additions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core action and followed by returns, ordering, and the read-only caveat. The 'Read-only: nothing is stored' clause overlaps with the annotation and slightly dilutes density, but nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, nested-schema tool with no output schema, the description covers what comes back (timeline, cost, sources, tracking link), which is the main missing structured information. Remaining gaps are routing guidance toward siblings and any statement of how much optional inputs improve match quality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters including the nested language_test and enum values. The description only refers vaguely to 'their profile' and adds no syntax, defaults, or precedence guidance beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find the visa routes') plus the distinguishing scope: personalized to a person's profile and ranked by estimated eligibility. An agent can tell this apart from list_visas, compare_visas, or visa_details without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the tool takes a person's profile, so an agent infers it should be used once profile attributes are known. The description never names an alternative (list_visas, compare_visas, points_calculator) or states when not to use this tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, so the description's added value is the return contract (score, line-by-line breakdown, threshold) and the accuracy caveat ('Same logic as the calculators on transita.app. An estimate, not an official assessment'), which is genuinely useful context an agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: capability and supported systems first, return shape second, accuracy caveat last. Every sentence carries distinct information with no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 25-parameter tool with no output schema, the description covers what is returned and the reliability of that result. It does not note that only the three required params are universal while the rest are system-conditional, though the schema's per-param descriptions carry that load.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each of the 25 parameters is already documented with per-system applicability and examples. The description adds no parameter detail beyond naming the four system enum values, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (score), a specific resource (a profile on a points test), and enumerates the four supported systems with their exact enum keys. This clearly separates it from sibling tools like transita_compare_visas or transita_match_visas, which compare or match rather than compute a score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope boundary ('one points test') and the four system keys imply when to reach for it, but the description never names an alternative tool or states when NOT to use it, e.g. versus transita_match_visas when the user has no full profile yet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the live intake status of a single visa pathway: whether it is currently open, the last selection round and cutoff score (for round-based programmes like Express Entry, AU SkillSelect, or the US H-1B lottery), what is expected next, and the official source. Call this before recommending a pathway so you never send a user toward a closed or paused programme. Continuous-intake visas return an 'open' status.
| Name | Required | Description | Default |
|---|---|---|---|
| visa_id | Yes | Transita visa id, e.g. 'ca-cec'. Get ids from transita_match_visas or transita_list_visas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description usefully adds return semantics (continuous-intake visas return 'open'; round-based programmes return last round and cutoff score). It does not discuss freshness, caching, or error behavior when a visa_id is unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and guidance are front-loaded in one sentence, and the return contents follow. The closing sentence on continuous-intake is useful but the prose is dense enough that one more sentence would have been bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the returned fields (status, last round, cutoff score, next expectation, official source), which is the needed compensation. Risk/edge handling (stale data, unknown visa_id) is the only gap for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single visa_id parameter is already documented with an example and a pointer to transita_match_visas/transita_list_visas. The description adds nothing about the parameter beyond 'a single visa pathway', so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Check the live intake status of a single visa pathway', followed by the exact return payload (open/closed, last round, cutoff score, expectation, source). It clearly separates this from transita_visa_details by scope: one live status field set versus full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit prescriptive trigger — 'Call this before recommending a pathway so you never send a user toward a closed or paused programme' — which tells the agent exactly when in the workflow to use it. It does not name a sibling alternative or state when to skip it, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank Transita's profiled cities on one dimension such as safety, healthcare or tech jobs, highest score first, optionally within one country. Scores run 0 to 100 and are editorial estimates built from the public sources the methodology names, not official statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most cities to return, e.g. 10. Default 10. | |
| country | No | Lowercase destination country code, e.g. 'de', 'ca' or 'uk'. 'gb' also works for the UK. | |
| dimension | Yes | Ranking dimension slug, e.g. 'safety', 'healthcare' or 'tech-jobs'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent lookup. The description adds meaningful context beyond annotations by disclosing that the scores are 0–100 editorial estimates from named public sources, not official statistics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the core behavior and the important data-quality caveat without wasted wording. The ranking semantics are front-loaded before the provenance note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ranked-list tool with no output schema, the description gives the key return characteristics: highest score first and a 0–100 editorial score range. It does not describe the exact result fields, but that is a minor gap against the otherwise complete parameter and annotation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well documented. The description reinforces the dimension and optional country semantics but adds little beyond the schema; the limit parameter is not discussed in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: ranking Transita's profiled cities on one dimension. It also clarifies scope (highest score first, optional country filter), which makes it easy to distinguish from the visa-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Rank ... on one dimension ... optionally within one country,' but there is no explicit guidance on when to choose this over country or cost-of-living siblings. It gives enough context to understand the basic call but leaves alternative routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent recorded changes to a visa's rules or to its official source page, newest first, for one visa or every visa in a country. Each change names the fields that moved, the source and the date. Whether a change is proposed or in force is only stated when a source says so.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Lowercase destination country code, e.g. 'de', 'ca' or 'uk'. 'gb' also works for the UK. | |
| visa_id | No | Transita visa id, e.g. 'uk-skilled-worker'. Get ids from transita_match_visas or transita_list_visas. | |
| since_days | No | How many days back to look, e.g. 90. Default 90. |
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), yet the description adds genuinely new behavioral context: results are newest-first, each change names the moved fields, source and date, and the important caveat that proposed-vs-in-force status is only stated when a source says so. That caveat prevents an agent from over-claiming certainty, which is real value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with zero filler: scope and ordering first, then the returned fields, then the qualification about proposed vs in force. Each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of explaining what a result row contains (moved fields, source, date), which is what an agent needs to interpret the response. It stops short of noting any result cap, truncation, or what an empty result means, a minor gap for a recently-changed feed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters including the 90-day default and the country/visa id formats. The description reinforces the country-vs-visa scoping but adds no syntax, default, or interaction detail beyond the schema — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('recent recorded changes to a visa's rules or to its official source page') with explicit scope and ordering, which is clearly distinct from siblings like transita_visa_details or transita_programme_status. It does not explicitly route against those siblings, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer 'use this to see what recently changed,' and the 'for one visa or every visa in a country' phrase hints at two access modes. But there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. transita_visa_details for full current rules).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List destinations and a suggested visa pathway for citizens of a given country: 4 to 6 destinations, each with key stats, plus an FAQ. Use it when the person asks where they could move and only knows their citizenship. Returns the list of guides if the nationality has no guide yet.
| Name | Required | Description | Default |
|---|---|---|---|
| nationality | Yes | Nationality word or country, e.g. 'Indian' or 'India'. Case does not matter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral detail beyond that: it returns 4-6 destinations with key stats and an FAQ, and explicitly notes the fallback behavior when no guide exists for the nationality. It does not discuss permissions or rate limits, but those are not critical for this read-only search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The primary purpose and scope come first, followed by the usage condition and fallback behavior, so the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries responsibility for explaining returns. It does this well by specifying 4-6 destinations, key stats, an FAQ, and the no-guide fallback. Exact field names are not given, but the description is sufficient for an agent to understand what to expect from this simple one-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter already documents that it accepts a nationality word or country, case-insensitively, with examples. The description reinforces that the input represents citizenship but adds no syntax or formatting details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List destinations and a suggested visa pathway') plus its scope ('for citizens of a given country'). It also describes the result shape (4-6 destinations with key stats and an FAQ), which clearly distinguishes it from siblings like list_visas, match_visas, and compare_visas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear triggering condition: 'Use it when the person asks where they could move and only knows their citizenship.' It does not explicitly name alternatives such as match_visas or compare_visas, but the usage context is specific enough for an agent to select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for a single visa pathway: eligibility category, processing time, fees, validity, PR timeline, and a free preview of the document checklist (lead time, ancillary cost, first section). The full multi-section checklist is part of Transita's paid action plan, which lives on the website.
| Name | Required | Description | Default |
|---|---|---|---|
| visa_id | Yes | Transita visa id, e.g. 'es-digital-nomad'. Get ids from transita_match_visas or transita_list_visas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world behavior, so the bar is lower. The description adds genuinely new context: only a free preview of the checklist is returned (lead time, ancillary cost, first section) and the full multi-section checklist is a paid offering off-tool. That paywall boundary prevents an agent from promising complete data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The returned-field list is front-loaded and the paywall caveat is placed immediately after it, where it is most relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-value burden — and it enumerates the returned sections, which is exactly what an agent needs to decide whether to call it. The paid-vs-free split closes the last gap about data completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's description already gives the id format example and the two sibling tools that supply ids. The prose adds nothing beyond 'a single visa pathway', so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('fetch') plus a precise resource ('full details for a single visa pathway'), followed by an enumeration of the returned fields (eligibility, processing time, fees, validity, PR timeline, checklist preview). The word 'single' implicitly separates it from the list/match siblings, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case inferable — pull detail for one visa once you have an id — and hints that id lookup routes through transita_match_visas/transita_list_visas (that hint lives in the schema, not the prose). It never states when not to use it or explicitly contrasts it with transita_compare_visas, which an agent might reach for instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
transita_compare_visas2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / visa_ids / descriptionAdded value: +"2 or 3 Transita visa ids, e.g. ['us-o1a', 'de-blue-card']."transita_cost_of_livingtransita_country_overview2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / country_code / descriptionAdded value: +"Lowercase destination country code, e.g. 'de', 'ca' or 'uk'. 'gb' also works for the UK."transita_list_visastransita_match_visas14 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / age / descriptionAdded value: +"Age in years, e.g. 31."Input schema / properties / citizenship / descriptionAdded value: +"Nationality as a word or country name, e.g. 'Indian' or 'India'."Input schema / properties / current_country / descriptionAdded value: +"Country the person lives in now, e.g. 'United Arab Emirates'."Input schema / properties / education / descriptionAdded value: +"Highest completed education, e.g. 'master'."Input schema / properties / goal / descriptionAdded value: +"Main reason for moving, e.g. 'work_tech'."Input schema / properties / income_usd / descriptionAdded value: +"Gross yearly income in US dollars, e.g. 85000."Input schema / properties / income_usd / maximumRemoved value: -9007199254740991Input schema / properties / language_testAdded value: +{
+ "additionalProperties": false,
+ "description": "English test result in that test's own scale, e.g. {test: 'ielts', listening: 8, reading: 7.5, writing: 7, speaking: 7}. Sharpens routes with a language bar.",
+ "properties": {
+ "listening": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "reading": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "speaking": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "test": {
+ "enum": [
+ "ielts",
+ "celpip",
+ "pte",
+ "toefl",
+ "none"
+ ],
+ "type": "string"
+ },
+ "writing": {
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "test"
+ ],
+ "type": "object"
+}Input schema / properties / target_countries / descriptionAdded value: +"Destination country codes to focus on, e.g. ['de', 'nl']. Leave out to search all."Input schema / properties / timeline / descriptionAdded value: +"When the person wants to move, e.g. '1year'."Input schema / properties / wants_prAdded value: +{
+ "description": "True to keep only routes that lead to permanent residency, e.g. true.",
+ "type": "boolean"
+}Input schema / properties / work_field / descriptionAdded value: +"Main field of work, e.g. 'software engineering' or 'nursing'."Input schema / properties / work_years / descriptionAdded value: +"Total years of full-time work experience, e.g. 5."transita_points_calculatortransita_programme_status2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / visa_id / descriptionAdded value: +"Transita visa id, e.g. 'ca-cec'. Get ids from transita_match_visas or transita_list_visas."transita_rankingstransita_rule_changestransita_search_by_nationality2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / nationality / descriptionAdded value: +"Nationality word or country, e.g. 'Indian' or 'India'. Case does not matter."transita_visa_details2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / visa_id / descriptionAdded value: +"Transita visa id, e.g. 'es-digital-nomad'. Get ids from transita_match_visas or transita_list_visas."transita_programme_statustransita_compare_visastransita_country_overviewtransita_match_visastransita_search_by_nationalitytransita_visa_details
Add one secure layer between your agents and this server.