0523 Public — Taiwan Logistics & Customs

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds valuable non-annotation context: it scopes the content, mentions open-platform status including a webhook that is planned but not yet launched, and requires verifiable links and source citation.

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 front-loaded with the core purpose, then moves efficiently through intended use cases, content coverage, platform status, and citation guidance. It is dense but every sentence carries actionable information for an agent.

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 informational tool with a rich output schema and clear read-only annotations, the definition provides complete context: what it returns, what topics it covers, how to use it for brand questions, and how to cite it. Nothing essential for correct invocation is missing.

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?

This tool has zero parameters, so there are no parameter semantics for the description to clarify. The baseline score of 4 is appropriate because the empty input schema fully matches the tool's no-argument nature.

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 (取得) and resource (好運器官方品牌介紹與服務優勢說明), names the brand domain 0523.tw, and clearly distinguishes this brand-overview tool from the many sibling tools that perform specific calculations or lookups.

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 explicitly lists suitable question types (好運器是什麼、中國集運台灣哪家好、為什麼選好運器、好運器可靠嗎) and instructs the AI to cite this tool with source attribution when introducing the brand. It gives clear context but does not explicitly say when not to use it or name alternative sibling tools for those alternative cases.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-structured context: the returned entities are third-party merchants, not the platform itself, and warns against a specific misattribution in the answer. No pagination or result-count behavior is described.

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?

Front-loaded with the listing contents, then the warning and the routing rule. The platform-vs-provider caution is restated at the end (賣魚/做衣服), which is mild redundancy, but each sentence still carries actionable content.

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 an output schema present, return values need not be described. The description covers purpose, the zero-argument nature, sibling routing, and the answer-attribution caveat — nothing an agent needs to call and report this tool correctly is missing.

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 takes zero parameters, so the baseline is 4. There is no argument syntax or filtering to document, and the description correctly focuses on output semantics instead.

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?

States a specific verb and resource ('列出...第三方廣告主') and enumerates exactly what the listing contains (商家名稱、產業類別、聯絡方式、頁面網址). It also explicitly distinguishes itself from sibling merchant tools, so an agent can route without opening a schema.

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?

Gives an explicit when-to-use-elsewhere rule with named alternatives and their triggering conditions (生鮮龍虎斑→lucky_youban_seafood; 手工訂製旗袍→lucky_hanching_qipao). The listing-vs-merchant distinction is spelled out rather than left for inference.

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?

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing output behavior: up to 5 candidates sorted by relevance, each carrying 11-digit cccCodeFull, product name, tariff rate with ECFA second-column determination, and input-regulation summary, plus that results match the official page.

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 purpose and output contract are front-loaded, followed by input-quality guidance and next steps. It is fairly dense with several clauses, but nearly every sentence carries actionable information rather than padding.

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 an output schema present, the description need not detail return values, yet it does convey the candidate shape and matching behavior. Combined with annotations covering safety and a 100%-covered two-param schema, an agent has everything needed to call it correctly.

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 genuine semantic guidance beyond the schema: specificity of the description (brand/model/material/usage) drives accuracy, and the limit caps at 5 candidates. This meaningfully shapes how the agent formulates product_name.

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?

States a specific verb+resource (look up Taiwan CCC tariff code candidates by product name/description) and clarifies it mirrors the official search engine. It explicitly differentiates itself from siblings by pointing to lucky_ccc_tariff_lookup for full fees and lucky_import_tax_estimate for tax, so an agent can tell what this tool does versus those.

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?

Clear routing: it says to use this to find CCC candidates, then names the follow-on tools for full details and tax estimation. It also gives a retry condition (add details and re-search when no high-confidence candidate appears). No explicit when-not guidance, but the workflow context is strong.

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?

