transita_search_by_nationalityShow top destinations and recommended visa pathways for citizens of a given country. Ideal first stop for the question 'Where should I move?'. Returns 4-6 destinations with the best-fit visa for each, key stats, and FAQ. Falls back gracefully if a slug isn't yet curated.
| Name | Required | Description | Default |
|---|---|---|---|
| nationality | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides specifics: 'Returns 4-6 destinations with the best-fit visa for each, key stats, and FAQ' and mentions graceful fallback for uncurated slugs. This gives the agent a clear expectation of the output and behavior in an edge case, which is more than minimally adequate.
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, each with a distinct purpose: purpose, usage context, and output/edge-case behavior. It is front-loaded with the core action, no filler, and every sentence contributes 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?
For a simple one-parameter search tool without an output schema, the description covers the main aspects: what it returns, how it behaves on uncurated data, and when to use it. It could optionally state sorting order or define 'key stats', but these are minor omissions given the tool's simplicity.
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?
The schema only defines 'nationality' as a string with no description. The tool description compensates by clarifying it means 'citizens of a given country' and references 'slug' input. This adds meaningful semantic context beyond the bare schema, especially given the 0% schema description coverage.
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 clearly states the tool's function: 'Show top destinations and recommended visa pathways for citizens of a given country.' This is a specific verb+resource combination. It also distinguishes itself from sibling tools by positioning this as the 'ideal first stop' for relocation queries, focusing on discovery rather than comparison or 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?
The description gives clear context for when to use this tool: 'Ideal first stop for the question "Where should I move?"' This implies it is for initial exploration. It does not explicitly name alternative tools or cases where another sibling would be preferred, which is why it doesn't reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct query type: comparison, country-level overview, profile matching, live status, nationality-based search, and detailed visa info. Even though visa_details and programme_status both concern a single pathway, their purposes are clearly separated as static details versus live intake status.
All tools share a consistent transita_ prefix and use snake_case, but the post-prefix patterns are mixed: compare_visas and match_visas are verb_noun, while country_overview, programme_status, and visa_details are noun-based. This is a minor inconsistency that does little to impede selection.
Six tools is an appropriate scope for a visa advisory server, covering search, comparison, detail, and status-checking without redundancy. Each tool has a clear role in the user journey from initial exploration to specific pathway evaluation.
The server covers the core advisory workflow: find destinations by nationality, get country overviews, match profiles, compare pathways, fetch details, and check current intake status. A notable minor gap is the absence of a direct 'list all visas for a country' tool, but search_by_nationality and country_overview mitigate this.