Skip to main content
Glama

Thai visa eligibility check

check_visa_eligibility
Read-onlyIdempotent

Score every Thai long-stay visa (DTV, ED, retirement, O-A, LTR, Privilege, marriage, work) against a person's age, purpose, savings, income and assets, using current rules. Amounts in THB except assets in USD.

Input Schema

NameRequiredDescriptionDefault
ageYes
fundsThbNoSavings available, THB
jobOfferNoHas a job offer from a Thai employer
purposesYes
assetsUsdNoInvestable assets, USD
marriedThaiNo
incomeThbMonthNoMonthly income, THB

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile needs no restating. The description adds that scoring uses "current rules," hinting at maintained rule currency, but given there is no output schema it should disclose the shape of the result and any caveats about rule freshness or jurisdiction limits.

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?

Two tight sentences, zero filler, with the covered visa set and evaluation inputs front-loaded. The currency caveat is placed last where it belongs as a secondary clarification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter analytical tool with no output schema, the definition says nothing about what comes back — per-visa scores, pass/fail verdicts, ranking, or explanatory rationale. It also omits whether results are exhaustive across all eight visa classes or only the applicable ones, which materially affects how an agent consumes the response.

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?

The currency convention ("Amounts in THB except assets in USD") adds real meaning, resolving the ambiguity in fundsThb/incomeThbMonth versus assetsUsd and explaining the description coverage gap. However, it adds nothing about marriedThai, jobOffer, or how the purposes enum values map to the listed visa classes.

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 names a specific verb ("Score") and resource (Thai long-stay visas), enumerating the covered visa classes (DTV, ED, retirement, O-A, LTR, Privilege, marriage, work) and the input dimensions used. It is clearly a scoring/assessment tool rather than a rule-lookup tool, which implicitly separates it from get_visa_rules, 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 Guidelines3/5

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

Usage is implied: run this when you have a person's profile and want eligibility across visa classes. There is no explicit guidance on when to prefer it over get_visa_rules or list_rule_changes, nor any stated prerequisite (e.g., gather rules first) or exclusion.

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.