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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description goes well beyond that by disclosing the legal logic: the prohibition triggers (재건축 after 조합설립인가, 재개발 after 관리처분인가), the exceptions (gift included, inheritance/divorce excluded), the consequence for the buyer (§39③→§73 loss-compensation route), and the fact that transfer_notice_done=True voids the restriction. This is rich domain behavior an agent could not infer from annotations.

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 question is front-loaded and every clause maps to a rule or parameter, so there is little outright waste. However the body is a dense run-on block mixing Korean and English with stacked legal citations, lacking clear delineation between the rule, the exceptions, and the per-parameter guidance, which hurts scanability.

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 complex, 11-parameter legal judgment with no output schema and no annotation-level detail, the description supplies the core decision rules, exceptions, timing effects and parameter routing needed to invoke it. It does not describe the shape of the returned judgment, which is the main remaining gap given the absence of an output schema.

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 11 parameters, so the description carries the full burden and does substantial work: it explains the role of in_speculation_overheated_zone, transfer_notice_done, is_one_plus_one_small (§76①7호라목 3-year resale ban), and enumerates the allowed transferor_reason values including the 시행령예외 case that drives decree_reason (§37③). Parameters such as owned_years, resided_years, association_established, management_disposal_approved and is_partial_share_transfer are only implied, so coverage is partial rather than complete.

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 opening line states a specific judgment task — whether a reconstruction/redevelopment association membership can be transferred in a speculation zone, citing Urban Renewal Act art. 39. This is a concrete verb+resource that separates it from the calc_* and other judge_* siblings. The mixed Korean/English phrasing and legal-citation density add some friction but the purpose remains identifiable.

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?

Explicitly frames the tool as a 'salability pre-filter that comes before tax calculation' (세액 계산보다 앞선 매도가능성 선필터), which tells the agent when to call it relative to the tax siblings. It also routes the agent to search_law(admrul, '투기과열지구 지정') to verify the zone at transaction time. No explicit when-not conditions are given, so it stops 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.