ONE HEART eSIM

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses real-world effects (writing a formal order, connecting to real payment flow), failure modes (ok=false may mean order created but payment link failed, do not retry), and required user communication (provide paymentUrl as-is, remind order won't ship until payment). This goes far beyond basic mutation disclosure.

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 structured with a clear opening statement, numbered prerequisites, and explicit post-conditions. Though longer than average, every sentence provides necessary safety or correctness information for a high-stakes financial action, and the content is front-loaded with the core purpose.

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 the tool's complexity (7 parameters, real money, no annotations, no output schema), this description covers prerequisites, parameter validation, return handling (paymentUrl, ok/error), and user-facing instructions. It leaves no critical gaps for safe invocation.

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?

Although schema already covers all 7 parameters (100% coverage), the description adds crucial constraints: productId and spec must come from query tools, quantity must match user confirmation, email/userName are mandatory, paymentMethod should be explicitly asked rather than defaulted. This enriches parameter semantics beyond the schema.

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 creates a real eSIM order and returns a payment link (LinePay or ECPay). It explicitly distinguishes itself from the sibling read/search tools and emphasizes this is a real transaction, not a simulation.

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?

It provides explicit prerequisites referencing sibling tools (search_esim_plans/recommend_esim_plan/get_esim_plan_detail), mandates user confirmation and informed consent, and specifies when it should not be used (not for simulation/estimation). This gives clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose safety and side effects. It says it returns multiple results for comparison, but it does not explicitly state that it is read-only, free of side effects, or mention any rate limits or error behavior. The read-only nature is implied by 'search' but not explicitly declared, which is a notable gap given the full burden is on the description.

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 one-sentence purpose, then a conditional usage guideline, then a clear alternative reference. It is front-loaded with the core function and contains no filler or redundancy. Every sentence contributes value.

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 4 optional parameters and no output schema, the description explains that multiple results are returned and differentiates from the recommendation tool. However, it does not describe the structure of the returned results or point to 'get_esim_plan_detail' for deeper information, which is a minor but relevant gap for a tool without an explicit output schema.

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 input schema has 100% description coverage, with detailed parameter descriptions including defaults and cross-tool guidance. The main description only mentions 'country, plan type, keyword' without adding new semantic meaning beyond the schema. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 uses a specific verb 'search' with a clear resource ('eSIM product list') and explicitly lists filtering dimensions (country, plan type, keyword). It also distinguishes itself from 'recommend_esim_plan' by contrasting browsing/comparing vs. getting a scoring-based recommendation, which differentiates it from a key sibling.

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?

Explicitly states when to use (browse/compare multiple plans or when user specifies a plan type) and when not to use (travel scenario where the user needs a direct recommendation), naming the alternative 'recommend_esim_plan'. Also, the country parameter description suggests calling 'list_esim_countries' when uncertain, providing additional guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.