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.