取得單一方案的完整詳情，包含商品說明（安裝/啟用步驟等）、各規格庫存、購買連結。 適用情境：使用者對某個已知方案想進一步了解安裝方式、使用細節、或確認庫存時。 需要先從search_esim_plans或recommend_esim_plan的結果取得productId，不要自己編造。
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | 方案的productId（GUID字串），從search_esim_plans或recommend_esim_plan的結果取得 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses what the tool returns (product description, stock, purchase link) and the prerequisite for productId, which is useful. However, it does not mention whether the operation is read-only, potential errors, or any other behavioral traits, but the nature of a detail-fetch implies no side effects.
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 extremely concise, using three short sentences: what it does, when to use, and the prerequisite. It is front-loaded with the main purpose and every sentence adds value without redundancy.
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?
The tool has only 1 parameter and no output schema, so the description carries the burden of explaining return values. It does so by listing the main content areas (description, stock, purchase link). The use case and prerequisite are also covered. It slightly lacks explicit mention of output structure or error behavior, but for a simple detail-fetch, it is largely 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?
Schema description coverage is 100%, and the parameter description in the schema already states that productId is a GUID from search_esim_plans or recommend_esim_plan. The tool description repeats this same guidance, adding no new semantic beyond the schema, so baseline 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 clearly states the tool fetches complete details for a single plan, listing specific contents (product description, stock, purchase link). It distinguishes itself from siblings by targeting a single known plan, while siblings like search_esim_plans or recommend_esim_plan handle discovery.
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 an explicit use case ('when the user wants to know installation steps, usage details, or check stock for a known plan') and specifies that productId must come from search_esim_plans or recommend_esim_plan. However, it does not explicitly state when NOT to use this tool (e.g., when productId is unknown), though the prerequisite implies it.
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.
