get_law_text

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral details beyond annotations, especially the jo natural-language conversion and the 6-digit code formatting pitfall. It does not mention response format, but annotation coverage lowers that burden.

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 a single dense sentence with front-loaded purpose followed by necessary usage details. The jo code examples and the explicit error case '234002 아님' carry high information value with no filler.

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 read-only retrieval tool, this description covers purpose, required identifiers, optional jo behavior, and the tricky JO code transformation. No output schema exists, but '전문 조회' implies the return is the full provision text. It could be more complete by explaining the mst/lawId ambiguity and return behavior explicitly, but it is largely sufficient.

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 description coverage is 100%, so the baseline is 3. The description adds extra meaning by declaring mst/lawId as required and emphasizing jo as the recommended way to target a specific article. It is partly redundant with the schema's detailed jo explanation, but still adds selection semantics absent from the required array.

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?

Description clearly states this is a law-article full-text lookup ('조문 전문 조회') using mst/lawId and optional jo, which distinguishes it from search-oriented siblings like search_law and get_annexes. It is specific about the resource and action, though it does not explicitly contrast itself with sibling tools.

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?

Provides clear usage context: mst/lawId are required, jo narrows to a specific article, and natural-language jo input is recommended. It does not state explicit when-not-to-use guidance or name alternatives, but the context is unambiguous enough for an agent to decide when this tool applies.

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