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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: a batch ceiling of 10 codes and partial-failure semantics where unknown codes land in a not_found bucket rather than failing the call. It does not mention result ordering relative to input codes, which is the main remaining ambiguity for batch use.

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 definition is front-loaded with the verb and resource, then the batch limit, then the failure mode, which is the right order for an agent scanning for go/no-go information. The long middle enumeration of ten returned attributes is somewhat redundant given that an output schema exists, but it is compactly punctuated rather than verbose.

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 an output schema present, the description does not need to explain return values, and it correctly spends its budget on scope ('public information only'), the 10-code batch limit, and not_found handling. The only gap is whether results are returned in the same order as the input codes, which matters for correlating a batch response back to the request.

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?

There is a single parameter with 100% schema description coverage, including the regex pattern, min/max items, and a code example, so the schema does the heavy lifting. The description only restates the batching limit ('한 번에 10개까지') and the code concept, adding no format or syntax detail beyond 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 states a specific verb and resource ('look up public info of materials by jitdot code') and enumerates exactly which attributes come back (display name, category, finish, spec, price, etc.), so the agent knows what it retrieves. It distinguishes itself implicitly from siblings by returning only presence flags for stock ('재고 유무') and design files ('설계 파일 유무'), which point to check_stock and get_design_files, but it never names those siblings explicitly.

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?

Usage is only implied: the tool requires jitdot codes as input, so the agent must already hold them, and 'codes not in the public catalog go into not_found' implies a lookup-by-known-ID workflow. There is no statement of when to prefer search_materials to discover codes, or when to escalate to check_stock for real stock levels, so the agent must infer routing from sibling names alone.

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