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

No annotations exist, so the description carries the full burden, and it does disclose non-obvious traits: segmented, order-preserving returns, segments absent when a category has zero events, `limit` being advisory only, and HK ticker support. Some of this restates the return shape already covered by the output schema, which keeps it from a full 5, but the quirk disclosures are genuinely value-adding.

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?

Front-loaded with the resource and usage triggers, then warnings, so the important routing information comes first. It is dense and the `limit` caveat is repeated (also present in the schema), and the exhaustive slug enumeration is longer than strictly needed, but nothing is superfluous enough to hurt.

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 two-parameter, optional-argument tool with an output schema, this covers everything an agent needs: what it returns, how to safely read a segment, why segments can be missing, and that HK symbols work. No material gap remains.

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 both parameters are already documented; the description still adds meaning by stating the window is roughly one month long (not derivable from the schema) and by stressing that `limit` is only a suggested value with per-segment counts differing. It does not add format details for `date` beyond what the schema says.

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 concrete resource (company event schedule covering dividends, lockup releases, earnings, IPOs, meetings, rights issues) and the exact window (~1 month from a given date). It explicitly names what it is not ('not a macro data calendar') and points to the sibling `ashare_macro`, so an agent can separate it from the many other ashare_* 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?

Gives concrete trigger phrasings ('which stocks unlock next week / who reports soon / which dividends this month') and an explicit exclusion with the correct alternative (`ashare_macro` for GDP/CPI/LPR). The precondition for reading a section (check `data.data` for the slug first) is also spelled out.

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