UK Data: UK FCDO travel advice

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

Annotations already declare readOnly, idempotent and non-destructive, and the description adds real context beyond them: the data is live from the GOV.UK Content API, the result is names/slugs only rather than advisory text, and the call costs 1 credit. The alternative-name aliasing behavior is a non-obvious trait disclosed up front.

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?

Front-loaded with the core question, then scope, then usage rationale, then source and cost. The parenthetical examples and cost note are justified, though the sentence count is a little higher than strictly needed for a single-parameter lookup.

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 one-parameter list tool with no output schema, the description covers what is returned (destination names, slugs, alternative names), the source and liveness of the data, and the absence of advisory content. Nothing an agent needs before calling it 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?

With one parameter at 100% schema coverage the baseline is 3, but the description adds meaning the schema only hints at: search matches alternative names such as cities and islands (Dubai, Tenerife) and that omitting it lists everything. That clarifies what the filter actually matches against, which is genuinely useful.

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 (lists every FCDO travel advice destination with its GOV.UK slug) and explicitly bounds scope with 'returns names only, not the advice itself', which separates it from siblings like travel_advice_country and travel_advice_safety. The alternative-name mapping purpose is also concrete, with worked examples (Dubai to United Arab Emirates, Tenerife to Spain).

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 a clear when-to-use: call this first to resolve a name into the slug that 'other travel advice tools can be called with'. It also rules out misuse by stating it does not return actual advice. It stops short of naming a specific sibling to use for the advice content itself, which keeps it from a 5.

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 read-only/idempotent/open-world, and the description adds genuinely useful context beyond them: the data source (GOV.UK Content API live), the one-credit cost, and the scope limit that the advice is written for British nationals only. It stops short of describing latency, rate limits, or error behavior for unknown countries.

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?

