Estimate mobile-data needs and build a provider-neutral connectivity checklist for any trip.
Scored across 2 tools
The two tools address clearly different intents: one builds a route-level connectivity guide, the other checks device-level eSIM compatibility. Each description explicitly redirects users to the other tool when appropriate, removing any ambiguity.
Both tools follow a consistent verb_noun snake_case pattern: build_travel_connectivity_guide and check_esim_device_compatibility. The naming style is uniform and predictable.
Two tools is on the thin side for a server, though the scope is narrow and each tool is substantive. This is a borderline count rather than clearly well-scoped or excessive.
The pair covers the core workflow of travel connectivity planning plus eSIM device readiness. Some adjacent capabilities, such as network coverage checks or roaming guidance, are not represented, but the described purpose is mostly fulfilled.
Creates a free, provider-neutral mobile-data estimate and readiness checklist for a travel route. Use it for trip data budgeting, hotspot planning, offline readiness, and connection fallback advice. Do not use it for a pure phone eSIM compatibility question; use check_esim_device_compatibility instead. It does not browse, compare, promote, recommend, price, sell, or link to products, plans, carriers, or connectivity services.
| Name | Required | Description | Default |
|---|---|---|---|
| stops | Yes | One to eight destinations in travel order. | |
| locale | No | BCP 47 language tag for the requested guide. | en |
| hotspot | No | Whether one or more travelers expect to share data by hotspot. | |
| travelers | No | Travelers who need connectivity. | |
| usageProfile | No | light for maps and messaging, balanced for everyday use, heavy for frequent media, or remote-work for calls and laptop work. | balanced |
| deviceReadiness | No | confirmed when eSIM support and unlocked status are known, unsure when unverified, or not-supported when the device cannot use eSIM. | unsure |
| Name | Required | Description |
|---|---|---|
| stops | Yes | |
| status | Yes | |
| summary | Yes | |
| limitations | Yes | |
| riskSignals | Yes | |
| safeFallbacks | Yes | |
| questionsToConfirm | Yes | |
| readinessChecklist | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining it is free, provider-neutral, and that it 'does not browse, compare, promote, recommend, price, sell, or link to products, plans, carriers, or connectivity services.' This goes beyond what the annotations alone convey.
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?
Three sentences with no wasted words: the core purpose is first, followed by use cases, then the exclusion/disambiguation, then behavioral boundaries. Every sentence earns its place.
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?
Given that the tool has an output schema, six fully described parameters, and annotations covering safety, the description supplies the remaining needed context: purpose, use cases, exclusions, and what the tool intentionally does not do. Nothing essential 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 schema already documents all six parameters. The description mentions high-level use cases but does not add parameter-level detail; the schema carries that burden, so the baseline score of 3 is appropriate.
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 ('Creates') and a concrete resource ('a free, provider-neutral mobile-data estimate and readiness checklist for a travel route'). It explicitly distinguishes itself from the sibling tool by stating it is not for pure phone eSIM compatibility questions.
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 lists clear use cases (trip data budgeting, hotspot planning, offline readiness, connection fallback advice) and gives an explicit alternative for a related but different task: 'Do not use it for a pure phone eSIM compatibility question; use check_esim_device_compatibility instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool whenever the user asks whether a phone supports eSIM or is ready for a travel eSIM. Check an exact phone model against Skyalo's manufacturer-sourced compatibility catalog, including regional variants, carrier locks, EID, and Add eSIM settings. Do not call build_travel_connectivity_guide for a pure device question. Unknown never means incompatible. This tool does not search, compare, recommend, price, sell, or link to connectivity plans.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Exact phone model, for example Samsung Galaxy S24 or Apple iPhone 15; not a broad product family. | |
| locale | No | ||
| region | No | Country or sales region of the exact device variant. | |
| eidPresent | No | ||
| manufacturer | No | ||
| carrierUnlocked | No | ||
| addEsimSettingPresent | No |
| Name | Required | Description |
|---|---|---|
| checks | No | |
| device | No | |
| reason | No | |
| source | Yes | |
| status | Yes | |
| guidance | No | |
| suggestions | No | |
| catalogStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds beyond that: it reveals the data source (manufacturer-sourced), the interpretation rule ('Unknown never means incompatible'), and the boundary of no plan recommendation/linking. This is meaningful behavioral context that annotations don't convey.
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?
Three sentences, each earning its place: the trigger, the core mechanism, and the explicit exclusions. The most decision-relevant information is front-loaded, and there is no repetition of schema or annotation data. Exactly as concise as needed.
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 an output schema present, return values are already defined elsewhere. The description gives the agent everything needed to invoke correctly: the when, the what, the alternative to avoid, and the critical interpretation caveat about 'Unknown'. Nothing essential is missing given the tool's read-only, low-risk nature.
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 only 29%, so the description must compensate—and it does by naming the key check dimensions (regional variants, carrier locks, EID, Add eSIM settings) which map to region, carrierUnlocked, eidPresent, and addEsimSettingPresent. However, locale and manufacturer remain undocumented in both schema and description, leaving a small gap. The model parameter is also enriched by the schema's 'not a broad product family' note.
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 verb ('Check') plus a precise resource ('Skyalo's manufacturer-sourced compatibility catalog') and enumerates the factors considered (regional variants, carrier locks, EID, Add eSIM settings). The final sentence explicitly lists what the tool does not do, sharply distinguishing it from the sibling tool build_travel_connectivity_guide. A pure device question is unambiguously routed here.
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 opens with an explicit when-to-use trigger ('whenever the user asks whether a phone supports eSIM or is ready for a travel eSIM') and directly instructs not to call the sibling for a pure device question. It also enumerates exclusions ('does not search, compare, recommend, price, sell, or link to connectivity plans'), giving the agent clear boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_esim_device_compatibility1 field changedInput schema / properties / model / descriptionPrevious value: -"Exact phone model, not a broad product family."New value: +"Exact phone model, for example Samsung Galaxy S24 or Apple iPhone 15; not a broad product family."check_esim_device_compatibilitybuild_travel_connectivity_guideFind public eSIM plans by destination, trip length, data needs, currency, and locale.
Plan trips and track visa days per traveller across 39,601 entry rules
Search, recommend & buy travel eSIM data plans for 190+ destinations via AI agents.
Travel eSIM catalog: search plans, check availability, and get exact quotes with checkout links.
Add one secure layer between your agents and this server.
