청약 도우미

housing_candidate_delete

Destructive

Delete one saved housing candidate by ID after confirming the target from the candidate list or detail view. Use it to remove a saved candidate, not to cancel an actual subscription application.

Instructions

사용자가 삭제를 요청한 본인의 저장 후보 하나를 삭제합니다. 후보 목록이나 상세 조회로 대상 ID를 확인한 뒤 사용하세요. 실제 청약 신청을 취소하는 기능은 아닙니다.

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": {
      "id": "<id>"
    },
    "name": "housing_candidate_delete"
  }
}

Input Schema

Name	Required	Description	Default
`id`	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 declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds value beyond that by constraining scope to the caller's own saved candidate and by clarifying that no real subscription is affected, which is exactly the kind of blast-radius context annotations cannot express.

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 short sentences, zero filler: what it does first, how to prepare second, and the key caveat last. Each sentence earns its place and the ordering is front-loaded with the operation itself.

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 one-parameter destructive delete with full annotation coverage and no output schema, the description supplies ownership scope, ID provenance and a domain caveat. It does not mention behavior on a nonexistent or already-deleted ID, which is the remaining gap for a destructive operation.

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

Parameters4/5

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

Schema coverage is 0% and the single 'id' parameter carries only a UUID format and pattern, so the description must supply meaning. It does so by identifying the value as a candidate target ID and telling the agent to obtain it from the list or detail endpoints, which is more than the schema provides.

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?

The opening sentence gives a specific verb (deletes) and a precisely scoped resource (one of the user's own saved candidates), so an agent knows exactly what operation this is. It also distinguishes the act from what it is not, namely a real application cancellation, which prevents the most likely misinterpretation in this domain.

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 a concrete prerequisite: confirm the target ID through the candidate list or the detail lookup before calling, which implicitly routes to housing_candidate_list and housing_candidate_get. It adds a boundary statement that this does not cancel an actual subscription application, though it does not name an alternative tool for that case.

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

Deploy Server