Staylong: Thailand long-stay visas

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, closed-world, and non-destructive, so the safety profile is covered. The description adds the useful return characteristic that the whole document text is returned (versus snippets from search), but says nothing about missing-id errors, size limits, or truncation. Adequate but thin 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?

One front-loaded sentence with a clear verb, the resource, the key constraint (by id), and compact examples. No wasted clauses.

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 single-param read tool with no output schema, the description should say what comes back and how unknown ids behave; 'full text' is the only return hint. It is complete enough to call correctly but leaves error and output shape to inference.

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 has one parameter with 0% description coverage and no type detail beyond 'string', so the description carries the burden and does so with three concrete namespaced id examples ('guide:...', 'place:...', 'office:...'). It still doesn't state whether the prefix is mandatory or what the id must match exactly.

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 ('Get the full text') and resource ('a Staylong document by id'), and the phrase 'from search' plus the id examples make clear this is the retrieval step that follows a search lookup rather than a listing tool.

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?

'by id from search' implies the prerequisite flow: obtain an id via the search sibling, then fetch it here. That distinguishes it from list_places and search, but there is no explicit when-not guidance or statement of what happens for ids that don't exist.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds behavior beyond that by enumerating what the caller receives (address, hours, services, and practical tips for 90-day reports, extensions, TM30), which substitutes for the missing output schema; it does not cover data freshness, multiple offices per city, or result ambiguity.

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 no filler; the primary purpose comes first and the payload details follow. Every clause contributes information an agent would otherwise lack.

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 usefully inventories the response fields, and it covers both geographic lookup modes. The remaining gap is that all three parameters are optional, yet the description never explains the fallback when no location input is supplied.

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 only 33%: only 'city' is documented, and lat/lng carry no description anywhere. The phrase 'for a Thai city, area or coordinates' hints that city and lat/lng are alternative lookup modes, but it does not say whether they can be combined or what happens when all three optional parameters are omitted.

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 immigration office') and adds scope: a Thai city, area or coordinates, plus the returned content (address, hours, services, tips). This clearly separates it from visa-rule siblings like check_visa_eligibility and 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.

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

Usage is implied by the input modes ('for a Thai city, area or coordinates') and by the mention of 90-day reports, extensions and TM30. However, it never states when to prefer find_providers or list_places instead, and gives no prerequisites or exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety behavior needs no restating. The description does add genuine value by enumerating the verification status values returned (verified, contacted, unverified), but says nothing about result volume, pagination, ordering, or what happens when no city is supplied.

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 no filler; the resource list is enumerated compactly. The trailing phrase about Staylong's verification status is slightly dense but still earns its place by flagging a returned field.

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 and all three parameters optional, the description should clarify default behavior (e.g., all cities, all types, verification filtering off) and roughly what comes back. It identifies the domain and the status vocabulary but leaves those operational questions open.

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 only 33% — city is documented, but type and verified_only carry no schema descriptions. The description compensates partially: it names the three entity types that map to the type enum and mentions verification status, which hints at verified_only, but it never explains the boolean's default or the effect of omitting city.

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 (list) and a concrete resource set (language schools, Muay Thai camps, visa agents) scoped to a Thai city, which distinguishes it from the visa/immigration siblings. It does not, however, explicitly differentiate itself from generic siblings like list_places or search, which could plausibly return the same entities.

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 the domain vocabulary: an agent can infer this is the tool for finding schools/camps/agents rather than visa rules. There is no explicit when-to-use vs when-not guidance and no mention of list_places or search as alternatives for broader place lookups.

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

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

The annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: the data comes from a 'live rules table' and each record carries an effective date, official source URL and confidence value. It does not say what happens for an unsupported track or how fresh the 'live' data is.

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, front-loaded with the resource and the returned fields, with no filler. The only waste is the enumerated track list, which duplicates the schema enum instead of adding explanation.

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, and the description does the work of describing the return payload (thresholds, effective date, source URL, confidence), which is the main thing an agent needs. Remaining gaps are minor: currency/units for money and fees, and behavior on an invalid track.

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 0%, but the single parameter is an enum that already constrains the accepted values. The description's trailing track list merely restates that enum verbatim rather than explaining what acronyms such as 'dtv', 'o-a-visa', 'ltr-visa' or 'thailand-privilege' mean, so it adds almost no meaning beyond the schema.

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 gives a specific verb and resource: it returns 'current thresholds for a Thai long-stay visa' with named fields (money, age, income, fees, stay length) for a given track. That is clear enough to distinguish it from check_visa_eligibility, but the differentiation is left implicit; no sibling is named.

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: an agent can infer it should call this to look up rule values before assessing eligibility. There is no explicit when-to-use or when-not-to-use guidance, and no routing between this tool and the closely related check_visa_eligibility or list_rule_changes siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and closed-dataset profile is fully covered without the description. The description does add return-content context (suits, cost level, immigration office) that annotations cannot convey, which is genuinely useful given there is no output schema. It says nothing about result volume, ordering, or pagination, so it adds only moderate value beyond the structured fields.

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 well-formed sentence with the core purpose front-loaded and the useful return-field detail trailing. No filler or restatement of the title. The only weak element is the trailing "or by what the person wants" clause, which is vague and could be dropped or replaced with a reference to the kind parameter.

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?

