청약 도우미

housing_finance_save

Destructive

Calculates and validates a housing finance plan, then saves or replaces the full plan; read existing inputs first and include payments, costs, and funding you want to keep.

Instructions

자금 계획 입력을 계산·검증한 뒤 본인의 계획 전체를 저장·교체합니다. 먼저 housing_finance_get으로 기존 입력을 읽고, 사용자가 유지하려는 납부·비용·유입 항목을 포함하세요. 입력 검증 통과는 실제 자금 확보나 대출 승인을 뜻하지 않습니다.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plan": "<plan>"
    },
    "name": "housing_finance_save"
  }
}

Input Schema

Name	Required	Description	Default
`asOf`	No
`plan`	Yes	현금 기준일 이후 납부·부대비용·유입·기존 대출 상환. 미확인 금액은 null이며 0원으로 추정하지 않습니다.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations, the description explains what replacement means: omitted items are dropped, so the agent must include the ones to preserve. That adds real context for the destructiveHint=true flag. The caveat that passing validation does not mean funds are secured or a loan is approved is a meaningful limit. It still does not describe the rate limits, auth needs, or what the validation failure result looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, with the action stated first, then the read-before-write procedure, then the validation disclaimer. Every sentence does real work, and none repeats the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a deeply nested, destructive, whole-plan save with no output schema, the description covers purpose, precondition, and replace semantics well. It could still say more about what the tool returns, such as calculation results or validation errors, and about what the top-level asOf means.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, and the nested plan object has its own description, so the schema carries much of the load. The description lists the item categories (payments, costs, funding), which maps to some sub-arrays, but it says nothing about the top-level asOf argument or about debtRepayments, availableCashWon, and the completeness flags. A baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb pair and resource: it calculates and validates funding-plan input, then saves or replaces the user's entire plan. That distinguishes it from housing_finance_get, which it names, but it never mentioned the similarly named housing_finance_calculate sibling, so an agent must infer that calculate is the non-persisting variant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states an explicit precondition and a procedure: read the existing plan with housing_finance_get first, and carry over the payments, costs, and funding items the user wants to keep. It does not say when not to use the tool, or when to prefer calculate-only, but the read-before-write guidance is unusually actionable.

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

Deploy Server