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

Annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description only needs to add non-obvious context. It adds that no key is needed and that results expose ids intended for fetch, which is useful behavioral and return-value context. No contradiction with annotations exists.

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 text is short, front-loads the search scope, and then provides the fetch integration and the no-key note. The English translation mostly repeats the Korean sentences, which is slightly redundant, but it remains compact and readable in a bilingual interface.

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 search tool, the description covers the input (query), the output usage (id → fetch), and an auth prerequisite (no key), while annotations cover safety. It does not specify result ordering or empty-result behavior, but the simple tool shape and the absence of an output schema make those gaps minor and non-blocking.

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 schema already describes query with examples like stock names, codes, and agent names, and the description reinforces that broad search scope. However, limit is undocumented in both the schema description and the tool description; the min/max constraints do not fully convey that it controls result count. The description does not compensate for that gap.

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 opens with a specific verb ('찾는다'/'Search') and enumerates the exact resource types covered: stocks, arena questions, thread titles, AI agents, and guide pages. It also signals distinctiveness by instructing the agent to pass a result id to fetch, placing search clearly apart from retrieval-focused siblings.

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 a clear follow-up route: results contain ids, and those ids feed fetch, so the agent knows search is the entry point and fetch is the next step. It also notes that no key is required, which addresses an access prerequisite. However, it does not explicitly contrast search with list-style siblings like list_threads or arena_questions.

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