Transita

Estimate move cost

transita_estimate_move_cost

Read-onlyIdempotent

Total cost worksheet for one visa route. The government application fee is sourced and dated. Flights, shipping, first rent, adviser, documents and living costs until the first pay are only the person's own figures: pass the ones they know and the rest stay blank, never guessed. Returns the sourced and entered subtotals separately, how many lines are still blank, and a cost-of-living note for the destination.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "visa_id": "<visa_id>"
    },
    "name": "transita_estimate_move_cost"
  }
}

Input Schema

Name	Required	Description
`visa_id`	Yes	Transita visa id, e.g. 'ca-cec'. Get ids from transita_match_visas or transita_list_visas.
`runway_usd`	No	Living costs from landing until the first pay cheque in US dollars, e.g. 5000.
`adviser_usd`	No	Immigration adviser or lawyer in US dollars, 0 if none, e.g. 2500.
`flights_usd`	No	One-way fares for everyone moving, in US dollars, e.g. 1800.
`housing_usd`	No	First rent, deposit and agency fees in US dollars, e.g. 6000.
`shipping_usd`	No	Shipping, freight and storage in US dollars, e.g. 4500.
`documents_usd`	No	Translation, apostille, police certificates and exams in US dollars, e.g. 700.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the description earns credit for the extra behavioral detail it supplies: the government fee is sourced and dated, everything else is unguessed user input, and subtotals are reported separately from entered figures. The only gap is that the shape of the returned cost-of-living note is unspecified.

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?

Three sentences, front-loaded with the purpose before the sourcing rule and the return summary. Dense but every sentence carries information; the phrasing 'only the person's own figures' is slightly awkward but not wasteful.

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 no output schema, the description steps in to describe what comes back: sourced and entered subtotals separately, a count of blank lines, and a destination cost-of-living note. Combined with 100%-covered parameters, an agent has everything needed to call and interpret this tool.

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 3 is the baseline, but the description adds real meaning by grouping the cost categories (flights, shipping, first rent, adviser, documents, living costs until first pay) and clarifying the runway semantics as 'until the first pay'. It also explains the blank-vs-guessed contract that governs every optional parameter.

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?

Opens with a concrete framing: a total-cost worksheet for one visa route, and immediately separates the sourced government fee from user-supplied lines. An agent can tell this is a single-route cost build-up rather than a comparison or a generic cost-of-living lookup, 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.

Usage Guidelines4/5

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

The description makes the invocation model clear: pass the figures the user actually knows, leave the rest blank, nothing is guessed. That is strong guidance for a partially-filled cost tool. It stops short of naming alternatives such as transita_compare_visas for multi-route comparison or transita_cost_of_living for destination baselines.

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

All Transita 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.