Front-loaded with the user question, then return contents, then provenance and caveats — a sensible order with no filler. Slightly dense in the final two clauses (other governments' advice plus the booking caveat), but every sentence carries information an agent needs.

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 one-parameter, read-only lookup with no output schema, the description covers what is returned, where it comes from, whose perspective it reflects, and its cost — everything needed to decide to call it and interpret the result.

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 country parameter already documents that it accepts name, alias, or GOV.UK slug with an example and a pointer to travel_advice_countries. The description only says "one country" and adds no format or fallback detail beyond the schema, 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?

Strong specific verb+resource: "Returns the FCDO headline for one country" and enumerates the returned fields (advice against travel, latest change, change history, sections available). It implicitly separates itself from list/aggregate siblings via "one country" and "headline", but never names travel_advice_countries or travel_advice_safety, so sibling routing is inferred rather than stated.

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 opening question ("Is it safe to travel to a country") sets the use case clearly, and the caveat "does not replace reading the full warnings before booking" signals this is a headline check rather than a complete briefing. No explicit when-not-to-use or named alternative (e.g., for full section text or entry requirements) is given.

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/openWorld/non-destructive, so the bar is lower, yet the description still adds substantial context: live retrieval from the GOV.UK Content API, a 1-credit cost, the output shape (headed plain-text subsections), and an explicit caveat that the destination's own authorities set and enforce the rules. The passport-nationality scope limitation is a real behavioral disclosure an agent could not infer from 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?

Front-loaded with the capability question, then immediately the returned section, then source, audience caveat and cost — a sensible information order with no filler sentences. It is dense with clauses, but each clause (output format, source, nationality scope, credit cost) carries distinct value rather than repeating structured fields.

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 one parameter and no output schema, the description must carry the return-value burden — and it does by naming the subsections and format returned. It also covers data provenance (live GOV.UK API), audience limits and cost, leaving nothing an agent needs to decide whether and how to call it.

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 sole 'country' parameter's description already documents accepted forms (country name, alternative name such as city or island, GOV.UK slug, e.g. "spain"). The tool description only restates 'for one country' and adds no further syntax or disambiguation guidance, 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?

Opens with the concrete user question it answers and then states precisely what it returns: the FCDO 'Entry requirements' section for one country, enumerating the subsections (passport validity, visas and length of stay, dual nationals, vaccine certificates, customs rules). That enumeration distinguishes it from siblings such as travel_advice_health, travel_advice_safety and travel_advice_warnings_insurance without having to name them.

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 context is explicit — visa and passport-validity questions for a single country — and it adds a meaningful applicability constraint: written for travellers on a full British citizen passport, with other nationalities directed to the destination's embassy. It stops short of naming sibling tools (e.g. travel_advice_health for vaccination/jab advice) or stating when-not-to-use cases, so it falls short of a 5.

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?

Beyond the annotations, the description discloses the live GOV.UK Content API source, the returned format as headed plain-text subsections, the one-credit cost, and important limitations including that it is not medical advice and does not fetch vaccine detail. These are meaningful behavioral details not captured by readOnlyHint, idempotentHint, or openWorldHint.

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 front-loaded with the user-facing questions and then specifies the returned content, source, limitations, and cost. It is dense but mostly purposeful; the parenthetical cost note and disclaimer are useful, though the opening could be tightened slightly.

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-parameter, read-only tool with no output schema, the description gives enough context to invoke it correctly: it explains the country scope, the exact section returned, the response format, the source, and the key limitations. Nothing material 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 description coverage is 100%, so the country parameter's accepted forms and example are already documented in the schema. The description adds only that the tool applies to one country, which is consistent with the schema but does not add significant new parameter 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 resource and verb: it returns the FCDO 'Health' section for one country. It also enumerates the returned subsections (emergency medical number, vaccines, medicines rules, local healthcare), which clearly distinguishes it from sibling travel advice tools such as safety or entry requirements.

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 opening questions establish the user need this tool addresses, and the description clearly bounds the tool by noting that vaccine detail is not fetched and pointing to TravelHealthPro and NHS fitfortravel instead. It does not explicitly route the agent to sibling tools like travel_advice_safety, but the health-specific scope is clear.

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 (readOnly, idempotent, non-destructive, openWorld), so the description's added value is real: it discloses the upstream source (GOV.UK Content API), that data is live, that only the latest change per country is returned, and that a call costs 1 credit. It stops short of describing pagination or response size behavior for the limit parameter, so not a full 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?

It is front-loaded with the user question it answers, then the payload, source, scope limitation, alternative, and cost — a sensible order. There is minor redundancy between the opening question and the following sentence describing the update time and one-line summary, but no sentence is expendable.

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 still tells the agent what comes back (per-country update timestamp plus the FCDO's summary line). For a zero-required-parameter read tool with full schema coverage, nothing needed to call it 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 description coverage is 100% for the single optional 'limit' parameter, so the schema already carries the range and default. The description adds no meaning beyond that, which is the expected baseline when structured fields do the work.

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 (FCDO/UK travel advice pages) and a specific ordering and payload (newest first, with update time and the FCDO's one-line change summary). It explicitly distinguishes itself from the sibling travel_advice_country, so an agent can select it without opening the 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?

It states the boundary condition ('Shows only the latest change per country') and names the exact alternative tool for the excluded case ('use travel_advice_country for a country's earlier changes'). It also names the intended audience, which clarifies the use context further.

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 readOnly, idempotent, openWorld and non-destructive, so the bar is lower, and the description still adds real value: live source is the GOV.UK Content API, output is headed plain-text subsections, a known content gap ('does not return Regional risks text') is disclosed with the workaround (link in also_see), and the cost is stated as 1 credit. That preempts the two most likely failure modes (missing regional detail, unexpected billing).

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?

Front-loaded with the user-facing question the tool answers, then the return shape, then the important caveat about regional risks, then cost. Information-dense with no filler, though the 'Regional risks' caveat runs a sentence long and the leading rhetorical question delays the literal statement of what is returned.

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 describes the return format (headed plain-text subsections, plus an also_see field), and it notes live sourcing and cost. It is nearly complete for a one-parameter read tool; only the required-ness of the country argument and any pagination/truncation behavior for long pages go unstated.

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%, with the schema already explaining that a country name, alternative name (city, island) or GOV.UK slug is acceptable and giving an example. The description adds no format or normalization guidance beyond the phrase 'for one country', 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?

The description names a concrete verb+resource combo — returning the FCDO 'Safety and security' section for one country — and enumerates the subsections returned (terrorism, protests, crime and scams, laws, outdoor activities, transport). This makes it trivially distinguishable from siblings like travel_advice_health, travel_advice_entry_requirements and travel_advice_warnings_insurance without opening any 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 implied by the content boundary: the agent can infer this is the pick for crime/terrorism/local-law questions. However, it never explicitly says when to choose this over travel_advice_country or travel_advice_warnings_insurance, nor does it state exclusions in tool terms — the only explicit boundary is against an internal section ('Regional risks'), not a sibling tool.

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?

Adds real context beyond the read-only/idempotent/openWorld annotations: the data source (live GOV.UK Content API), the return shape (headed plain-text subsections plus machine-readable alert status), the known limitation that FCDO warning maps are images and are not returned, and a cost of 1 credit. The only gap is nothing about freshness/rate limits beyond the credit note.

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?

Front-loaded with the use-case question and the verb+resource, followed by return format, provenance, limitation, disclaimer and cost in a tight sequence. Every sentence contributes, and the cost hint is correctly placed last in parentheses.

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 the burden of describing return values, and it does so (plain-text subsections plus machine-readable alert status) while also flagging excluded content (maps) and the policy-terms caveat. Nothing needed to call this single-parameter, read-only tool 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% for the single 'country' parameter, and the schema already documents that names, alternative names (city/island) and GOV.UK slugs are accepted. The description adds no parameter-level detail beyond that, so it sits at the baseline for fully documented schemas.

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 ('Returns the FCDO Warnings and insurance section for one country') and pins down the exact section, which implicitly separates it from siblings like travel_advice_safety, travel_advice_health and travel_advice_entry_requirements. The opening question ('Will my travel insurance still be valid?') frames the agent-relevant intent rather than duplicating the name.

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 insurance-validity framing plus the caveat that payout depends on the policy's own terms implies when this tool is the right pick, but the description never explicitly names an alternative or a when-not condition. With siblings covering safety, health and entry requirements, an explicit routing sentence would have raised this score.

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