Skip to main content
Glama

travel_advisories

Read-onlyIdempotent

Official travel advisories for a country from several governments (for example the US, UK, Canada and Australia), each normalised to a 1-4 level with its own summary and link. Args: country = ISO alpha-3 code; min_level = optional 1-4 filter.

Input Schema

NameRequiredDescriptionDefault
countryYes
min_levelNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that results are aggregated from multiple governments and normalised to a 1-4 scale with summary and link, but says nothing about coverage gaps (countries without advisories), freshness, or auth/rate constraints. With annotations carrying the safety burden, a 3 is appropriate.

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 sentences: the capability and result shape front-loaded, then a terse args clause. No filler, no repetition of the tool name, and the most load-bearing detail (ISO alpha-3) is stated compactly.

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

Completeness4/5

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

An output schema exists, so return-value explanation is not required, and the description covers purpose, sources, normalisation and both arguments. The gap is the absence of any routing guidance against close siblings (country_risk, conflict_events) and no note on countries that may lack advisories.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the entire burden, and it does: country is specified as an ISO alpha-3 code (a critical format detail the schema omits entirely) and min_level as an optional 1-4 filter. Both parameters are fully characterised despite the empty schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (official travel advisories) and its provenance (several governments, e.g. US, UK, Canada, Australia), plus the normalisation scheme to a 1-4 level. This is clearly separable from adjacent siblings like country_risk and conflict_events, which surface different data.

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 rather than stated: an agent can infer this is the tool for government advisory levels, and the min_level filter hints at narrowing behaviour. However, there is no explicit when-to-use guidance or contrast with siblings such as country_risk, so the agent must infer the boundary itself.

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.

Resources