Taiwan government tenders: 14M+ notices, vendor/agency intel, forecasts, committees, debarment list.
Scored across 20 tools
Most tools have distinct purposes (search, entity resolution, vendor analysis, committee lookup, etc.), but there is some overlap among vendor-related tools (vendor_awards, vendor_report, vendor_committee, vendor_compliance) and committee tools (committee_member, search_committee_members, unit_committee, evaluation_committee) that could cause misselection without careful reading.
Tool names generally follow a clear noun-based or verb_noun pattern (search_tenders, get_tender, find_entity, vendor_report, unit_report). A few names are noun phrases (hot_opportunities, public_reading, price_analysis) rather than verb-led, but the pattern is still predictable and readable.
20 tools is on the higher end but appropriate for a domain covering tenders, vendors, committees, contracts, and forecasting. Each tool addresses a distinct workflow, though a few could be consolidated (e.g., committee-related tools).
The tool set covers the full tender lifecycle (search, detail, forecast, public reading, awards, subcontracting, price analysis) plus vendor intelligence, committee analysis, and compliance records. It is remarkably comprehensive for the stated domain, with no obvious dead ends.
公家機關財物變賣（kind=sell）或出租（kind=rent）公告：車輛、設備、廢料、場地、攤位等； 以及國有財產署（國產署）的國有土地標租（kind=nps_rent）與標售（kind=nps_sale）——這兩類不在政府電子採購網。 q 篩財物名稱或機關（國產署類：地號、縣市、鄉鎮、使用分區、租約類別）；語法：空白＝且、OR＝或、-詞＝排除，台／臺互通。 open_only 只列還沒截止／還沒開標的，設 False 時國產署類會改列開標結果（得標金額、超出底價％、投標數）。 open_only 查到 0 筆時會自動附上近期已結束的：一般財物附 recently_closed（最近 90 天截止的，沒有再放寬到一年， status＝已截止）；國產署附 recent_results（最近的開標結果，含得標金額）。可看行情與哪些機關常釋出，下一批通常類似。 回傳公告日、截止日或開標日、底價、保證金、面積、標的所在地與官網連結。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| kind | No | sell | |
| limit | No | ||
| open_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses the open_only fallback behavior (auto-attaching recently_closed/recent_results), the status values, the different behavior for general assets vs nps categories, and the returned fields. No contradictions exist.
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 every sentence carries distinct information: purpose, category distinctions, query syntax, open_only behavior, fallback semantics, and return fields. It is organized with line breaks and structured content rather than redundant prose.
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?
Despite having no output schema and no annotations, the description explains what the tool returns, how filtering works, what each category means, and the important fallback behavior. An agent has enough information to select and invoke the tool correctly for both general asset sales and nps land cases.
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 0%, so the description must explain the parameters, and it does for q, kind, and open_only, including exact kind values and q syntax. The limit parameter is not mentioned at all, which prevents a 5, but the covered parameters receive far more meaning than the schema alone provides.
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 verb and resource: it lists public-agency asset sale/rent announcements and National Property Administration land lease/sale notices. It also enumerates the asset categories (vehicles, equipment, scrap, land, stalls) and explicitly separates these from government e-procurement, so an agent can distinguish this tool from procurement-focused 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 clear operational guidance: when to use open_only, how the False setting changes results, and that nps_* categories are not covered by government e-procurement. It does not explicitly name sibling tools as alternatives or state when not to use this tool, but the context is strong enough for an agent to infer appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
採購評選委員個人紀錄：評選案數、資料期間、現職版本、常評選的機關、類別比例、 常一起出現的委員、評選案的得標廠商彙整、決標／預算比（基準為全部評選案）與最近案件。 姓名要完整；不確定時先用 search_committee_members。回答時請附合議制聲明。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It discloses the scope of the record, clarifies that the award/budget ratio is based on all evaluation cases, lists the returned data facets, and requires a disclaimer. It does not mention not-found behavior or read-only status, but the disclosed scope is strong for a profile lookup tool.
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 compact and front-loaded with the resource type, followed by a tight list of contents and two necessary operational instructions. There is no repetition or 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?
For a one-parameter lookup with no output schema and no annotations, the description is nearly complete: it covers input requirements, output scope, metric basis, and response behavior. The only minor gaps are handling of missing records and exact output formatting.
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 input schema has one 'name' string parameter with no schema-level description. The tool description compensates by stating the name must be complete and instructing the agent to first use search_committee_members when uncertain, giving the parameter meaningful operational semantics beyond the bare 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?
The description clearly identifies a specific resource—採購評選委員個人紀錄 for an individual committee member—and enumerates exact contents such as case counts, date range, current position, agencies, category ratios, co-appearing members, vendor summaries, and award/budget ratio. It also differentiates this from search_committee_members by instructing that name lookup should happen first if uncertain.
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 gives explicit usage guidance: the name must be complete, and search_committee_members should be used first when the name is uncertain. It also specifies that the answer must include the collegial-system disclaimer, which is a concrete output requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
兩家廠商的同場對戰紀錄：交手幾次、各贏幾次。 兩個名稱都要是正式全名（先用 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.
某一案的採購評選委員名單（機關公開者）：姓名、現職、與本案相關學經歷。 未公開時回傳機關的說明。回答時請附上合議制聲明。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it discloses key conditions: only publicly disclosed committee members are returned, and if not public, the agency's explanation is returned. It also instructs the agent to include a collegiate-system statement; this exceeds what the schema alone would reveal, though error cases and permissions are not covered.
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 three short, front-loaded sentences with no filler. It covers the main content, the fallback behavior, and the output instruction, so every sentence 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 tool with no output schema and no annotations, the description adequately covers the returned data and the public-disclosure fallback. It is incomplete, however, because it does not define the two required parameters and does not distinguish this tool from the many committee-related siblings, so an agent could still select the wrong tool or pass malformed identifiers.
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, but it never explains what unit_id and job_number mean, what formats they take, or how they identify the case. The description only hints at '案' and '機關', leaving parameter interpretation to inference from the parameter names.
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 identifies the specific resource ('某一案的採購評選委員名單') and the fields returned (姓名、現職、學經歷), which makes the core purpose clear. It loses one point because it does not explicitly differentiate itself from overlapping siblings such as search_committee_members or committee_member.
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 phrase '某一案' plus the required unit_id and job_number implies the tool is for retrieving a specific case's committee list. However, there is no explicit guidance about when to prefer this tool over the many committee-related siblings, and no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用不完整的名稱找機關或廠商的正式名稱與代碼。 例：輸入「台電」找台灣電力公司相關、「北市府」找臺北市政府相關。 vendor_report / unit_report / compare_vendors 需要正式名稱，先用這個查。
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior — fuzzy/incomplete-name matching and returning official name plus code — but does not disclose result-set behavior (single vs multiple matches), failure behavior when no match is found, or any matching constraints. Adequate but with gaps.
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?
Three compact sentences with no waste: purpose is front-loaded, examples follow, and usage guidance closes. Each sentence earns its place and the overall length is appropriate for the tool's simplicity.
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 tool with no output schema and no annotations, the description is nearly complete: it states purpose, parameter semantics via examples, return content (official name and code), and pre-conditions for related tools. Only edge-case behavior (no match, multiple matches) is unaddressed.
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 0% and the parameter is only titled 'Q', so the description must compensate. It does so via examples like '輸入「台電」找台灣電力公司相關', clarifying that q is an incomplete name fragment of an agency or vendor. This meaningfully fills the schema gap, though it stops short of specifying format constraints.
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: '用不完整的名稱找機關或廠商的正式名稱與代碼' (use incomplete names to find official names and codes of agencies/vendors), with concrete examples. This makes clear it is a name-resolution/lookup tool and distinguishes it from siblings like search_tenders (tender search) and vendor_report (report generation).
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 says 'vendor_report / unit_report / compare_vendors 需要正式名稱，先用這個查' — telling the agent to use this tool first when those siblings need an official name but only an incomplete one is available. This names the dependent alternatives and provides clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
共同供應契約：機關不用另外招標、可直接下單的品項與廠商。 mode="awards"（預設）：共契決標公告，一案一列，附品項（名稱、決標金額）與得標廠商；q 逐詞比對案名、機關、品項、廠商， vendor 給廠商正式全名，year 西元或民國年。 mode="catalog"：現行共契品項目錄（工程會開放資料，限具環保標章品項），一列一個品項×廠牌型號×立約商，涵蓋台銀集中採購的 電腦主機、螢幕、印表機、耗材、投影機、冷氣、影印機租賃等 18 個契約與各醫院衛材藥品（附決標單價）；筆電、軟體等不在內。 q 比對品項、型號、廠商、分類，vendor 可給統編。 mode="series"：契約系列——同一機關同一系列（如台銀「電腦設備用品」）的歷期歸在一起，回每系列期數、慣例決標月份、 最近一期金額與得標家數、下一期預估年月（依歷期間隔推算）；q 比對系列名／機關，vendor 不適用。 mode="series_detail"：某一系列的每期明細與立約商進出（新進／退出／連續在榜），q 給系列名、unit_id 給機關代碼（從 series 結果取）。 mode="vendor"：一家廠商的共契版圖——歷年共契決標、現行目錄裡的品項數／分類／廠牌、同品項的競爭者；vendor 給正式全名。 問「某型號／某類商品共契由哪些廠商供應」用 catalog；問「哪家廠商拿過共契、金額多少」用 awards； 問「這個共契多久招一次、下一輪大概什麼時候、誰進誰出」用 series／series_detail。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| mode | No | awards | |
| page | No | ||
| year | No | ||
| limit | No | ||
| vendor | No | ||
| unit_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses data source (工程會開放資料), scope limitation (限具環保標章品項), exclusions, per-mode output contents, matching logic for q, and how parameters like vendor and unit_id are interpreted in each mode.
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 the tool has five distinct modes and no schema/description coverage. Every block earns its place: the opening sentence frames the domain, each mode block adds required behavior, and the closing routing sentence converts user intent into mode selection without 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?
Given the tool's complexity, the absence of annotations, a 0%-coverage schema, and no output schema, the description is remarkably complete. An agent can determine which mode to call, which parameters to supply, what data to expect back, and what is deliberately out of scope.
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 0%, so the description must compensate. It richly explains mode, q, vendor, year, and unit_id semantics. The only gap is page and limit, which appear only as numeric defaults with no explanation of pagination behavior or limits.
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 defines the resource: Taiwan's 共同供應契約 (framework contracts) for direct government ordering without separate tendering. It further breaks the tool into five explicit modes, each with a distinct resource scope (award announcements, current catalog, contract series, series details, vendor landscape), so there is no practical ambiguity with sibling tools.
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 routing paragraph gives explicit when-to-use instructions: '問某型號／某類商品共契由哪些廠商供應' → catalog, '哪家廠商拿過共契、金額多少' → awards, and duration/entrant questions → series/series_detail. It also states exclusions such as laptops/software not in catalog and vendor being inapplicable in series mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
單一標案的完整歷程：招標→決標的每則公告、預算與決標金額、得標廠商、 競爭態勢（幾家投標／是否單一投標）、是否為續約案、政府電子採購網的 招標文件領取頁與公告詳細內容頁網址，以及開標實況——決標公告揭露的 每一家投標廠商、各自標價、底價、未得標原因。 開標實況是別處查不到的：可以看出出價最低的為什麼沒得標。 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?
With no annotations provided, the description carries the full behavioral burden. It discloses the data-source dependency (inputs from search_tenders), adds an availability caveat (bid-opening details as disclosed in the award announcement), and explains analytical value (seeing why the lowest bidder lost). It stops short of a 5 because it does not state edge-case behavior such as what happens when a tender is not found or when bid-opening details are absent.
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 is front-loaded in the first phrase, followed by a logical flow: what is returned, why it matters, then where the inputs come from. The content enumeration is dense but earned. The unique-value pitch ('開標實況是別處查不到的...可以看出出價最低的為什麼沒得標') is slightly redundant with the earlier mention but serves a distinct routing purpose.
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 simple 2-parameter lookup with no output schema and no annotations, the description carries the full burden of explaining expected returns, and it does so thoroughly: it enumerates the announcement history, amounts, vendor, competition, renewal status, URLs, and bid-opening records. The main gap is edge-case behavior (missing tender, undisclosed bid-opening data), which keeps it from a 5.
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 by telling the agent where both parameters come from (unit_id and job_number from search_tenders result rows), which is the key semantic needed to construct a correct call. The parameter names themselves are self-explanatory. It doesn't provide format constraints, but the provenance note largely makes up for the absent schema descriptions.
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-resource combination: retrieving a single tender's complete history (單一標案的完整歷程), and enumerates the returned content in detail (announcements, budget/award amounts, winning vendor, competitive landscape, bid-opening details). It differentiates from siblings by explicitly claiming the bid-opening details (開標實況) cannot be found elsewhere, and by positioning search_tenders as the source of its inputs.
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 gives clear workflow context: unit_id and job_number come from search_tenders result rows, telling the agent this tool is the follow-up detail lookup after a search. It also states a de-facto exclusion, that bid-opening details exist nowhere else. However, it never names an alternative explicitly or states when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
流標機會：反覆流標、至今未決標的案子——競爭者少、機關急著發包， 是新廠商切入的好標的。回傳最新 10 筆。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無任何 annotation，描述承擔全部行為揭露責任。描述說“回傳最新 10 筆”，透露了輸出數量限制，但未提及權限要求、只讀性、或返回欄位格式。作為一個具抓取操作（僅回傳）的工具，缺少對響應結構或異常行為的明確描述，但並未與任何註記矛盾。
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?
描述簡潔精簡，用一句話概括功能（回傳樣態與目的），並加上“回傳最新 10 筆”的行為關鍵數據，無多餘字詞，開頭即點明主題，結構良好。
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，且屬簡易列表回傳，描述提供了“最新 10 筆”這個數量限制，足以讓代理了解基本行為。但未指明回傳欄位（如投標編號、機關名稱等），雖然沒有輸出 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?
該工具沒有參數（參數數為0），schema 欄位說明覆蓋率為100%，因此描述無需補充參數語義。依規則，當無參數時基準分為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?
描述明确说明工具返回的是“流標機會”——反复流标、至今未決標的案子，動詞“回傳”清楚指向操作，資源名稱與內容相呼應。它與兄弟工具（search_tenders、get_tender）有明確區隔，因為它聚焦於特定狀態（流標）且無需參數。
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.
底價分析：這個案子大概會以多少錢成交。 依歷史「決標／預算比」給三檔出價建議（保守／典型／積極）， 比較基準依樣本充足度自動選：相似案（標題關鍵詞比對）＞同機關＞同細類＞同大類＞全庫。 另外回傳 reserve：從已決標案子回推的真實底價分布——機關把底價訂在預算的幾成、 決標價又落在底價的幾成。底價在開標前保密，這是同類已決標案的統計， 依決標方式分開（評選類的價格由機關訂定，決標價通常等於底價）。 適合在使用者問「這案該報多少」「值不值得投」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| unit_id | Yes | ||
| job_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly explains the methodology (using historical data, selecting comparison basis by sample sufficiency), and explicitly notes that the reserve price is confidential before opening, but this is a statistical estimate from similar awarded cases. It also clarifies that the analysis varies by tender type (evaluation vs. lowest price). This is rich behavioral context that goes beyond a simple tool description.
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 quite long, but it is information-dense and well-structured. It starts with a clear summary, then explains the methodology, the reserve calculation, the comparison basis logic, and ends with usage guidance. It is appropriately front-loaded with the core purpose. The main slight deduction is for being somewhat verbose, but each sentence adds value, so it is not overly wasteful.
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?
The description is comprehensive for a tool with no output schema and no annotations. It specifies inputs (implicitly), explains the algorithmic approach, highlights the key output (reserve distribution), and addresses confidentiality nuances. It even gives the intended use case. There is no missing critical information for an agent to decide whether to invoke it and understand its behavior.
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 0% as per context signals, and the schema only provides field names ('unit_id', 'job_number') with no descriptions. The description does not explicitly explain what each parameter means, but it does reference '案子' (case) and the tool name implies it analyzes a specific case, so likely 'job_number' identifies the case and 'unit_id' the unit. However, the description does not provide explicit mapping, so it is not a perfect score. Given low coverage, the description compensates by giving context that these two parameters are needed for a specific case, but does not detail syntax or format.
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 purpose: analyzing the bottom price of a procurement case and providing three bid suggestions. It uses specific terms like '決標/預算比' and '底價分析' that are distinct from sibling tools. It also explains the output includes a reserve price distribution, which differentiates it from other analytical tools.
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 when to use this tool: when users ask 'this case should bid how much' or 'is it worth bidding'. It implies not for other types of analysis, and differentiates from siblings by focusing on price and reserve, not vendor comparison or committee info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
採購預告：機關在正式招標前公布的「幾月要招、預算多少」，通常早 1～3 個月， 是唯一能搶在公告前準備的來源。q 篩標案名稱或機關（空白＝且，台／臺互通），unit 給機關代碼（含下級機關）。 注意：官網只公布未來 1～3 個月的預告，全庫通常只有一百多件，很多主題本來就沒有。 官方預告 0 筆時，會自動改回傳 recurring_estimates：同一機關每年重複發包的案子（出現 3 年以上）， 依歷年招標月份推估下次約在哪個月——這是推估、不是官方預告，引用時請講清楚。 include_past=True 連已經到期的舊預告一起列。 回傳預定招標年月、預定預算、招標方式、履約地點與官網連結。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| unit | No | ||
| limit | No | ||
| include_past | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it explains the 1–3 month official window, the small dataset size, the automatic fallback to recurring_estimates, the fact that recurring_estimates are estimates and not official forecasts, and the effect of include_past=True. This is rich, honest behavioral context.
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 dense but front-loaded with the core purpose, then filters, limitations, fallback behavior, and return fields. A small redundancy exists between '通常早 1～3 個月' in the first sentence and the later warning that the official site only publishes forecasts 1–3 months out, but overall every sentence adds useful information.
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 there is no output schema, no annotations, and four parameters, the description is unusually complete: it lists the returned fields, explains the non-official fallback clearly, covers the main parameter semantics, and sets expectations about data availability. An agent has enough detail to select and invoke this tool 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 description coverage is 0%, so the description must compensate. It does for q, unit, and include_past, adding meaningful semantics like q matching tender name or agency, 台/臺 equivalence, unit being an agency code including subordinates, and include_past listing expired forecasts. However, the limit parameter is not mentioned in the description, so one of four parameters relies solely on the 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?
The description clearly identifies the tool as a procurement forecast (採購預告) published 1–3 months before tender, and immediately states it is the only source that lets users prepare before an official announcement. This differentiates it from siblings like search_tenders and get_tender, which cover already-announced 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?
It explicitly says this is the unique pre-announcement source, explains q and unit usage, and warns that the official site only publishes 1–3 months ahead and that many subjects have no forecast at all. It also describes what happens when official forecasts are absent (automatic fallback to recurring_estimates), giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
公開閱覽：招標文件草案公開徵求廠商意見的案件，廠商可在意見截止日前向機關提出規格或資格意見。 預設只列「閱覽期內」的案（通常只有幾十件）；include_closed=True 連閱覽期已過的一起列（有三千多件，適合看某類案的規格草案）。 閱覽期內 0 筆時，會自動附上 recently_closed：最近 90 天內已結束的同類公開閱覽（已截止、不能再提意見）， 可以看這類案有哪些機關在辦、規格草案長怎樣，通常不久後就會正式招標。 q 篩標案或機關（空白＝且，台／臺互通），unit 給機關代碼。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| unit | No | ||
| limit | No | ||
| include_closed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explicitly states the default is only active reading periods, include_closed behavior, the automatic recently_closed fallback when zero results, the 90-day window, and the fact that opinions can no longer be submitted for closed cases.
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 fairly long but every sentence adds value: definition, default behavior, include_closed, recently_closed fallback, and filter semantics. It is logically structured and front-loaded with the core purpose.
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?
It thoroughly covers parameter behavior and edge cases, but since there is no output schema, it does not describe the structure of returned items (e.g., fields like case ID, date, agency name). Limit is also left implicit. An agent would need to infer response shape.
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 explains q (filters tender or agency, blank acts as AND, 台/臺 interchangeable), unit (agency code), and include_closed. Limit is not explained, but its name and default make its meaning inferable.
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 identifies the tool as listing public reading cases (draft tender documents open for vendor comments), with a specific resource and verb. It explains default filtering and include_closed behavior, though it does not explicitly differentiate it from sibling search tools.
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 implicit usage context: when to set include_closed=True, and when the recently_closed fallback appears. However, it never names alternatives or states when not to use this tool versus sibling tools like search_tenders or get_tender.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用姓名、現職或機關名稱找採購評選委員；回傳評選案數最多的前幾位。
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It reveals one meaningful behavior: results are ranked by the number of review cases and limited to the top few. But it does not disclose match semantics (fuzzy vs exact), the exact limit, whether the search is read-only, or what fields are returned.
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 compact sentence that front-loads the action and search criteria, then gives the result behavior. There is no filler or redundant 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?
For a single-parameter search tool, the description is mostly sufficient for selection and invocation. However, with no output schema and no annotations, it leaves unclear details such as exact result limit, returned fields, and how to choose among the many committee-related sibling tools.
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 schema provides no description for the required q parameter (0% coverage), but the description compensates by specifying that q can be a name, current position, or agency name. This gives an agent enough semantic grounding to populate the sole parameter correctly.
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 action ('找' / search), the resource ('採購評選委員' / procurement evaluation committee members), and the query dimensions (name, current position, or agency name). It also adds a distinguishing result behavior (returns the top members by number of review cases), which differentiates it from sibling tools like committee_member or evaluation_committee.
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 intended use case is implied: use this when you need to find committee members by name, title, or agency. However, it does not explicitly contrast this tool with related siblings such as committee_member or vendor_committee, and it does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋政府標案公告。
q: 關鍵字（比對標題與機關名，例「冷氣」「智慧路燈」）。空白＝且（「路燈 監視器」兩個都要有）、
OR＝或（「路燈 OR 監視器」）、-詞＝排除（「路燈 -維護」）；OR 優先序最低，不支援括號。
kind: tender=招標中 / award=已決標 / failed=流標，空=全部。
region: 縣市（例「台北市」「高雄市」，「臺」寫成「台」）。
year: 公告日期的西元年。只有使用者明確指定年份時才填；不確定就留空——
填了會把跨年度的案子排除（去年底公告、今年才截標的案子就看不到）。
unit_id: 機關代碼（用 find_entity 取得）——查「某機關發的案」用這個，
比 q 精確（q 是全文比對）。
unit_name: 機關名稱片段（例「臺中市政府」，含所屬機關）；沒有代碼時用這個。
vendor: 廠商名稱（正式全名）——查該廠商投標／得標過的案。
budget_min/budget_max: 預算金額範圍（新台幣元）。
回傳最新 10 筆與總數；需要更多用 page 翻頁。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| kind | No | ||
| page | No | ||
| year | No | ||
| region | No | ||
| vendor | No | ||
| unit_id | No | ||
| unit_name | No | ||
| budget_max | No | ||
| budget_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return of latest 10 results, total count, and pagination via page. It also warns about year filtering excluding cross-year tenders. It does not mention authentication, rate limits, or side effects, but for a read-only search tool, its transparency is solid. Minor gap: response format is not detailed beyond count and pagination.
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 structured as a clear list with one line per parameter, front-loading the purpose and return behavior. Each line is dense but necessary given 10 parameters; examples aid comprehension without fluff. Final line about pagination is succinct. No wasted sentences.
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 10-parameter tool with no output schema, the description covers all parameters' semantics, usage constraints, and result set behavior (latest 10, total, pagination). It even provides fallback logic (unit_name when no code). The only missing piece is the exact fields of each tender record, which would be revealed by the output itself, so this is not a gap.
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%, yet the description thoroughly explains every parameter: q's matching logic and syntax, kind's three states, region's normalization (臺→台), year's cautious use, unit_id vs unit_name differentiation, vendor's full-name requirement, and budget range. This goes far beyond the schema's bare names and defaults.
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 with '搜尋政府標案公告' (search government tender announcements), clearly stating the verb and resource. It distinguishes itself from siblings like get_tender (specific tender) and find_entity (entity lookup) by describing the search behavior and return of latest 10 records with total count.
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 explicit when-to-use guidance for each parameter: year should only be filled when explicitly specified, unit_id is preferred over unit_name when a code is available (and points to find_entity), and explains q's AND/OR/exclusion semantics. Also advises against using year when uncertain, warning it excludes cross-year cases. This is actionable and routes to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分包機會：大型企業得標後，決標公告會登記「預估分包予中小企業之金額」（採購法第 67 條允許分包，第 65 條禁止轉包）。 中小企業可以用來找上游：哪些大廠剛標到大案、預計要分多少出來，附得標廠商在決標公告登記的電話地址。 mode="list"（預設）：有預估分包的決標案，q 比對案名／機關／得標廠商（空白＝且、OR＝或、-詞＝排除），region 縣市、 category 工程類／財物類／勞務類，sort=date（新到舊）／amount（分包金額）／rate（分包比例）。 mode="leaders"：常分包的大廠排行（期間內預估分包總額）；mode="units"：大廠得標案分包最多的機關； mode="vendor"：一家廠商（vendor 給正式全名）的分包紀錄。days 期間，預設 365。 注意：這是決標時的預估值，實際分包以契約為準；只記大型企業分給中小企業的部分。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| days | No | ||
| mode | No | list | |
| page | No | ||
| sort | No | date | |
| limit | No | ||
| region | No | ||
| vendor | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It transparently states that the data is an estimate from the award announcement, not the final contract, and clarifies the scope (only large enterprises subcontracting to SMEs). It also mentions the included contact details of the winning vendor. This goes beyond basic read/write semantics and provides context about data freshness and limitations.
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 detailed but well-structured. It starts with the core purpose and legal context, then systematically explains each mode and parameter, and ends with a concise note on data limitations. It is front-loaded with the most important information and uses clear separation of concerns. No word is wasted; every sentence adds value.
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?
The description is comprehensive for a tool with no output schema, but it does not explicitly describe the response format or list the fields returned beyond mentioning the subcontract amount and vendor contact info. It also does not explain the 'page' and 'limit' parameters, though their function is intuitive. Given the complexity of 9 parameters and no output schema, a brief note on the return structure would make it fully complete.
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?
Despite the schema having 0% description coverage, the description adds substantial meaning to nearly every parameter. It explains q syntax (blank=AND, OR=OR, -word=exclude), region (county/city), category (engineering/property/labor), sort options (date/amount/rate), days default, and vendor full name requirement. It also describes the mode parameter's values and their effects. This is far more than the schema titles provide.
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 identifies the tool's purpose: to find subcontracting opportunities from large enterprises that won tenders, with reference to specific procurement law articles (67 and 65). It explains the data source (award announcements) and the intended audience (SMEs). This is a specific verb+resource description that distinguishes it from sibling tools like search_tenders or vendor_awards.
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 provides explicit guidance on when to use each mode (list, leaders, units, vendor) and explains the query syntax, filters, and sort options. It also includes a critical caveat that these are estimated values at award time, actual subcontracting may differ, and that only large-to-SME subcontracting is covered. This is clear, actionable usage guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
機關常找的評選委員：席次數、占比與前 5 位集中度（40% 以上代表委員圈子相對固定）。 unit 為機關代碼（先用 find_entity 查）。
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool computes aggregate statistics and even interprets the 40% threshold as indicating a relatively fixed committee circle. It does not cover auth requirements, rate limits, or edge cases, but it gives a reasonable picture of the tool's read-only analytical behavior.
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 only two sentences long. The first defines the output and its interpretation; the second explains the parameter and prerequisite. There is no filler or repetition of schema fields.
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 analytical tool with no output schema, the description covers the purpose, the metrics, the meaning of a key threshold, and how to obtain the required parameter. It does not describe the exact return shape, but the listed metrics partially compensate. Overall, an agent can likely call this tool 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 0%, so the description must compensate. It does: it explains unit is an agency code and directs the user to find_entity for lookup. This is genuinely useful beyond the bare schema. It could be stronger with format examples or default behavior, but for a single parameter this is sufficient.
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 reports an agency's frequently invited evaluation committee members, with specific metrics: seat counts, proportion, and top-5 concentration. It identifies the resource (unit/committee) and the analytical purpose, though it lacks an explicit action verb and does not directly contrast with sibling committee tools such as evaluation_committee or committee_member.
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 a concrete prerequisite: unit is an agency code and should be resolved via find_entity before using the tool. This is actionable usage guidance. It does not explain when to choose this tool over sibling committee-related tools, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
機關情報報告：發包規模與金額、主要供應商、供應商集中度、 競爭程度（平均投標家數／單一投標率／流標率）、發案旺月、 peer_comparison：這些指標在同類型、同規模機關裡的百分位（pct 80＝比 80% 同類高）， 判斷「算高還是低」要看這個，不要拿不同類型的機關直接比數字、 「固定週期標案」——每年重複招標的案與預估下次發案時間， 以及 reserve_profile：這個機關把底價訂在預算的幾成、決標價落在底價的幾成 （依決標方式分開，同樣是最低標，各機關鬆緊差很多）。 unit 可以是機關代碼（如 3.76.54）或機關全名（會自動查代碼）。 適合回答「這個機關好不好投」「它什麼時候會再發案」。
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the unit parameter accepts an agency code or full name and that the tool will automatically look up the code. It also warns that reserve price tightness varies by agency, which is a behavioral nuance. However, it does not explicitly state that the operation is read-only, nor does it mention any potential side effects, data freshness, or output format. Since '報告' (report) implies read-only, some behavior is left to inference.
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 dense paragraph in Chinese that packs many specific metrics, usage guidance, and input semantics. Every sentence adds value, and key information is front-loaded (the type of report and primary purpose). It is long but not verbose, though it could benefit from bullet points for readability. It 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?
Given the tool has only one parameter, no annotations, and no output schema, the description is quite thorough: it lists all report sections (scale, suppliers, concentration, competition, peak months, peer comparison, recurring tenders, reserve profile) and explains how to interpret peer comparisons. It also covers the input format. Minor gaps remain, such as not mentioning the report's time coverage or how results are presented, but for a one-parameter report generator, it is near complete.
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 0% and the schema only shows a string type for 'unit' with no description. The tool description fully compensates by specifying that 'unit 可以是機關代碼（如 3.76.54）或機關全名（會自動查代碼）' — it can be an agency code (with a concrete example) or the full name, with automatic code lookup. This is precise, gives an example, and explains conversion behavior.
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 that this is an agency information report (機關情報報告) covering specific metrics such as tender scale, supplier concentration, competition levels, peak months, peer comparison, recurring tenders, and reserve price profile. It also explicitly notes the input unit can be an agency code or full name with auto-lookup. This goes beyond a simple verb+resource to differentiate itself from sibling tools like vendor_report, focusing on the agency side.
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 provides clear context for when to use the tool: '適合回答「這個機關好不好投」「它什麼時候會再發案」' (suitable for answering 'is this agency good to bid for' and 'when will it issue tenders again'). It also advises using peer_comparison rather than directly comparing numbers across different agency types. However, it doesn't explicitly name alternative sibling tools or state when NOT to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
某一家廠商的歷年得標清單（一案一列、新到舊），附逐年件數與金額。 name 必須是正式全名（先用 find_entity 查）；year 可用西元或民國年篩選單一年度； unit_id 只看某個機關發給它的案；limit 最多 100，需要更多用 page 翻頁。 award_amount 是這家自己拿到的決標金額：複數決標（同案多家得標或分品項）時不是全案總額， 那種列會另附 winners（得標家數）與 case_total（全案總額）。 要看得標率、對手、往來機關等分析用 vendor_report；要看單一案的開標實況用 get_tender。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| page | No | ||
| year | No | ||
| limit | No | ||
| unit_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
在沒有 annotations 的狀況下，描述承擔了完整的行為揭露：包括 limit 上限 100、用 page 翻頁、year 支援西元/民國年、unit_id 過濾。特別解釋 award_amount 在多廠商得標時不是全案總額，並說明 winners 與 case_total 的附帶資訊，行為細節充分。
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?
沒有 output schema，但描述已說明回傳的列結構、金額語意、分頁與前置查詢，足以讓 agent 正確呼叫。從查詢名稱、篩選、翻頁到判讀結果的資訊都齊全。
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%，但描述逐一賦予五個參數意義：name 需正式全名、year 的年度格式、unit_id 的機關過濾、limit 的上限與 page 的分頁方式。所有參數都有超出欄位名稱的語意。
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 與 get_tender 分別負責分析與單一案件，與 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?
明確說明使用前置條件：name 必須為正式全名且先用 find_entity 查詢。也明確給出替代工具的使用時機：「要看得標率、對手、往來機關等分析用 vendor_report；要看單一案的開標實況用 get_tender」。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
廠商投過且有公開名單的案子裡最常遇到的評選委員：同案次數、其中得標次數， 並附該廠商整體得標率作為基準。name 必須是正式全名。回答時請附合議制聲明， 不要推論委員與廠商之間的關係。
| Name | Required | Description | Default |
|---|---|---|---|
| name | 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?
三個句子結構清晰、每句都有實質貢獻：先說明目的與輸出資料點，再給輸入約束，最後給回答行為要求。無冗詞、無與 schema 重複的內容，資訊密度高且依邏輯順序排列。
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%，參數 name 在 schema 中完全沒有說明。描述補上了關鍵語義：'name 必須是正式全名'，這防止代理傳入縮寫或別名。這是單參數工具最重要的參數約束，的確提供了價值。但除此之外沒有更多——未說明 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?
描述明確指出工具的用途：找出廠商投標且公開發布名單的案件中，最常出現的評選委員，並列出同案件次數、得標次數與基準得標率。這與其他委員會相關的兄弟工具（evaluation_committee、committee_member、search_committee_members）有清楚區隔，因為它是以廠商為中心的統計查詢。不過整個描述沒有明確的動作動詞（如'查詢'、'列出'），而是以名詞短語呈現目的，略有模糊空間。
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?
描述提供了輸入格式限制（name 必須是正式全名）與回答格式要求（需附合議制聲明、不得推論委員與廠商關係），這些是明確的使用指引。但完全沒有提及何時該用此工具而非替代方案，也未說明當廠商無公開名單或無投標案件時該如何處理。鑑於列表中有五個委員會相關工具，缺少替代路由是明顯缺口。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
廠商的政府採購法第 101 條相關紀錄：拒絕往來（生效中／期滿）、註銷拒絕往來、 停權案例（含申訴結果）。name 必須是正式全名。全部為政府電子採購網公告的事實， 請附來源並註明「停權案例含申訴審議中或已撤銷者，以官網記載的救濟結果為準」。 拒絕往來期間依第 103 條不得參加投標或作為決標對象或分包廠商。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the behavioral burden and does so well: it discloses data provenance (政府電子採購網公告的事實), required source citation, the handling of appeal status, and the legal consequence under Article 103. It does not describe output shape or error behavior, but the disclosed context is materially useful.
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 four dense sentences with no filler: scope, name requirement, source/citation requirement, and legal effect. The most identifying information is front-loaded, and every sentence carries necessary guidance.
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 tool with one parameter and no output schema, the description covers the core semantics, source, required disclaimer, and legal significance. It does not specify the exact return format or how strictly name matching works, but it provides enough for correct invocation in most cases.
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 for the single 'name' parameter. It adds the key constraint that 'name' must be the formal full name, which goes beyond the bare schema. Examples or exact-match rules would push it higher, but this is sufficient for a one-parameter tool.
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 identifies the resource precisely: 政府採購法第 101 條 vendor compliance records, and enumerates the included record types (拒絕往來、註銷拒絕往來、停權案例). It stops short of 5 because it lacks an explicit verb such as 查詢, though the intent is unmistakable.
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 provides clear operational guidance: the name must be the formal full name, results must cite the government e-procurement source, and a specific disclaimer about appeal results must be included. It does not explicitly name sibling alternatives, but the scope is distinctive enough for an agent to select this tool over vendor_report or vendor_committee.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
廠商情報報告：得標率、已知得標總額、最大客戶、單一投標比例 （開標時只有它一家的案子占比，全庫平均 50.1%）、最常交手的對手與相對勝率、 近期得標與「近期輸給誰」。name 必須是正式全名（先用 find_entity 查）。 適合分析競爭對手或盡職調查。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains what data the report contains, defines the sole-bid ratio metric with a database average reference, and uses 'known' to caveat the awarded total amount. It does not explicitly state read-only behavior or error handling, but as a report tool the content list and metric definitions give the agent a strong behavioral picture.
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 compact and front-loaded: it opens with the report type, lists all included metrics in one efficient sentence, then adds a critical parameter instruction and use-case note. Every sentence earns its place, and the parenthetical definition of the sole-bid ratio adds real value without bloat.
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 there is no output schema, the description compensates well by enumerating the report's content, including win rate, total awarded amount, largest client, sole-bid ratio, competitors, and recent outcomes. It also covers the required input precondition. It could be more complete by describing the output format or behavior when the vendor is not found, but the listed metrics give an agent sufficient context to invoke and interpret the 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?
Schema description coverage is 0%, so the description must compensate. It directly addresses the only parameter, name, by specifying it must be the formal full name and instructing the agent to look it up via find_entity. This is strong parameter guidance, though an example value or format hint would make it even clearer.
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 defines the tool as a vendor intelligence report, listing concrete metrics such as win rate, known total awarded amount, largest client, sole-bid ratio, main competitors, and recent wins/losses. This specific deliverable distinguishes it from sibling tools like compare_vendors, which compares vendors, and search_tenders, which searches tenders. The verb 'report' and the detailed metric list make the purpose unmistakable.
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 gives an explicit prerequisite: the name must be the formal full name, and find_entity should be used first. It also states the intended use case ('suitable for analyzing competitors or due diligence'). However, it does not explicitly say when not to use this tool or mention alternatives, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
subcontract_opportunitiesframework_contracts1 field changedInput schema / properties / modeAdded value: +{
+ "default": "awards",
+ "title": "Mode",
+ "type": "string"
+}framework_contractsprocurement_forecast1 field changedInput schema / properties / include_pastAdded value: +{
+ "default": false,
+ "title": "Include Past",
+ "type": "boolean"
+}public_reading1 field changedInput schema / properties / include_closedAdded value: +{
+ "default": false,
+ "title": "Include Closed",
+ "type": "boolean"
+}vendor_awardssearch_tenders1 field changedInput schema / properties / unit_nameAdded value: +{
+ "default": "",
+ "title": "Unit Name",
+ "type": "string"
+}asset_salescommittee_memberevaluation_committeeprocurement_forecastpublic_readingsearch_committee_membersunit_committeevendor_committeevendor_compliancecompare_vendorsfind_entityget_tenderhot_opportunitiesprice_analysissearch_tendersunit_reportvendor_reportTaiwan Government Procurement MCP — 政府電子採購網 (PCC) tenders (keyless).
Tender search + AI CPV finder. Register free: 1 daily email alert, up to 20 results/search.
Taiwan legal research: court judgments, statutes, and interpretations. 台灣判決、法條、函釋、釋字搜尋。
Canadian procurement intelligence: CanadaBuys and Alberta tenders, ranked for your shop.
Add one secure layer between your agents and this server.
