列出一心eSIM目前販售方案覆蓋的所有國家/地區（英文與中文名稱對照，含各國方案數量）。 適用情境：使用者問「你們支援哪些國家」「有賣OO地區的eSIM嗎」；或你準備呼叫 search_esim_plans/recommend_esim_plan，但不確定某國家在系統裡該用什麼名稱表示時， 先呼叫這個工具確認，比用猜的準確。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It clearly states the output content (country names and plan counts) and indicates it is a read-only confirmation tool. It does not explicitly state 'read-only' but the verb 'list' implies no side effects; however, it lacks details about potential formatting or error behavior, so a 4 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a single functional statement plus a concise use-case context. It avoids repetition and every sentence adds value, including explicit alternatives and confirmation guidance.
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 zero-parameter tool without output schema, the description provides all essential information: what it returns, why it exists, and when to call it. It also explains the value proposition (avoiding guessing country names), making it fully contextually complete.
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 tool has zero parameters, so there is nothing to document. The description does not need to add parameter meaning; it correctly focuses on the output content and use cases. Baseline of 4 for zero-parameter tools 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 explicitly states the tool lists all countries/regions covered by the eSIM plans, including bilingual names and plan counts. It clearly differentiates from sibling tools by focusing on country listing rather than plan search or ordering.
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 specific triggers: user asks which countries are supported, or before calling search_esim_plans/recommend_esim_plan to confirm country naming. It explicitly names the alternative tools and positions this as a preliminary verification step, which is strong guidance.
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 task: listing countries, searching plans, fetching details, recommending based on needs, and creating orders. The two plan-finding tools are clearly distinguished by their usage intent (browsing vs. recommendation), eliminating ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (list, get, search, recommend, create) with the 'esim_plan' or 'esim_order' object. This uniformity makes the set highly predictable.
With 5 tools, the server is tightly scoped to the eSIM sales journey: discovery, search, detail, recommendation, and order creation. Each tool earns its place without redundancy or bloat.
The server covers the full pre-purchase lifecycle comprehensively, from country listing to order creation with payment links. A minor gap is the lack of an order status or retrieval tool, but this does not hinder the primary workflow of purchasing an eSIM plan.
