Get detailed info about a specific eSIM package, including pricing, VAT/tax note and activation behavior. Pass customer_country to get the correct display currency and VAT flag.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes | Package ID | |
| customer_country | No | Customer's billing/residence ISO country code (e.g. 'DE'). Drives EUR pricing and VAT flag for EU customers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint: false. The description adds meaningful behavioral context beyond those annotations by revealing country-dependent pricing/currency/VAT behavior and the types of details returned. There is no contradiction with 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?
The description is two sentences with no filler. The core purpose is front-loaded, and the only added usage nuance (customer_country) is introduced in the second sentence. Every part 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?
For a simple two-parameter tool with rich annotations and no output schema, the description adequately explains what the tool does and the key parameter behavior. The phrasing 'activation behavior' is slightly vague, but this is a minor gap given the tool's low complexity.
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%, so the baseline is 3, but the description adds value by explaining that customer_country drives the correct display currency and VAT flag and framing package_id as targeting a specific package. This complements the schema's explanations rather than merely repeating them.
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 and resource: 'Get detailed info about a specific eSIM package.' It also lists the key content areas (pricing, VAT/tax note, activation behavior), which clearly distinguishes it from siblings like search_packages or check_* tools.
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 provides clear usage context, especially the instruction to pass customer_country for the correct display currency and VAT flag. It does not explicitly name alternatives or state when not to use the tool, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of the eSIM purchasing workflow: coverage, device compatibility, country listing, package search, package details, checkout creation, and order status. There is no overlap between tools.
All tools follow a consistent verb_noun pattern using snake_case (check_, create_, get_, list_, search_). The verbs are specific to the action and nouns describe the resource, creating a predictable pattern.
Seven tools is well within the ideal range for a domain-specific server. Each tool covers a step in the journey from discovery to delivery, with no redundant utilities.
The tool set covers the entire eSIM purchase lifecycle: discovery (list_countries, search_packages, get_package_details), compatibility verification (check_device_compatibility), coverage assessment (check_coverage), payment (create_checkout), and order tracking (check_order_status). No obvious gaps exist for the intended use case.