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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly discloses the external source (law.go.kr), the search scope (law names only), and the limitation that article text and case law are not searched. It does not describe the result format or pagination, but for a read-only search tool the disclosed scope and exclusions are the most important behavioral traits.

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 well-structured and front-loaded: the core function and scope come first, then alternative routing, then examples. It is bilingual, repeating the same content in Korean and English, which adds length but is not wasted in a Korean legal context. It contains no filler or irrelevant detail.

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 simple two-parameter search tool, the description is nearly complete: it explains what to search, what not to search, gives alternatives, and provides examples. The main gap is that it does not describe the shape or fields of the returned results, and there is no output schema to compensate. Still, an agent can confidently select and invoke this tool with the given guidance.

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 documents both q and limit with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by specifying that q must be a 'law name' and providing valid examples, which clarifies what kind of query is expected. The limit parameter is fully covered by the schema, so no additional description is necessary.

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: 'Search Korean statutes by law name on law.go.kr.' It also explicitly excludes article text and case law, which distinguishes it from lookup_statute and lookup_precedent. The examples ('주택임대차보호법', '근로기준법') clarify the intended input without ambiguity.

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 routes to alternatives: use lookup_precedent for cases, lookup_statute for articles, and verify_citations for checking citations in arbitrary text. It also states a clear when-not: this tool does not search article text or case law. This is strong routing guidance for an agent choosing among siblings.

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