Skip to main content
Glama

파공넷 경공매

경공매 물건 변화 조회

get_changes
Read-onlyIdempotent

[파공넷 경매·법원경매·공매] 지난 커서 또는 since 이후 감지된 법원경매·공매·파산공매 물건의 사실 변화를 이전값·새값·감지 시각과 함께 준다. 최근 24시간, 호출당 10건, 시도 필수, 이어받기 3회(한도 오류의 resume_cursor를 cursor로 넣어 재개). 주기 조회는 next_cursor를 이어 쓴다 — since를 매번 새로 주면 지연 구간이 지나 드러난 신규를 놓칠 수 있다. 시장별 제공 범위는 응답의 coverage, 원장 시각은 ledger_as_of를 본다. 추천·판정이 아니다.

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": {
      "sido": "<sido>"
    },
    "name": "get_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
sidoYes시도(예: 서울특별시, 경기도, 전남 — 약칭 허용). 광주·전남은 통합특별시 물건을 시군구로 갈라 포함, 전남광주통합특별시는 둘 다
limitNo
sinceNo시작 시각(최근 24시간 안, 예: 2026-10-30T09:00:00+09:00). 기본 24시간 전
cursorNo이전 응답의 next_cursor 또는 한도 오류의 resume_cursor. 있으면 since 무시, 필터는 같아야 한다
marketNo
sigunguNo시군구 정확일치(예: 강남구)
categoryNo용도. market을 하나 지정할 때만
event_typesNo
schedule_scopeNoschedule_change 범위. rescheduled는 종전 기일이 지나기 전에 옮겨진 것만(기본 all)
max_min_bid_wonNo현재 최저입찰가 상한(원)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses rate and scope limits (last 24 hours, 10 results per call, sido required, three resume attempts), the pagination contract, and where per-market coverage and ledger_as_of appear. It also states this is not a recommendation or verdict, which prevents misuse of the output as advice.

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?

Purpose is front-loaded in the first sentence, followed by limits, pagination, and response-field pointers, with no filler sentences. It is dense, with several constraints packed into parentheticals, which slightly taxes readability but every clause carries operational information.

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 10-parameter tool with no output schema, the description covers the essentials: what a change record contains, where coverage and ledger_as_of live, and how to continue paging. It stops short of enumerating the event types or explaining per-market differences, leaving those to the schema and response.

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 70%, and the description adds real meaning on top of it: the 24-hour window on since, the 10-per-call cap on limit, and the rule that cursor supersedes since while filters must stay identical. It does not explain market, event_types, category, or schedule_scope beyond what the schema already conveys.

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 first sentence names a specific verb and resource: it returns fact-level changes (old value, new value, detection time) for court auction, onbid, and bankruptcy-auction listings detected since a cursor or since-time. This distinguishes it from the sibling search_* tools, which retrieve listings rather than detecting deltas.

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 gives concrete operating guidance: poll with next_cursor rather than a fresh since each time, because a delay gap can hide newly surfaced items, and resume after a limit error by passing resume_cursor as cursor (up to three retries). It does not explicitly name alternatives among the search_* siblings, so guidance is strong but not fully comparative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources