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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a real behavioral constraint beyond that — only *currently listed* Korean stocks are searched and matching is by partial string. It says nothing about multiple matches (list vs. single best hit), result limits, or ordering, which matters for a lookup tool feeding other calls.

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?

Two short sentences, front-loaded with what it does and followed by why you'd call it. No filler, though the second sentence could be folded into the first without loss.

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?

There is no output schema, so the description is the only place to learn what comes back — and it never says whether the response is a list of matches, a single ticker, or includes names/codes together. For a one-parameter lookup tool this is a notable omission, though the core contract is still usable.

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 0% and the single 'query' property is an untyped-in-practice bare string, so the description must carry the load. It does add meaning by saying both a partial stock name and a stock code are acceptable inputs, but it gives no detail on format (e.g., 6-digit code vs. full name) or ambiguity handling.

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 gives a specific verb ('찾는다' / find) and resource ('지금 상장된 한국 종목' / currently listed Korean stocks), plus the matching keys (partial name or code). That is enough to distinguish it from siblings like search_holder or get_holders, though it never names a sibling explicitly to confirm the contrast.

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 states the operational context clearly: the result is meant to supply the ticker argument for other tools, which tells an agent when to reach for it. It does not state any when-not conditions or name an alternative for resolving tickers another way.

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