lucky_workflow取得好運器（0523.tw）中國→台灣集運的完整工作流程：註冊、取得中國集運倉收件地址、電商下單、包裹預報、入倉、合併打包出貨、海快運送、台灣清關（簡易申報＋EZ WAY 實名認證）、新竹物流配送到府／超商取貨。內含現行費率（即時讀取）與計費規則。適合回答「集運怎麼用／流程是什麼／怎麼從淘寶買東西寄回台灣」。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | 完整結構化結果。欄位依工具而異，與 content[0].text 內附的 JSON 完全相同。 | |
| source | Yes | 資料來源，固定為 0523.tw。引用時請註明。 | |
| summary | Yes | 一行白話結論，已把關鍵數字算好，可直接引用回覆使用者；無摘要時為空字串。 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, indicating a safe, side-effect-free read. The description adds that the rates are read in real-time, which is useful behavioral context. However, it doesn't disclose the output structure or any potential delays, and the list of workflow steps is more content than behavioral transparency.
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 a single, information-dense sentence that front-loads the main purpose, lists the workflow steps in a structured sequence, and ends with usage guidance. Every clause adds value without redundancy, making it appropriately sized for a workflow overview tool.
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 no parameters, a rich output schema, and annotations indicating a safe read operation, the description provides enough context for the agent to understand when to use the tool and what it returns. It covers the full scope of the workflow, rates, and billing rules, making it complete for its intended purpose.
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 no parameters, and the input schema is empty with 100% coverage. Per the rubric, the baseline for 0 params is 4, and the description doesn't need to add parameter semantics.
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 provides the complete consolidated shipping workflow from China to Taiwan, listing the specific steps (registration, warehouse address, ordering, pre-report, warehousing, packing, shipping, customs clearance, delivery). This distinguishes it from sibling tools that cover specific aspects like freight quotes or tariff 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?
The description explicitly states it is suitable for answering questions about how the consolidated shipping process works, including how to buy from Taobao and ship to Taiwan. However, it does not explicitly mention when to use alternative tools for specific rates or declarations, though its mention of 'current rates' implies some overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.