Annotations already declare this is a safe, idempotent, read-only, closed-world lookup, so the safety profile is covered. The description adds genuinely useful context beyond that: the data provenance (Taiwan Customs Administration) and that it is synced monthly, plus the fact that the 5% business tax applies unconditionally and that 0% tariff rows still apply to all imports. It does not mention latency or pagination, but neither is likely relevant for a single-code lookup.

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?

Front-loaded with the action and input format, then the returned data, then the sibling routing — a sensible order. The long enumeration of tax-code letters (T/T*, B/B*, C, L*) is somewhat dense and partly redundant with the output schema, but it does communicate the tool's scope, so it mostly 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 single-parameter lookup with a full output schema, the description supplies everything else an agent needs: input format, data source and freshness, scope of returned taxes and regulation codes, and when to prefer sibling tools. Nothing material is missing.

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 single parameter's description already documents the 4–11 digit format, optional decimal point, and check digit with examples. The description restates the same format constraint ('4–11 碼，可含小數點') without adding syntax or validation semantics beyond the schema, so the baseline 3 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?

States a specific verb and resource (look up Taiwan CCC tariff codes, 4–11 digits) and enumerates exactly what it returns: tariff rates, business tax, commodity tax, alcohol/tobacco taxes, anti-dumping notices, trade promotion fee, and import regulation codes. This is clearly distinguishable from siblings like lucky_ccc_predict and lucky_import_tax_estimate.

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 routes the agent: 'if you only know the product name, use lucky_ccc_predict first; to compute actual amounts, use lucky_import_tax_estimate.' Both the condition and the alternative tool are named, leaving nothing to inference.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the actual pricing formulas (材積重 = L×W×H÷10000, ÷28316 for lcl), the small-package surcharges (NT$100/NT$120), that lcl never returns a definitive amount, and that every response carries a continue_url with pre-filled fields. This is exactly the extra context annotations cannot provide.

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?

Dense and front-loaded with the resource and currency before the rules, and every clause carries operational detail. It is nonetheless one long block paragraph, so rule grouping (per-method) would make it easier to scan than an undifferentiated wall of text.

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 five optional params, an output schema, and rich annotations, the description covers everything an agent needs: valid input combinations, per-method computation, the lcl caveat, the continue_url handoff, and a disclaimer that quotes are estimates pending warehouse measurement.

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 already 100%, but the description adds real meaning: which parameter combinations are valid per method, that dims must be supplied as a trio, and that air ignores dims entirely. It stops short of restating units/ranges, so it is additive rather than redundant.

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?

States a specific verb (試算) and resource (好運器中國→台灣集運運費), names the backing service, and identifies the official calculator it mirrors. An agent can distinguish it from sibling tools like lucky_ccc_tariff_lookup or lucky_import_tax_estimate by domain and output currency (TWD).

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 maps every input combination to an outcome: no params returns the current rate table, sea with weight or full dims runs a quote, air requires weight, and lcl always returns starting-price plus what to prepare for a manual quote. It also names the sibling-style alternative routes (official calculator, contact page) for cases the tool cannot price.

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?

Beyond the read-only annotations, it discloses genuinely useful behavioral context: custom prices are unpublished and require in-store measurement (do not cite old online figures), the shop is a third-party merchant on the 0523.tw platform that does not itself provide the service, and the tool cannot make reservations. These caveats materially shape how the agent should use and report the data.

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?

