search_taxlaw

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

No annotations are provided, so the description must carry the behavioral transparency burden on its own. It helpfully discloses the exact-lookup priority ('질의에 문서번호가 섞여 있으면 exact lookup 을 최우선으로 시도한다') and the auto-domain-detection behavior. However, it does not reveal the return-retention format, pagination, sorting, or what happens when the auto-detection is ambiguous, leaving some important behavior unaddressed.

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 description is economical and front-loaded: the first sentence states the tool's core purpose, the next two sentences provide essential behavioral constraints, and the final sentence gives the usage context. Every sentence serves a distinct, valuable purpose without repetition or wasted tokens.

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?

Given the available context with low complexity and a schema with 100% description coverage, the description is sufficiently complete. It explains the main behavioral nuances (exact lookup, auto-domain detection), and its entry-point advice makes it clear when to invoke this tool in a larger flow. A slightly more explicit distinction from lookup_tax_document and the named domain-specific siblings would make it fully complete, so it stops one step short of 5.

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 covers all four parameters with full coverage, which gives a baseline of 3. The description adds value by clarifying that the query parameter can include document numbers and that domains can be auto-inferred from expressions like '예규', '심판', '통칙', and '적부'. This goes beyond the schema's short description and improves an agent's understanding of how to fill meaningful values.

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 clear and specific statement: '국세청 자료 전 영역을 한 번에 검색한다' – it searches all NTS data areas at once (inquiries, decisions, notices, forms). This distinguishes the tool from sibling domain-specific search tools, and adds the exact-lookup behavior for document numbers, making the purpose explicit and unique.

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?

The description explicitly says to use this tool as the entry point when unsure which area to search ('어느 영역을 봐야 할지 모를 때의 진입점으로 쓸 것'). It also implies that when the domain is unknown, the tool will auto-detect it based on the query. However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of a 5.

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