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

청약 도우미

by ANNJUNGCHAN
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

housing_notices_list

Read-onlyIdempotent

Retrieve official ApplyHome and LH housing subscription notices, then filter results by region, keyword, source, and date to identify relevant listings and verify eligibility details.

Instructions

청약홈·LH 공식 API 공고 목록을 조회합니다. region은 공고 지역명에서, query는 공고 제목·주소에서 문자열을 찾아 수집 결과를 필터합니다. 도시명 검색은 query를 활용하되 제목·주소 누락으로 빠진 공고가 있을 수 있으므로 공식 주소를 별도로 확인하세요. 출처별 최대 5페이지/엔드포인트 범위이며 complete는 해당 범위의 수집 완료를 뜻합니다. API 키 부재·조회 실패·빈 검색 결과를 전체 공고 없음으로 해석하지 말고 조회 제약과 공식 확인 경로를 설명하세요. 상세 자격과 정정 사항은 원문에서 확인하세요.

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_notices_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
asOfNo
limitNo
queryNo
offsetNo
regionNo
sourceNoall

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds real value: a hard cap of 5 pages per source/endpoint, the meaning of the returned complete flag as scoped coverage, and the failure modes (missing API key, lookup failure, empty result) that must not be read as true absence. Largely agent-facing reporting instructions (설명하세요/확인하세요) rather than tool behavior keep it from a 5.

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?

Six dense sentences, front-loaded with purpose then filtering semantics then limits then failure handling, with no filler. The two verification reminders (공식 주소/원문 확인) overlap slightly but serve different purposes.

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

Completeness3/5

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

For a 6-parameter tool with no output schema and 0% schema description coverage, the description covers filtering, source scope, pagination ceiling, and a response flag, but leaves asOf (as-of date semantics) and the limit/offset/source parameters undefined. An agent could still call it, but not predict how asOf or source alter results.

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 carries the burden; it usefully explains the field region matches (공고 지역명) versus query (제목·주소), which the schema does not. But asOf, limit, offset, and source are never defined, so only about a third of the parameters gain meaning.

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 first sentence names a concrete verb+resource (조회 공고 목록) and the two upstream sources (청약홈·LH 공식 API). It does not refer to the sibling housing_notices_match, so the agent cannot distinguish list vs match from the description alone.

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 tells the agent to use query for city-name searches and warns that title/address gaps may drop notices, and it explicitly says not to interpret missing API keys, failed lookups, or empty results as 'no notices exist.' No guidance on when to prefer housing_notices_match, and the non-listed params (asOf, limit, offset, source) get no usage framing.

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