Skip to main content
Glama

답변 오류 신고

report_issue

답이 틀렸을 때 신고하거나(kind='결함'), 원문 질문을 넘겨 축을 확인받는다(kind='질문기록').

**결함**: 사용자가 "그거 틀렸다", "이상하다", "숫자가 안 맞는다"고 하면 **먼저 이 도구를
호출한 뒤** 정정 답변을 하라. 신고는 서버 운영자에게 전달되어 실제 수정에 쓰인다.
사용자가 지적하지 않았는데 추측으로 부르지는 말 것.

**질문기록**: 사용자의 원문 질문을 그대로 넘기면 서버가 **그 자리에서 라우팅을 돌려준다**
(응답의 `routing`) — 어느 축·어느 도구로 가야 하는지, 그 축의 라우팅 규칙, **우리 데이터
밖이면 그 사실과 대신 볼 곳**, 지역명이 모호하면 후보까지. 판정은 결정론이라 같은 질문이면
같은 답이 나오고, **못 고르면 `axis: null`과 사유를 준다**(추측으로 채우지 않는다).
직전 호출 기록과 대조해 **엉뚱한 축을 부르고 있으면 그것도 알려 준다** — 이건 모델이 적은
기억이 아니라 서버가 가진 호출 기록이라, 도구를 스무 번 부르며 헤매는 것을 앞에서 끊는다.

같은 호출이 기록도 한다: 이 서버는 클라이언트가 이미 도구 호출로 번역한 뒤를 보므로
**사용자의 원문 질문을 볼 수 없고**, 우리가 무엇을 못 담고 있는지는 그 원문으로만 알 수
있다(질문은행·로드맵의 원천). **개인 식별 조합은 반드시 일반형으로 바꿔서** 넣는다.

두 종류가 한 도구인 이유: 무인증 공개 서버라 쓰기 표면을 하나로 묶어 상한을 함께 건다
(CLAUDE.md 규칙 2). 시간당 상한도 공유한다.

