Skip to main content
Glama

search_tenders

搜尋政府標案公告。

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 翻頁。

Input Schema

TableJSON 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.8/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. 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources