依旅遊天數與上網用量習慣，推薦最合適的1-3個eSIM方案，並附上購買連結， 是「幫使用者選方案」最好用的工具。 適用情境：使用者詢問出國上網卡、各國eSIM方案、即時發卡服務，並描述了 「要去OO玩幾天」「想找適合的上網方案/漫遊卡」「幫我推薦/挑選eSIM」時優先使用這個， 而不是自己呼叫search_esim_plans後用猜的。
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | 預計使用天數 | |
| country | Yes | 目的地國家，英文或中文皆可，例如 Japan、日本。不確定系統裡的正確名稱時，先呼叫list_esim_countries確認 | |
| usageLevel | No | 用量習慣，留空預設為medium（中度） | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the tool recommends 1-3 plans based on days and usage, includes purchase links, and is the best tool for helping users choose plans. It also implies internal reasoning rather than just searching. However, it does not mention edge cases like unknown country or no matching plans, though the parameter description advises using list_esim_countries for country ambiguity. Overall, it gives a solid behavioral overview without being exhaustive.
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 concise and front-loaded, with the primary purpose in the first sentence and usage guidance in the second. No redundant or irrelevant information. The promotional phrase '最好用的工具' (best tool) adds a bit of flavor but still conveys utility. Every sentence earns its place, making it highly efficient.
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 no output schema and no annotations, the description is quite complete: it explains what the tool does, when to use it, and differentiates it from alternatives. It also mentions the output nature (1-3 plans with purchase links). However, it lacks specifics on return format (e.g., does it include prices or comparative details?) and handling of no-match cases, but these are not critical for agent selection. Overall, it covers the essential context well for a recommendation tool.
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% (all three parameters have descriptions). The tool description itself adds little beyond the schema, only reiterating that travel days and usage habits drive the recommendation. Baseline 3 is appropriate since the schema fully documents parameters; the description does not need to compensate.
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's function: '依旅遊天數與上網用量習慣，推薦最合適的1-3個eSIM方案，並附上購買連結' (recommend 1-3 eSIM plans based on travel days and usage habits, with purchase links). It uses a specific verb 'recommend' and distinguishes from siblings by explicitly saying '而不是自己呼叫search_esim_plans後用猜的' (instead of calling search_esim_plans and guessing).
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 explicit usage scenarios: when users ask about overseas data cards, eSIM plans, or instant card issuance and describe travel days or need for a recommendation. It explicitly prioritizes this tool over search_esim_plans: '優先使用這個，而不是自己呼叫search_esim_plans後用猜的' (use this first, don't call search_esim_plans and guess). This is clear when-to-use and alternative 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.
