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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the calculation is deterministic on the factsheet, defaults assume standard tax rates while 중과·감면 live in realty_policy_rules, and — critically — it instructs the agent that assumptions must be surfaced to the user. It stops short of describing return shape in detail, but the disclosure of the assumption-handling obligation is valuable.

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 core purpose and boundary are front-loaded well, but the text is dense with self-referential asides (신고 #43의 선 그대로, 실측 124만원) that add persuasion rather than actionable content. Several parentheticals could be dropped without losing invocation-relevant meaning, so it reads as verbose rather than tight.

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 7-parameter, no-output-schema financial calculation, the description supplies the missing context: deterministic vs. personal-parameter split, assumption disclosure duty, and the sibling that owns each excluded concern. It also hints at return shape ('행마다 한 줄 요지' vs footnotes), which is enough given no output schema. Minor gap: no explicit note on which parameters are needed to get a meaningful result when all are optional.

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 every parameter (keyword, house_ty, movein_ym, mid_rate_pct, house_manage_no, extra_options_krw, include_footnotes) is already documented in the schema with defaults, ranges, and cross-tool hints. The description adds only the general note that rates may differ from the default; it does not extend parameter semantics meaningfully, so the baseline 3 applies.

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?

States a specific verb (계산한다) and a precisely bounded resource (분양 한 건의 층별 총 소요자금), then enumerates the exact components: 분양가·발코니·중도금이자·취득세. The agent can immediately tell this apart from sibling cost tools like realty_presale_funding_plan without reading any schema.

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 draws the boundary: it computes only what is deterministically derived from the notice + tax law, and names the alternatives for everything outside that line — realty_complex_rent_by_pyeong for jeonse prices, realty_presale_funding_plan for loan/funding judgment, realty_policy_rules for the tax table itself. This is a textbook when/when-not/alternatives statement.

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