청약 도우미

housing_monitoring_get

Read-onlyIdempotent

Retrieve your saved commute destination, work hours, and current housing conditions before editing them; use missingFields to identify details that still need confirmation.

Instructions

본인의 통근 목적지·출퇴근 시간·현재 주거 조건을 조회합니다. 조건을 수정하기 전에 사용하고, missingFields는 추가로 확인할 항목으로 설명하세요.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "housing_monitoring_get"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 6, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description's meaningful addition is the mention of a missingFields result concept, but it does not describe the overall return shape or what happens when the user has no saved conditions.

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?

Two short sentences: the first front-loads what is retrieved, the second carries the usage rule and the missingFields handling note. Nothing is wasted, though the phrasing of the missingFields instruction is slightly abstract without an example of its structure.

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?

With no parameters, no output schema, and full annotation coverage, the description is nearly sufficient: it enumerates the returned subject areas and flags the missingFields concept an agent must explain to the user. Only the absence of any detail on missingFields' shape across the 16 siblings keeps it from being complete.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; per baseline this lands at 4. The description correctly focuses on describing the output instead.

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 pairs a specific verb (조회합니다 / retrieve) with a specific resource (commute destination, commute hours, current housing conditions), so the agent knows exactly what data comes back. It does not differentiate itself from the closely named sibling housing_profile_get, which is a real ambiguity given both read profile-like data.

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 clear sequencing rule ('use before modifying conditions'), which implies housing_monitoring_save is the follow-up action. It stops short of naming that sibling explicitly or stating when NOT to use this versus housing_profile_get.

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

Deploy Server