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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the default lookback of 5 trading days, that signals are computed on daily closes rather than intraday, and that leaving event empty returns per-event counts plus the top 5 each. No mention of result caps or the shape when event is supplied.

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?

Dense but front-loaded: purpose first, then event glossary, then output default, then example queries. The event enumeration is long but each definition earns its place; the only weakness is that it reads as one run-on block with the '일별 종가 기준' caveat buried at the end where it matters.

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?

With ten optional parameters and no output schema, the description does the important work: it explains what is returned when event is omitted and that evaluations are close-based. Gaps remain on how limit/theme/industry narrow results and what the response looks like once a specific event is requested.

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 50%, and the description compensates well for the most consequential parameter by defining every event enum value and restating the days default. However limit, theme, market, and industry get no explanation in either the description or the schema, and the interaction between limit and the empty-event default (top 5) is left ambiguous.

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 resource (주가 이벤트) and scope (전 종목, 최근 N거래일) and enumerates all nine event types with inline definitions (high_52w = 52주 신고가(종가), golden_cross = 20일선이 60일선 위로, limit_up = +29.5% 이상). This is specific enough that an agent can distinguish it from siblings like price, rank, or screen without opening the 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 concrete trigger phrasings ('52주 신고가 종목', '거래량 터진 종목', '며칠째 오르는 종목') that map directly to the event enum, which is strong when-to-use guidance. It stops short of naming alternatives or exclusions, e.g. that a single stock's price history belongs to price, or custom composite filters to screen.

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