get_tender
單一標案的完整歷程:招標→決標的每則公告、預算與決標金額、 得標廠商、競爭態勢(幾家投標/是否單一投標)、是否為續約案。 unit_id 與 job_number 來自 search_tenders 的結果列。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | Yes |
單一標案的完整歷程:招標→決標的每則公告、預算與決標金額、 得標廠商、競爭態勢(幾家投標/是否單一投標)、是否為續約案。 unit_id 與 job_number 來自 search_tenders 的結果列。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | 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,但代理能理解呼叫後可期待的結果;缺乏疑難排除或額外限制,但整體已足夠導引正確使用。
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 對參數的描述覆蓋率為 0%,描述僅說明 unit_id 與 job_number 來自 search_tenders 的結果列,未實際定義每個參數的語意或格式,無法充分補償 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?
描述明確指出工具是取得「單一標案的完整歷程」,並列出具體包含的內容(每則公告、金額、得標廠商、競爭態勢、續約與否),動詞與資源清楚,且與兄弟工具 search_tenders(搜尋)明顯區隔。
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?
描述說明參數來源來自 search_tenders 的結果列,隱含應在搜尋後使用,但未明確說明何時不該用或相對於其他兄弟工具的選擇條件,僅屬暗示層級。
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.