Skip to main content
Glama

search_tenders

搜尋政府標案公告。

q: 關鍵字(比對標題與機關名,例「冷氣」「智慧路燈」)。空白=且(「路燈 監視器」兩個都要有)、
   OR=或(「路燈 OR 監視器」)、-詞=排除(「路燈 -維護」);OR 優先序最低,不支援括號。
kind: tender=招標中 / award=已決標 / failed=流標,空=全部。
region: 縣市(例「台北市」「高雄市」,「臺」寫成「台」)。依序以公告明細的履約地點、機關名稱、
        案名裡的地名判斷;靠案名推估的那筆會帶 location_guess(約九成五準確),回答時要註明是推估。
        仍有約 5% 判不出(多為台灣中油、台電、國防部各司令部、台鐵、海巡署、駐外機構,履約地點寫「其他」),
        填 region 查不到。要找齊某地區:填 region 搜一次,再對這些機關用 unit_name、不填 region 搜一次,
        location 寫「其他」或沒有的,用 get_tender 看履約地點與開標地點判斷,並標明「履約地點未明」。
year: 公告日期的西元年。只有使用者明確指定年份時才填;不確定就留空——
      填了會把跨年度的案子排除(去年底公告、今年才截標的案子就看不到)。
unit_id: 機關代碼(用 find_entity 取得)——查「某機關發的案」用這個,
         比 q 精確(q 是全文比對)。
unit_name: 機關名稱片段(例「臺中市政府」,含所屬機關);沒有代碼時用這個。
vendor: 廠商名稱(正式全名)——查該廠商投標/得標過的案。
budget_min/budget_max: 預算金額範圍(新台幣元)。
回傳最新 10 筆與總數;需要更多用 page 翻頁。

Input Schema

NameRequiredDescriptionDefault
qNo
kindNo
pageNo
yearNo
regionNo
vendorNo
unit_idNo
unit_nameNo
budget_maxNo
budget_minNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / unit_name
      Added value: +{
      +  "default": "",
      +  "title": "Unit Name",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and mostly succeeds: it discloses the return shape (最新 10 筆與總數), the pagination mechanism, the synthetic field location_guess with ~95% accuracy and a duty to label it as estimated, and the ~5% of agencies where region matching fails. It does not mention read-only safety, error behavior, or rate/query cost, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then a clean parameter-by-parameter block where each line is actionable rather than filler. The enumeration of agencies where region fails (中油、台電、國防部…) is long but functional. Slightly dense, and the region paragraph could be tightened without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by stating the return size, total count, pagination, and the location_guess caveat. For a 10-parameter search tool with rich filtering semantics and known data-quality traps, essentially nothing an agent needs in order to query correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must document all 10 parameters — and it does. It supplies non-obvious syntax for q (AND by space, 'OR' keyword, '-term' exclusion, no parentheses, OR lowest precedence), enumerates kind values (tender/award/failed), normalizes region spelling (臺→台), and explains budget units and year's cross-year exclusion risk. This is meaning well beyond bare property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: '搜尋政府標案公告' (search government tender announcements). An agent can tell this is the list/search tool versus get_tender (single record fetch) even though no sibling is named explicitly. It stops short of the top score because the distinction from vendor_awards or framework_contracts is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes between alternatives: 'unit_id(用 find_entity 取得)' vs unit_name vs q, and notes q is full-text while unit_id is precise. It gives a concrete multi-step procedure for regional completeness (search region once, re-search by unit_name without region, then use get_tender to inspect 履約地點) and states when NOT to fill year. This is as prescriptive as a search tool definition gets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources