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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds several things annotations cannot express: the returned `status` lifecycle vocabulary and how to interpret repealed/ceased vs `unknown`, and the warning that a not-found result does not mean the serial is fabricated. It also discloses the document class limit (agency materials, never court reasoning), which prevents a misattribution error the annotations would not catch.

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?

It is a dense block rather than a short one, but the identifying fact (EXACT serial lookup) is front-loaded and each subsequent sentence encodes a distinct failure mode: status misreading, miss-as-fabrication, document-class confusion, wrong-tool-for-keywords. The final 勞裁字 sentence is narrow but prevents a specific misfire, so it earns its place; a line-broken layout would improve scanability.

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?

For a 2-parameter, no-output-schema lookup tool, everything an agent needs to call it correctly and to correctly interpret the result is present: input shape, the status field's meaning, the meaning of a miss, and the doc-type boundary. There is no output schema, yet the description still characterizes the returned payload enough to act on it.

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 100%, so the per-field descriptions already carry the parameter semantics and the baseline is 3. The description adds a genuine constraint beyond that — that this tool takes the serial only and that keyword exploration belongs elsewhere — which reinforces why `serial` must be an exact number rather than a search phrase.

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?

States a specific verb and resource ('EXACT lookup of a Taiwan administrative interpretation by its issuing serial number') and immediately supplies concrete serial-format examples. It also explicitly marks the boundary against search_legal_references (keyword exploration), so an agent can pick between the two without opening either schema.

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?

Gives an explicit use case ('verify that a cited interpretation exists and to check its current validity BEFORE citing it') plus named alternatives and the condition that selects each: search_judgments for judgments, search_legal_references for topic/keyword work, search_bundle/search_judgments for 勞裁字 decisions. Exclusions are stated as directly as the inclusions.

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