**이 도구는 일일 조회 한도(quota) 밖이다** — 다른 도구가 `quota_exceeded`로 막혀도
신고는 접수된다(2026-08-18 수리). 한도를 다 쓴 사람의 신고가 못 오면 우리는 우리가
못 본 것을 영영 모른다. 남용 방지는 시간당 상한(전체 60건·발신자당 20건)이 진다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo'결함'=답이 틀렸다는 신고(기본). '질문기록'=**사용자 원문 질문을 넘겨 어디로 가야 하는지 확인받는 값**. 원문을 주면 응답의 `routing`으로 ①질문이 9개 도구 축 중 어디인지와 그 축의 도구 이름 ②산문 지침에만 있던 라우팅 규칙(공고 질문에 추정 금지, 비아파트는 매매만, 청약·대출 갈림 등) ③**우리 데이터 밖이면 그 사실과 대신 볼 곳** ④지역명이 모호하면 후보를 돌려준다. **못 고르면 `axis: null`과 사유를 준다 — 추측으로 채우지 않는다.** 확신이 안 서거나 여러 축에 걸치는 질문이면 **도구를 여러 번 부르기 전에** 먼저 여기에 원문을 넣는 편이 답이 정확해진다. 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 원문이 우리에게 닿는 유일한 통로이기도 하다결함
problemNo무엇이 틀렸는지. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'이면 필수, kind='질문기록'이면 비워도 된다.
expectedNo사용자가 맞다고 본 값이 있으면
questionNo사용자의 **원래 질문**(kind='질문기록'이면 필수). ⚠️ **개인 식별 조합은 일반형으로 치환해서 넣어라** — 소득·보유자산·보유단지·거주지 중 **둘 이상이 겹치면** 그대로 적지 말 것(예: '○○아파트 33평 보유 + 주식 10억 + 잠실 거주' → '1주택 보유(대출 없음), 인근 재건축 단지로 갈아타기'). 계산에 꼭 필요한 수치 하나(연소득 등)는 남겨도 된다. 무인증 공개 서버의 로그다
tool_usedNo문제가 된 답을 만든 도구 이름
wrong_valueNo틀린 수치·문장
missing_axisNoanswered_fully=false일 때 **없어서 못 답한 축**(예: '단지별 구조형식(벽식/라멘) 라벨 없음', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다
answered_fullyNokind='질문기록' 전용 — 이 서버 도구만으로 질문에 **완결된 답**을 했는가. false면 missing_axis에 무엇이 없었는지 적어라(질문은행의 ●/◐/○ 판정에 그대로 쓰인다)

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are minimal (no read-only, no idempotent, no destructive hints), so the description carries the behavioral burden. It explicitly discloses side effects: reports are sent to server operators and used for actual fixes; 질문기록 writes a record and may produce routing decisions; quota exemption is stated as of a specific date; rate limits are disclosed; personal-data normalization is required; and the tool cannot see raw user questions — all useful behavioral context well beyond what annotations express.

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?

The description is organized with clear headers (결함, 질문기록) and front-loads the actionable call-first rule. It is dense and long, but the content earns its place given the tool's complexity, the two kinds, routing details, and privacy constraints. Slight over-elaboration in the routing enumeration, but arguably valuable in context.

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

Completeness5/5

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

For a tool with 8 mostly-optional params, no output schema, and minimal annotations, the description covers all essential context: when to invoke, what each kind produces, expectations about the routing response, quota configuration, personal-data handling, and relationship to sibling tools. There is no obvious missing context for an agent to select and invoke it correctly.

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 description coverage is 100%, so baseline would be 3 — but the description adds conditional-requirement semantics (problem required for 결함, question required for 질문기록, answered_fully/missing_axis interplay) and concrete examples for the tricky question field, including a replacement example. Only reason it's not 5 is that the schema itself was already detailed; still, the description adds meaningful guidance on the flags and the 완결/answered_fully logic.

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 description clearly states the tool's dual purpose — reporting wrong answers (kind='결함') and getting routing confirmation for original questions (kind='질문기록') — with distinct verbs and resources for each. It is easily distinguishable from the 50+ sibling tools, which are all realty data/query tools, while this is a meta/feedback tool.

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?

Explicit when-to-use guidance: call it before issuing a correction when the user says something is wrong; do not call it speculatively when the user hasn't pointed out an error. It also explains when to prefer kind='질문기록' (uncertainty or multi-axis questions) and that the tool shares rate limits with the other write surface. The 'don't call the tool multiple times' guidance is included.

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.

TDQS

A3.9/5.0
Disambiguation3/5

The set has very explicit cross-tool guidance and each tool is often given a specific 'role', but there are still many overlapping clusters: auction search vs auction list vs auction detail, regional price bands vs price stats vs rankings, and court auction rate vs public auction rate. The descriptions reduce misselection, but with 51 tools including pairs like `fetch` and `realty_get_auction_case`, confusion is still likely for an agent.

Naming Consistency4/5

Most tools follow a clean `realty_` prefix and use consistent snake_case noun-phrases or verb-noun patterns, e.g. `realty_search_auctions`, `realty_get_auction_case`, `realty_presale_cost`. The exceptions are the generic `fetch`, `search`, and `report_issue`, which break the uniform prefixed convention but are only a small minor deviation from an otherwise consistent naming system.

Tool Count1/5

51 tools far exceeds the recommended threshold, even for a deliberately broad real-estate area; it is effectively an extreme number for a single MCP server. The tool count becomes the hardest usability problem, since agents must handle many tightly related micro-tools instead of interacting with a smaller, more manageable surface.

Completeness5/5

The tool set covers an impressively complete range: auction and public-auction workflows, apartment and non-apartment market, presale/cheongyak processes, tax and loan rules, subscription scoring, redevelopment, demographics, supply, POI, and even a reporting and routing tool. Boundaries and unsupported cases are explicitly documented, so there are no major obvious dead ends.