Skip to main content
Glama
Sign In
청약 도우미

청약 도우미

by ANNJUNGCHAN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

housing_profile_save

Destructive

Validate the user's housing subscription conditions and replace the complete saved profile, preserving retained values; omitted criteria become unconfirmed.

Instructions

본인의 청약 조건을 검증한 뒤 프로필 전체를 교체합니다. 먼저 housing_profile_get으로 기존 값을 읽고, 사용자가 유지하려는 값을 포함해 저장하세요. 생략한 조건은 미확인으로 바뀝니다. 관심지역 비교는 지원하는 지역명 별칭을 정규화한 뒤 공고의 region 값과 일치하는지 확인합니다. 성남을 경기도로 확장하는 시·도 포함관계 판정은 하지 않으므로, 저장 전 공고의 지역 단위와 사용자 의도를 확인하세요.

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": {
      "profile": "<profile>"
    },
    "name": "housing_profile_save"
  }
}

Input Schema

NameRequiredDescriptionDefault
profileYes확인된 개인 조건. 모르는 값은 null 또는 생략합니다. 은행 계좌번호나 인증정보는 입력하지 않습니다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but they do not say *what* is destroyed; the description does — "생략한 조건은 미확인으로 바뀝니다" — making full-replacement data loss concrete. It also discloses a genuine analytical limitation (no 시·도 containment, e.g. 성남→경기도), which an agent could not infer from annotations or schema.

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

Conciseness4/5

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

Four sentences, front-loaded with the action and its destructive scope, then the prerequisite, then the two semantic caveats. Dense but every clause carries operational weight; only the region-alias discussion runs slightly long for a single-parameter tool.

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 full-replace tool with one deeply nested required object and no output schema, the description covers the essential missing pieces: read-before-write, omission semantics, and region-matching limits. It does not state what happens on validation failure or whether a confirmed profile is returned, but return-value disclosure is not required here.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema for the nested fields: omitted or null conditions are recorded as unconfirmed, and preference regions are alias-normalized and matched against the notice's region value by exact name. It stops short of describing how confirmedNoticeDates, asOfDate, or schemaVersion interact with the replace.

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?

"본인의 청약 조건을 검증한 뒤 프로필 전체를 교체합니다" states a specific verb (검증 후 교체), a specific resource (청약 프로필), and the crucial scope word 전체 (full replace), which separates it from the read sibling it explicitly names, housing_profile_get.

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?

It gives an explicit prerequisite workflow ("먼저 housing_profile_get으로 기존 값을 읽고"), tells the caller what to include ("사용자가 유지하려는 값을 포함해 저장하세요"), and states a pre-save check ("저장 전 공고의 지역 단위와 사용자 의도를 확인하세요"). When-to-use, how-to-prepare, and a stop condition are all present.

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

Deploy Server

Other Tools