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

The annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the description's added value is the semantic caveat: some versions are unverified and must not anchor an assertion. That is real behavioral context that the annotations cannot convey. It still doesn't say how many versions come back or whether the full history or a windowed slice is returned.

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?

Three short sentences, with the return contents stated first and the caveat last, so nothing is buried. There is no filler. The only weakness is that the trigger advice and the caveat could be tightened into one line.

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?

There is no output schema, but the description covers what the result contains (history, notation, verification flags), which partly compensates. The gap is the callable side: the required law_name/article_number formats are left entirely unaddressed, and the agent can easily supply the wrong shape. This is adequate but incomplete for a two-required-param lookup.

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 0%, so the description should carry the burden for law_name and article_number, but it says nothing about expected formats (for example, whether article_number is '3' or '제3조'). The phrase '특정 조문' only implies what the parameters are, without giving an agent enough information to fill them in reliably.

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 (returns) and a well-scoped resource (revision history of a specific article), and it enumerates what the payload contains: version history, revision notation, verification/source status. It does not explicitly distinguish itself from get_article (current text), but the scope is clear enough that an agent can tell the two apart.

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 names the trigger question ('when did it change') directly, so the agent knows when this tool is the right call. It also adds an exclusion ('don't use unverified versions for definitive application'), which is useful usage guidance. It stops short of naming an alternative tool for current text.

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