公開閱覽：招標文件草案公開徵求廠商意見的案件，廠商可在意見截止日前向機關提出規格或資格意見。 預設只列「閱覽期內」的案（通常只有幾十件）；include_closed=True 連閱覽期已過的一起列（有三千多件，適合看某類案的規格草案）。 閱覽期內 0 筆時，會自動附上 recently_closed：最近 90 天內已結束的同類公開閱覽（已截止、不能再提意見）， 可以看這類案有哪些機關在辦、規格草案長怎樣，通常不久後就會正式招標。 q 篩標案或機關（空白＝且，台／臺互通），unit 給機關代碼。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| unit | No | ||
| limit | No | ||
| include_closed | No |
Changes observed during successful MCP inspections.
Input schema / properties / include_closedAdded value: +{
+ "default": false,
+ "title": "Include Closed",
+ "type": "boolean"
+}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.
Add one secure layer between your agents and this server.