청약 도우미

housing_candidate_save

Destructive

Save housing subscription review candidates and notes, creating a new entry or replacing an existing one by ID. Read the record first before updating; saving does not verify eligibility or apply.

Instructions

본인의 검토 후보와 메모를 저장합니다. id 생략 시 새 항목을 만들고, id 지정 시 본인 항목 전체를 교체하므로 housing_candidate_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": {
      "candidate": "<candidate>"
    },
    "name": "housing_candidate_save"
  }
}

Input Schema

Name	Required	Description	Default
`id`	No
`candidate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag destructive=true and idempotent=false, but the description earns credit by explaining exactly what is destroyed: the whole personal item is replaced when id is given, so the safe read-before-write path is spelled out. It also disclaims side effects (not eligibility check, application, or reservation), though it says nothing about return values or per-user ownership checks.

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 tight sentences: the replacement hazard is front-loaded, the alternative tool is named next, and the disclaimer closes it. No filler or restated field names.

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 destructive, non-idempotent mutation with no output schema, the description covers the critical risk (full overwrite) and the required prior read. It stops short of describing the response or ownership constraints, which would fully close the loop.

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 description coverage is 0%, so the description must compensate, and it usefully defines the semantics of id (create vs. full replace). However it says nothing about the candidate payload beyond 'memo', leaving the large nested notice/requirements structure entirely to the schema.

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

Purpose5/5

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

Names a specific verb and resource (save the user's review candidate and memo) and immediately clarifies the create-vs-replace duality. It is clearly separable from housing_candidate_get and the other housing_*_save siblings.

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

Usage Guidelines5/5

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

Explicitly states the branching condition: omit id to create, supply id to replace, and read the existing record first via housing_candidate_get. Alternatives and prerequisites are both named, leaving nothing to inference.

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

Deploy Server