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 tool merges three TWSE datasets and queries in parallel, and explains the failure behavior: '任何一段查不到都會標成 null 並記在 caveats，不會整個失敗' (any missing segment is marked as null and recorded in caveats, not causing overall failure). This adds significant behavioral context beyond the schema.

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 three sentences long, front-loaded with the main purpose, then a key caveat, then behavioral details. Every sentence contributes distinct information without redundancy, making it appropriately concise and well-structured.

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 absence of an output schema and annotations, the description covers essential context: the high-level output contents, data freshness disclaimer, parallel querying, and error handling with nulls and caveats. This is sufficient for an agent to understand what to expect and when to use the tool, making it complete for its complexity.

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?

The input schema already provides 100% coverage for both parameters: 'code' includes examples and 'include_realtime' explains its default and extra call. The tool description itself adds no additional parameter details, so the baseline of 3 applies as per the rubric.

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 the tool's function: '一次取得單一上市 ETF 的完整概況' (obtain a complete overview of a single listed ETF), and lists the exact components (basic info, previous trading day price/volume, periodic investment popularity). It also distinguishes itself from a sibling tool by explicitly directing users to twse_realtime_quote for real-time prices.

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 explicit when-not-to-use guidance: '價量為前一交易日，不是盤中即時；要當下價格請用 twse_realtime_quote' (price/volume is from previous trading day, not real-time; use twse_realtime_quote for current price). This names the alternative tool and clarifies the scope, satisfying the requirement for explicit usage direction.

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