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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the size of the dataset (183 themes), the return content per mode (关联个股/节点/位置/关联度/业务描述), the hard parameter-combination constraint with the failure consequence ('给错组合拿不到数据'), and the naming constraint (Chinese full names only). It still omits any note on data freshness, result size limits, or latency, which keeps it short of a 5.

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 mode enumeration is front-loaded and the two ⚠️ warnings cover distinct issues (parameter pairing vs. topic naming), so there is little true redundancy. Heavy markdown bolding and emoji add visual noise, and the mode list partly restates the schema's own mode description, which is the only real drag.

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?

An output schema exists, so return-value documentation is not required, yet the description still sketches what comes back per mode. Combined with the mode selection rules, the Chinese-name constraint, and the list-first fallback, an agent has everything needed to call this three-mode tool correctly on the first attempt.

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 baseline is 3, and the description genuinely exceeds it by stating the two-way exclusivity rule (graph requires topic, stock requires code) and the invalid-combination outcome, which the schema's per-parameter 必填 notes do not express. The supplied example values for topic and code also disambiguate format beyond the schema's '如 sh600667'.

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 names a specific resource (A股产业链, 183 themes) and enumerates the three distinct modes with concrete call examples (`mode=list`, `mode=graph` + `topic=超级电容`, `mode=stock` + `code=sh600667`) along with what each returns. This lets an agent distinguish it from sibling tools like ashare_sector or ashare_profile without opening a 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?

It gives an explicit trigger list ('用户问产业链/上下游/某公司处于链上什么位置/这个主题有哪些公司'用这个), states the mutual-exclusion rule selecting between graph and stock modes, and even prescribes a fallback (call `mode=list` first when unsure of the Chinese full topic name). When-to-use, when-not-to-use, and alternatives are all present.

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