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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds substantial non-obvious behavior beyond that: the definition varies per tax kind, de facto marriage is expressly excluded in acquisition tax, under-30 unmarried children need 12-month income above 40% median, and the care-merge exception age differs (65 vs 60). This is real decision context, though it omits anything about the shape of the verdict 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?

The purpose is front-loaded, and the tax_kind warning plus the per-tax bullet structure make it scannable despite being dense. It is somewhat verbose and mixes legal citations with operational guidance, but no sentence is clearly wasteful.

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 12 parameters, a single required field, no output schema, and the complexity of a tax-law household test, the description supplies the essential per-tax rules and exceptions. It is close to complete for the inputs, with the main gap being that it never states what the judgment returns.

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% across 12 parameters, so the description must compensate and does so only partially. It clarifies relationship values, tax_kind, is_de_facto_marriage, merged_for_parent_care, descendant_age, and legally_divorced_but_living_together, but leaves age, is_minor, lives_together, is_married_or_was, and shares_livelihood unexplained.

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 specific verb+resource: 'Decide whether two people form one household (1세대) for income, acquisition or holding tax purposes.' It scopes the tool precisely (household-identity determination) and cites the governing legal bases, which lets an agent distinguish it from status-oriented siblings like judge_jongbu_one_home_status or judge_155_special.

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?

It gives explicit conditional guidance: tax_kind must be matched, and it details how the household definition diverges between 양도세 (same address + shared livelihood) and 취득세 (resident-registration table). It does not, however, name sibling tools as alternatives for adjacent determinations, so it stops short of full routing guidance.

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