realestate.kr_ltv

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description goes further by disclosing the substantive regulatory behavior: limit ratios vary by district/house count/first-time status, multi-household in regulated or capital areas gets 0% for additional purchases, and hard amount caps of 600M/400M/200M KRW apply by market value band. These are genuine behavioral rules an agent cannot infer from any structured field.

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?

Front-loaded with the operation and output, then the ratio rules, then the amount caps, then the misuse note — logical and mostly waste-free. It is dense with Korean regulatory detail, but every clause carries substantive information; only the amount-cap sentence could be tightened.

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?

An output schema exists, so return values need not be explained, and the core regulatory logic is present. However, for a 9-parameter domain calculator the description leaves year (which regulation version) and include_proposed (whether proposed legislation counts) completely unexplained, and provides no routing against the DSR/DTI siblings — an agent could easily call it with the wrong vintage of rules.

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 coverage is 0% across 9 parameters, so the description must carry parameter meaning and only partly does: it clarifies that loan_amount and property_value are KRW strings with 4-decimal HALF_EVEN rounding, and it maps house_count, is_regulated, is_capital_area and is_first_time_buyer to the ratio rules. It says nothing about year, as_of, or include_proposed, which are three of the nine inputs, leaving a real gap.

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 names a specific computation (LTV = loan amount / property value) plus two concrete outputs: whether the loan is within the limit and the maximum allowed loan amount. That is clearly distinct from formula-flavored siblings such as realestate.kr_dsr or realestate.kr_dti, though it never explicitly contrasts itself with them, so it stops short of a 5.

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 describes the domain rules under which the tool applies (regulated/capital area, house count, first-time buyer) but gives no explicit 'use this instead of X' guidance against the DSR/DTI siblings in the same namespace. It does include one concrete misuse warning (house_count must be the pre-loan household count), which is real usage guidance but limited to a single parameter.

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