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

Annotations already cover safety (readOnlyHint=true) and scope (openWorldHint=false), so the bar is lower, and the description still adds real behavior detail: the return bundle (item name, alternate names, pre-purchase measurement advice, a 만물도감 page, Coupang/Naver Shopping links) and the tolerance for vague, slangy input. It does not mention whether shop links require anything or how result ranking works, which is a minor residual gap.

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 purpose, then input characteristics, then return contents, then routing advice — a sensible order. The parenthetical slang examples are long but they earn their place by teaching input quality; only slight trimming would improve it.

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 no output schema, the description compensates by enumerating what comes back, and with only two parameters the surface area is small. The one omission is any statement about what 'limit' controls or how many candidate names are returned by default, which matters slightly for interpreting results.

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 only 50% ('query' is documented, 'limit' is not), so the description must compensate, and it does: it tells the agent to pass a raw vague description (shape, place, symptom, field slang) with concrete Korean examples, which is meaningfully richer than the schema's '사용자가 말한 그대로의 설명'. The 'limit' parameter is never addressed, though its default and 1-10 bounds are self-explanatory in the schema.

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 verb and resource ('Find the name of any physical object, part or daily-life item') and states the input shape ('from a vague Korean (or English) description') plus the exact output payload. An agent immediately knows this is a name-identification tool, not a search or shopping tool.

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?

'Use this first when a user asks what something is called or where to buy a part they cannot name' gives a clear triggering condition and a priority signal ('first') for a workflow. There are no sibling tools to disambiguate against, so no alternatives or exclusions are needed, but no explicit when-not guidance is offered either.

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