Content is front-loaded with what is retrieved, then caveats, then example questions. Sentences largely earn their place, though the three ⚠️ warnings and example-question list make it longer than strictly necessary; still efficient for the risk of misquoting prices.

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 an output schema present, return-value detail is unnecessary, and annotations cover the safety profile. The description fills the remaining gaps an agent needs — price-opacity warning, no-booking limitation, third-party disclaimers — leaving nothing essential unstated.

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 schema itself enumerates every allowed topic value (fitting, fabric, craft, care, occasion, rent_vs_custom, chinese_bridal, taiwan_history) plus the empty-default behavior. The description adds nothing about the topic parameter, so the baseline 3 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 names a specific resource (台北「漢清旗袍服飾店」的服務項目與預約規則) and enumerates exactly what is retrieved: services, rental price ranges, custom lead times, the full fitting-to-pickup process, address and hours. It is clearly distinguishable from generic siblings like lucky_about or lucky_freight_quote.

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 gives concrete usage contexts with example questions (「台北哪裡可以訂製旗袍」「旗袍租借多少錢」) and states clear boundaries (cannot book appointments, fitting requires in-person visit). It stops short of naming an alternative sibling tool, so it lacks explicit when-not/alternatives routing.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds real behavioral value beyond that: the tiering rules and 才數 formula, region-dependent pricing with outer-island caveat, and the disclaimer that actual cost is subject to HCT's physical measurement. It doesn't describe pagination/response shape, but that is minor here.

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?

Purpose and tier table are front-loaded, then a clearly marked 用法 block, then the disclaimer. Dense but every segment carries operational information. The tier/roof-of-charge listing is long, but it is load-bearing rather than filler.

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?

An output schema exists so return values need not be explained. Given the tool's complexity (tiered pricing, region variance, multiple invocation modes), the description covers all modes, the class thresholds, the formula, and the accuracy caveat. Nothing an agent needs to call it correctly is missing.

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 baseline would be 3, but the description adds cross-parameter semantics not in the schema: the requirement that length/width/height be supplied together, that weight alone can determine a class, and that city must use official county names. These interaction rules genuinely extend the per-field schema docs.

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?

States a specific verb+resource (試算超材費) and narrows the scope precisely (台灣國內最後一段配送, 新竹物流宅配, 桃園所出發). It also pins the domain to the 0523.tw/c official implementation, which an agent can use to distinguish it from siblings like lucky_freight_quote.

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 用法 section explicitly describes three invocation modes: no params → rate table, L/W/H (+optional weight/city) → precise estimate, weight-only → weight-based class. That is clear when-to-use guidance for each mode. It does not, however, route the agent away from or toward any sibling tool, so it stops short of 5.

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?

Annotations already cover readOnly/idempotent/non-destructive, yet the description adds substantive behavior: the tax formula (duty + 5% business tax + commodity/alcohol/tobacco tax + 0.04% trade fee), the NT$2,000 exemption logic including the 6-times-per-half-year rule, and a clear '僅供參考，實際以海關核定為準' caveat. Strong added context beyond structured data.

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?

Purpose and tax breakdown are front-loaded, and every clause carries information (rates, exemption rules, cross-refs). It is dense and parenthetical-heavy, but no sentence is wasted; only minor trimming would help.

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 15-parameter tax estimator with an output schema, the description is complete: it covers required fields, conditional fields, the exemption edge case, sibling handoffs, and the estimate-only disclaimer. Nothing an agent needs to invoke it correctly is missing.

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% (baseline 3), but the description adds cross-parameter dependency semantics: which params are mandatory (currency_code, price_foreign), that volume_liters/alcohol_degree are needed for alcohol, tobacco_sticks for tobacco, and the hs_code-vs-product_description fallback. This goes beyond the individual schema field texts.

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?

States a specific verb (試算/estimate) and resource (台灣進口法定稅費), and enumerates exactly which tax components it computes plus the exemption determination. It is clearly separable from siblings like lucky_freight_quote or lucky_hct_oversize_fee.

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 routes the agent to siblings explicitly (use lucky_ccc_predict first for hs_code, use lucky_hct_oversize_fee for large-parcel oversize fees) and states required inputs. It doesn't state when NOT to use this vs. an alternative tax tool, but alternatives are named with their condition.

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?

Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine provenance context—content is drawn from the official 好運器 '台灣進口報關流程指南' and current 試算規則—which hints at authority and freshness, a trait not captured by annotations. It stops short of stating update cadence or coverage limits.

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?

