採購預告：機關在正式招標前公布的「幾月要招、預算多少」，通常早 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 |
Changes observed during successful MCP inspections.
Input schema / properties / include_pastAdded value: +{
+ "default": false,
+ "title": "Include Past",
+ "type": "boolean"
+}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.
Add one secure layer between your agents and this server.