This is a simple read-only listing tool with two optional parameters and no output schema, so the description's coverage of what is returned and how to filter is close to sufficient. Rich annotations handle the safety and openness questions. The remaining gap is the unattached "what the person wants" filter and the absence of any note on result size or ordering.

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 0%, so the description must carry the semantic load for both parameters. It implicitly explains city via "Filter by city" and loosely explains kind via the "neighbourhoods, towns, islands" parenthetical, which matches the enum values. However, it adds no detail on matching behaviour (exact vs partial city names) and introduces an unsupported "what the person wants" filter concept that has no corresponding parameter.

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 ("List Staylong's long-stay places") and immediately scopes what a place is via the parenthetical "neighbourhoods, towns, islands", which maps onto the kind enum. The return content ("who each suits, cost level and immigration office") further pins down the resource. It does not explicitly contrast itself with siblings like check_visa_eligibility or find_immigration_office, though the resource is plainly distinct.

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 only guidance is "Filter by city or by what the person wants", which is about filtering rather than when to choose this tool over a sibling. There is no statement of when not to use it, no prerequisites, and no named alternative. Worse, "what the person wants" does not correspond to any parameter in the schema, so an agent trying to follow it has nothing to bind to.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add context, and it does: results are ordered newest first and each entry carries dates, and the source of truth is Staylong's own log. It does not say what happens when no changes exist or whether older changes are retrievable beyond the requested window.

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 sentence with no waste; the resource, scope, ordering, and date inclusion are all front-loaded before any 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?

For a simple read-only list tool with no output schema, the description covers source, scope, ordering, and that dates are present, which is enough to call it correctly. The remaining gaps are the undocumented 'limit' default and the shape of an individual change entry.

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 0% for the single optional 'limit' parameter, so the schema supplies only type and bounds (1-50). The description never mentions limiting, defaults, or maximum result count; 'latest' and 'newest first' hint at bounded recency but give no concrete semantics.

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 (Thai long-stay visa rule changes), a specific source ('logged by Staylong'), and an ordering ('newest first'), which implicitly separates it from get_visa_rules (current rules) versus this changelog feed. It stops short of naming that sibling explicitly, so the read-versus-changes distinction must be inferred.

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: the word 'changes' suggests this is for tracking what's new rather than for answering 'what are the rules', but there is no explicit when-to-use or when-not guidance and no reference to get_visa_rules or check_visa_eligibility as alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral information beyond that: results are identifiers rather than full documents, and those ids are meant to be passed to fetch. It omits result limits, ranking behavior, and what happens on zero matches, which keeps it below a 5.

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 short sentences, front-loaded with the verb and content scope, then the return contract. No filler, no repetition of the title, and the fetch hand-off is placed exactly where an agent needs 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?

For a 2-parameter entry-point search with no output schema, the description covers purpose, domain breadth, and the shape of the return value well enough to call it correctly. The remaining gap is routing guidance against the six narrower sibling tools, which a single clause could have closed.

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 kind enum already enumerates every content type. The description's content list ('visa guides, rules, 150 FAQs, nationality pages, place guides, immigration offices and tools') roughly mirrors those enum values without adding format, syntax, or matching semantics. Baseline 3 is appropriate since the schema carries the parameter burden.

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 gives a specific verb (Search) plus the exact resource scope: Thailand long-stay content across visa guides, rules, FAQs, nationality pages, place guides, immigration offices and tools. It also states what comes back (ids). It stops short of naming which sibling to prefer, so an agent can't fully separate it from get_visa_rules or list_places without reading those schemas.

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 phrase 'Returns ids for the fetch tool' implies the intended search-then-fetch workflow, which is real guidance. However, there is no explicit statement of when to use this broad search versus the narrower siblings (get_visa_rules, list_places, find_immigration_office, check_visa_eligibility), so the routing decision is left to inference.

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