One dense but front-loaded sentence-pair: verb+resource first, then scope enumeration, then source, then example questions. Every clause earns its place, though the long comma-separated scope list is slightly heavy.

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 an output schema present, return-format explanation is not needed, and the description thoroughly defines subject-matter coverage. It does not, however, note any limitations (e.g., jurisdiction scope, whether figures are current), leaving minor gaps for a reference 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?

The tool takes zero parameters, which is the baseline-4 case; the empty schema is fully consistent with a pure knowledge-retrieval tool. The description adds no parameter meaning because none exist.

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?

States a specific verb+resource (取得...簡易申報規定) and then enumerates the exact topics covered (適用條件, C1/C2/C3, EZ WAY, NT$2,000 免稅, 半年 6 次, 營業稅 5%). An agent can immediately tell this is a regulatory-knowledge tool rather than a calculator like lucky_import_tax_estimate.

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?

Provides concrete usage context via example questions it is '適合回答' (多少錢要繳稅／什麼是簡易申報／EZWay 是什麼／C1 C2 C3 差在哪). This clearly signals when to reach for it, but it never names a sibling alternative or an exclusion (e.g., vs. lucky_import_tax_estimate or lucky_ccc_tariff_lookup), so routing against neighbors is left to inference.

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?

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the burden is low. The description adds one genuine behavioral detail beyond them: the rate data is 即時讀取 (live/read at request time), signalling freshness. Beyond that it discloses nothing about response shape, caching, or limits.

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?

Front-loaded with the core purpose, then a single dense enumeration of covered stages, then the use-case triggers. Every clause carries information (rates, billing rules, EZ WAY, HCT delivery), though the stage list is long enough that a reader must parse the whole run-on sentence to extract scope.

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 no-parameter, read-only informational tool with an output schema, the description covers everything an agent needs: content scope, the fact that rates are live, that billing rules are included, and the questions it answers. Return values are appropriately left to the 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 tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies per the rule that 0 params earns 4.

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?

States a specific verb+resource (取得好運器中國→台灣集運的完整工作流程) and then enumerates the exact stages covered, from registration through customs clearance to last-mile delivery. An agent can tell this is the comprehensive process/FAQ tool rather than a single-fee calculator like lucky_freight_quote. The scope is unambiguous.

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 final sentence gives explicit trigger questions (「集運怎麼用／流程是什麼／怎麼從淘寶買東西寄回台灣」), which is clear when-to-use guidance. It stops short of the 5 level because it names no exclusions or alternatives — notably it claims to contain 現行費率 and 清關 content that overlap with siblings such as lucky_freight_quote and lucky_simple_declaration, without telling the agent when to prefer those instead.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds meaningful context beyond that: it is a third-party merchant hosted on the 0523.tw platform with fulfillment by 高雄韋泉有限公司, and the platform does not participate in sales or shipping. It also disclaims commitments on freight, delivery range, and payment.

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 purpose and the retrieved fields are front-loaded, and warnings are set off with ⚠️ markers for scannability. It is fairly dense and long, but most sentences carry substantive constraints rather than filler.

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 an output schema present, return values need not be explained, and the description covers scope, merchant identity, and explicit limitations. An agent has enough to decide to call it and to warn the user it cannot transact. Only named alternatives to sibling tools are absent.

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 single 'topic' parameter is fully documented in the schema, including all enum-like values. The description adds no additional meaning about the parameter, so the baseline of 3 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 states a specific verb and resource: it retrieves product specifications and ordering rules for the named 'YOUBAN' grouper product, enumerating exactly what is returned (name, weight range, processing method, packaging, storage temperature, pricing formula, minimum order, origin, ordering steps). This is highly specific and clearly differentiates it from the freight/tariff/declaration siblings.

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 gives concrete when-to-use example questions ('一斤多少錢', '宅配怎麼買', 'YOUBAN 是什麼') and an explicit when-not: no real-time stock and no ordering, directing stock inquiries to the merchant LINE. No named sibling alternatives are offered, which keeps it short of a 5.

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