compare_vendors
兩家廠商的同場對戰紀錄:交手幾次、各贏幾次。 兩個名稱都要是正式全名(先用 find_entity 查)。 適合回答「A 跟 B 誰比較強」「我常輸給誰」。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_a | Yes | ||
| vendor_b | Yes |
兩家廠商的同場對戰紀錄:交手幾次、各贏幾次。 兩個名稱都要是正式全名(先用 find_entity 查)。 適合回答「A 跟 B 誰比較強」「我常輸給誰」。
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_a | Yes | ||
| vendor_b | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無 annotations,描述描述主要行為(回傳交手次數、勝負數量),但未揭露輸出格式、資料來源、是否為唯讀操作或錯誤處理方式。對簡單查詢工具而言,基本行為已表達,但缺乏更深入的行為細節。
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?
三句話簡潔有力:第一句說明功能,第二句說明必要前置條件,第三句明確適用情境。每句話都有資訊價值,無冗餘,結構清晰且重點前置。
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?
考慮到工具結構簡單(兩個字串參數、無輸出 schema、無 annotations),描述已涵蓋功能、參數前置條件、適用情境。缺少回傳格式或失敗情境的說明,但對一個簡單比較工具來說整體已足夠完整。
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 參數僅有標題,無描述。描述補充了參數的重要語義:兩個名稱都必須是正式全名,且需先透過 find_entity 查詢。這對於正確使用參數有實質幫助,但未逐一說明每個參數的具體格式。
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?
描述清楚說明工具功能:比較兩家廠商對戰紀錄(交手次數、勝負),動詞「比較」搭配資源「廠商」,並與兄弟工具如 vendor_report、price_analysis 區分。明確指出適用問題類型,有助於 agent 選擇。
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?
描述明確指出使用情境(回答誰比較強、常輸給誰),且提供重要前置條件:名稱必須是正式全名,需先使用 find_entity 查詢。雖未明說何時不使用此工具,但已提供足夠的使用指引。
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 has a clearly distinct purpose: search, entity lookup, tender detail, price analysis, vendor/unit reports, head-to-head comparison, and hot opportunities. Even similar-sounding vendor_report and compare_vendors are unambiguously different in scope.
Naming is mixed: some tools use verb_noun (search_tenders, find_entity, get_tender, compare_vendors) while others use noun_noun or adjective_noun (unit_report, vendor_report, price_analysis, hot_opportunities). The style is readable and snake_case is consistent, but there is no single predictable pattern across the set.
Eight tools is a well-scoped size for a government tenders intelligence server. Each tool covers a meaningful workflow area without redundancy or bloat.
The tool surface covers the full read-only intelligence workflow: searching tenders, resolving entities, retrieving a tender's complete lifecycle, analyzing pricing, surfacing opportunities, and generating counterparty/unit/vendor reports. No obvious dead ends or major missing operations for the stated domain.