還沒決標的案子：投標行情與對手習慣。回答「這類案子通常成交在預算的幾成」「主要對手習慣報多少」「勝負在價格還是評選」。 最低標：參考案得標價占預算的 10%／中位數／90% 分位、主要對手近 3 年同類最低標的報價中位數（附樣本數）、 這個機關同類案過去平均幾家投標、預估底價與偏低門檻（施行細則第 79 條：低於底價 80% 機關可要求說明或擔保）。 最有利標：得標價中位數、報價最低的廠商有幾成拿到案子（通常不到一半，勝負在評選）。 不提供勝率或建議報價（回測顯示估計不穩、還輸給簡單規則）；回答時用行情區間與對手習慣說明，提醒使用者依自身成本評估。 unit_id 與 job_number 來自 search_tenders 的結果列；已決標的案子改用 get_tender。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It excels by explicitly declaring what the tool will NOT do – '不提供勝率或建議報價' (does not provide win rate or suggested quotes) – and justifying it with the backtesting rationale (estimates unstable, lose to simple rules). It also describes the data it will surface (medians, percentiles, sample sizes, bottom-price threshold per Implementation Rules Article 79). It stops short of mentioning authentication, rate limits, or a precise return format, earning a 4 rather than a 5.
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 long but densely informative and well-organized: scope and questions first, then two clear data sections (最低標 and 最有利標), then the limitation disclaimer, then the parameter-source note. The length is justified by the tool's branched logic (lowest-bid vs most-advantageous-bid). Nothing reads as filler; every sentence carries functional value. It loses one point only because it could front-load the 'no win rate/quote' disclaimer slightly earlier, though it is already close to the middle.
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 output schema and no annotations, the description reasonably covers scope, the two analysis modes, the data the reply will contain (行情區間, medians, sample counts, competitor habits), the tool's stated limitation, and parameter provenance. It does not explicitly describe the response envelope (e.g., possible fields or format), but for an analysis/consulting tool the content of the answer is well implied. The only gap is a lack of explicit return-format or error-condition notes, which are minor for this 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?
Schema description coverage is 0%, so the description must compensate. It does add one meaningful linkage – that unit_id and job_number come from the result rows of search_tenders, giving an agent a retrieval path for both required inputs. However, it does not define what each parameter represents within the tool (e.g., what a unit is, what job_number references), and the schema titles ('Unit Id', 'Job Number') provide almost no semantic signal. The search_tenders provenance is useful but leaves each parameter's meaning under-specified.
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 opens by bounding the scope ('尚未決標的案子' – not-yet-awarded cases) and states a specific resource (投標行情與對手習慣, bid market conditions and competitor habits) plus the specific questions it answers (typical closing percentage of budget, competitor quote habits, whether outcome hinges on price or evaluation). It clearly differentiates from siblings: get_tender is for awarded cases and search_tenders is the lookup, while this is the strategy analysis for pending ones. The verb–resource–scope combination is precise and distinguishes it without opening any 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?
The description explicitly states the use condition (not-yet-awarded cases), names the alternative tool for the opposite case ('已決標的案子改用 get_tender'), and instructs where the input parameters come from ('unit_id 與 job_number 來自 search_tenders 的結果列'). This is an explicit when/when-not/alternative routing with no ambiguity left to inference.
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.