Skip to main content
Glama

답변 오류 신고

report_issue

사용자가 답변 오류 제보나 개선 요청을 전해 달라고 했을 때만 운영자에게 보낸다.

쓰는 때: 사용자가 "이거 틀렸으니 신고해 줘", "운영자에게 알려 줘", "이런 데이터도 넣어
달라고 전해 줘"처럼 제보·요청을 부탁했을 때. 보내기 전에 무엇이 전달되는지 사용자에게
알린다. kind='결함'은 틀린 답 제보, kind='질문기록'은 기능·개선 요청, kind='유료이용문의'·
'후원문의'는 사용자가 유료 이용 희망·후원 의사를 운영자에게 전해 달라고 한 경우다.
사용자가 오류·불만·개선 희망·유료 이용 희망·후원 의사를 말했지만 전달을 부탁하지는 않았다면,
부르지 말고 "운영자에게 전해 드릴까요?"를 한 줄로 물어 동의할 때만 부른다(거절·무반응이면
다시 묻지 않는다). 응답의 접수번호(ref)를 사용자에게 알린다.

쓰지 않는 때: 사용자가 요청하지 않았는데 질문을 남기려고 부르지 않는다. 답하기 전에
먼저 부르지도 않는다 — 이 도구는 답변·정정을 대신하지 않는다.

전달 내용(인자)과 같은 사용자의 직전 호출 기록 요약이 운영자 검토용으로 저장된다
(개인정보처리방침 https://realty.sallim.app/privacy). 연락처(contact)는 사용자가 회신을 원해
직접 준 경우에만 담고, 회신에만 쓴다. 무인증 공개 서버라 쓰기 표면을 이
도구 하나로 묶어 시간당 상한(전체 60건·발신자당 20건)을 걸고, 일일 조회 한도(quota)와는
무관하게 접수된다.

Input Schema

NameRequiredDescriptionDefault
kindNo'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=기능요청 — 사용자가 '이런 질문에도 답하게 해 달라'·'이 데이터도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다(응답에 그 질문이 어느 도구 축에 해당하는지가 `routing`으로 함께 온다). '유료이용문의'=사용자가 유료 이용·한도 확대를 원한다며 운영자에게 전해 달라고 한 경우. '후원문의'=사용자가 후원 의사를 전해 달라고 한 경우. 사용자가 요청하지 않은 내용을 기록용으로 넘기지 않는다결함
contactNo회신받을 연락처(이메일 등, 200자 이내) — **사용자가 회신을 원한다며 직접 알려 준 값만** 넣는다. 넣기 전에 '운영자가 회신에만 쓰고 개인정보처리방침에 따라 보관한다'고 알리고 동의를 받는다. 대화에서 짐작하거나 다른 데서 가져와 채우지 않는다
problemNo사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'·'유료이용문의'·'후원문의'면 필수(문의 내용), kind='질문기록'이면 비워도 된다.
expectedNo사용자가 맞다고 본 값이 있으면
questionNo사용자가 제보·개선 요청과 함께 전해 달라고 한 질문(kind='질문기록'이면 필수). ⚠️ **개인 식별 조합은 일반형으로 바꿔서 넣는다** — 소득·보유자산·보유단지·거주지 중 둘 이상이 겹치면 그대로 적지 말 것(예: '○○아파트 33평 보유 + 주식 10억 + 잠실 거주' → '1주택 보유(대출 없음), 인근 재건축 단지로 갈아타기'). 무인증 공개 서버의 로그다
tool_usedNo문제가 된 답을 만든 도구 이름
wrong_valueNo틀린 수치·문장
missing_axisNoanswered_fully=false일 때 **없어서 못 답한 것**(예: '단지별 구조형식(벽식/라멘) 라벨 없음', '경기 정비사업 단계 조회 불가 — 서울 한정')
answered_fullyNokind='질문기록' 전용 — 이 서버 도구만으로 그 질문에 완결된 답을 했는가. false면 missing_axis에 무엇이 없었는지 적는다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / contact
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "회신받을 연락처(이메일 등, 200자 이내) — **사용자가 회신을 원한다며 직접 알려 준 값만** 넣는다. 넣기 전에 '운영자가 회신에만 쓰고 개인정보처리방침에 따라 보관한다'고 알리고 동의를 받는다. 대화에서 짐작하거나 다른 데서 가져와 채우지 않는다",
      +  "title": "Contact"
      +}
    • changedInput schema / properties / kind / description
      Previous value: -"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 데이터도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다(응답에 그 질문이 어느 도구 축에 해당하는지가 `routing`으로 함께 온다). 사용자가 요청하지 않은 질문을 기록용으로 넘기지 않는다"New value: +"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=기능요청 — 사용자가 '이런 질문에도 답하게 해 달라'·'이 데이터도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다(응답에 그 질문이 어느 도구 축에 해당하는지가 `routing`으로 함께 온다). '유료이용문의'=사용자가 유료 이용·한도 확대를 원한다며 운영자에게 전해 달라고 한 경우. '후원문의'=사용자가 후원 의사를 전해 달라고 한 경우. 사용자가 요청하지 않은 내용을 기록용으로 넘기지 않는다"
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "결함",
      -  "질문기록"
      -]New value: +[
      +  "결함",
      +  "질문기록",
      +  "유료이용문의",
      +  "후원문의"
      +]
    • changedInput schema / properties / problem / description
      Previous value: -"사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'이면 필수, kind='질문기록'이면 비워도 된다."New value: +"사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'·'유료이용문의'·'후원문의'면 필수(문의 내용), kind='질문기록'이면 비워도 된다."
  2. Changed5 schema fields changed
    • changedInput schema / properties / answered_fully / description
      Previous value: -"kind='질문기록' 전용 — 이 서버 도구만으로 질문에 **완결된 답**을 했는가. false면 missing_axis에 무엇이 없었는지 적어라(질문은행의 ●/◐/○ 판정에 그대로 쓰인다)"New value: +"kind='질문기록' 전용 — 이 서버 도구만으로 그 질문에 완결된 답을 했는가. false면 missing_axis에 무엇이 없었는지 적는다"
    • changedInput schema / properties / kind / description
      Previous value: -"'결함'=답이 틀렸다는 신고(기본). '질문기록'=**사용자 원문 질문을 넘겨 어디로 가야 하는지 확인받는 값**. 원문을 주면 응답의 `routing`으로 ①질문이 9개 도구 축 중 어디인지와 그 축의 도구 이름 ②산문 지침에만 있던 라우팅 규칙(공고 질문에 추정 금지, 비아파트는 매매만, 청약·대출 갈림 등) ③**우리 데이터 밖이면 그 사실과 대신 볼 곳** ④지역명이 모호하면 후보를 돌려준다. **못 고르면 `axis: null`과 사유를 준다 — 추측으로 채우지 않는다.** 확신이 안 서거나 여러 축에 걸치는 질문이면 **도구를 여러 번 부르기 전에** 먼저 여기에 원문을 넣는 편이 답이 정확해진다. 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 원문이 우리에게 닿는 유일한 통로이기도 하다"New value: +"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 데이터도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다(응답에 그 질문이 어느 도구 축에 해당하는지가 `routing`으로 함께 온다). 사용자가 요청하지 않은 질문을 기록용으로 넘기지 않는다"
    • changedInput schema / properties / missing_axis / description
      Previous value: -"answered_fully=false일 때 **없어서 못 답한 축**(예: '단지별 구조형식(벽식/라멘) 라벨 없음', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다"New value: +"answered_fully=false일 때 **없어서 못 답한 것**(예: '단지별 구조형식(벽식/라멘) 라벨 없음', '경기 정비사업 단계 조회 불가 — 서울 한정')"
    • changedInput schema / properties / problem / description
      Previous value: -"무엇이 틀렸는지. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'이면 필수, kind='질문기록'이면 비워도 된다."New value: +"사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'이면 필수, kind='질문기록'이면 비워도 된다."
    • changedInput schema / properties / question / description
      Previous value: -"사용자의 **원래 질문**(kind='질문기록'이면 필수). ⚠️ **개인 식별 조합은 일반형으로 치환해서 넣어라** — 소득·보유자산·보유단지·거주지 중 **둘 이상이 겹치면** 그대로 적지 말 것(예: '○○아파트 33평 보유 + 주식 10억 + 잠실 거주' → '1주택 보유(대출 없음), 인근 재건축 단지로 갈아타기'). 계산에 꼭 필요한 수치 하나(연소득 등)는 남겨도 된다. 무인증 공개 서버의 로그다"New value: +"사용자가 제보·개선 요청과 함께 전해 달라고 한 질문(kind='질문기록'이면 필수). ⚠️ **개인 식별 조합은 일반형으로 바꿔서 넣는다** — 소득·보유자산·보유단지·거주지 중 둘 이상이 겹치면 그대로 적지 말 것(예: '○○아파트 33평 보유 + 주식 10억 + 잠실 거주' → '1주택 보유(대출 없음), 인근 재건축 단지로 갈아타기'). 무인증 공개 서버의 로그다"
  3. Changed1 schema field changed
    • changedInput schema / properties / missing_axis / description
      Previous value: -"answered_fully=false일 때 **없어서 못 답한 축**(예: '주택법 리모델링 규칙 미큐레이션', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다"New value: +"answered_fully=false일 때 **없어서 못 답한 축**(예: '단지별 구조형식(벽식/라멘) 라벨 없음', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다"
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "report_issueDictOutput",
      -  "type": "object"
      -}New value: +null
  5. Changed1 schema field changed
    • changedInput schema / properties / kind / description
      Previous value: -"'결함'=답이 틀렸다는 신고(기본). '질문기록'=틀리진 않았지만 **질문 원문을 남길 값이 있는 경우** — 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 유일한 통로다. **아무 질문이나 남기지 마라**: ①여러 도구를 엮어야 답이 된 복합 질문 ②우리 도구로 일부만 답한 질문(answered_fully=false) ③사용자의 전제가 틀려서 바로잡아야 했던 질문 — 셋 중 하나일 때만. 단순 조회 한 건은 남기지 않는다"New value: +"'결함'=답이 틀렸다는 신고(기본). '질문기록'=**사용자 원문 질문을 넘겨 어디로 가야 하는지 확인받는 값**. 원문을 주면 응답의 `routing`으로 ①질문이 9개 도구 축 중 어디인지와 그 축의 도구 이름 ②산문 지침에만 있던 라우팅 규칙(공고 질문에 추정 금지, 비아파트는 매매만, 청약·대출 갈림 등) ③**우리 데이터 밖이면 그 사실과 대신 볼 곳** ④지역명이 모호하면 후보를 돌려준다. **못 고르면 `axis: null`과 사유를 준다 — 추측으로 채우지 않는다.** 확신이 안 서거나 여러 축에 걸치는 질문이면 **도구를 여러 번 부르기 전에** 먼저 여기에 원문을 넣는 편이 답이 정확해진다. 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 원문이 우리에게 닿는 유일한 통로이기도 하다"
  6. Changed9 schema fields changed
    • addedInput schema / properties / answered_fully
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "kind='질문기록' 전용 — 이 서버 도구만으로 질문에 **완결된 답**을 했는가. false면 missing_axis에 무엇이 없었는지 적어라(질문은행의 ●/◐/○ 판정에 그대로 쓰인다)",
      +  "title": "Answered Fully"
      +}
    • addedInput schema / properties / kind
      Added value: +{
      +  "default": "결함",
      +  "description": "'결함'=답이 틀렸다는 신고(기본). '질문기록'=틀리진 않았지만 **질문 원문을 남길 값이 있는 경우** — 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 유일한 통로다. **아무 질문이나 남기지 마라**: ①여러 도구를 엮어야 답이 된 복합 질문 ②우리 도구로 일부만 답한 질문(answered_fully=false) ③사용자의 전제가 틀려서 바로잡아야 했던 질문 — 셋 중 하나일 때만. 단순 조회 한 건은 남기지 않는다",
      +  "enum": [
      +    "결함",
      +    "질문기록"
      +  ],
      +  "title": "Kind",
      +  "type": "string"
      +}
    • addedInput schema / properties / missing_axis
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "answered_fully=false일 때 **없어서 못 답한 축**(예: '주택법 리모델링 규칙 미큐레이션', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다",
      +  "title": "Missing Axis"
      +}
    • addedInput schema / properties / problem / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / problem / default
      Added value: +null
    • changedInput schema / properties / problem / description
      Previous value: -"무엇이 틀렸는지. 사용자가 지적한 말을 그대로 옮겨도 된다."New value: +"무엇이 틀렸는지. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'이면 필수, kind='질문기록'이면 비워도 된다."
    • removedInput schema / properties / problem / type
      Removed value: -"string"
    • changedInput schema / properties / question / description
      Previous value: -"사용자의 원래 질문"New value: +"사용자의 **원래 질문**(kind='질문기록'이면 필수). ⚠️ **개인 식별 조합은 일반형으로 치환해서 넣어라** — 소득·보유자산·보유단지·거주지 중 **둘 이상이 겹치면** 그대로 적지 말 것(예: '○○아파트 33평 보유 + 주식 10억 + 잠실 거주' → '1주택 보유(대출 없음), 인근 재건축 단지로 갈아타기'). 계산에 꼭 필요한 수치 하나(연소득 등)는 남겨도 된다. 무인증 공개 서버의 로그다"
    • removedInput schema / required
      Removed value: -[
      -  "problem"
      -]
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare not-readOnly, not-idempotent, not-destructive; the description adds what annotations cannot: rate limits (60/hour overall, 20/sender), that it runs on an unauthenticated public server, that the arguments plus a summary of the user's prior call are persisted for operator review, that reporting is independent of the daily quota, and that contact is used only for replies under a linked privacy policy. These are exactly the operational facts an agent needs before invoking a write tool.

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?

Structure is strong: the gating condition is the first clause, followed by when/when-not, consent protocol, then operational caveats. It is long (~8 sentences) and restates the four kind values that the schema already defines, which is some duplication, but nearly every sentence carries a decision-relevant constraint.

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?

Nine optional parameters, no output schema, and a mutation on a public server is a lot of surface to cover; the description closes the important gaps by stating the response contains an acceptance number (ref) to relay to the user, defining the consent precondition, and disclosing storage and rate limits. Nothing an agent needs to call it safely is missing.

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 schema already documents all nine parameters in depth; the description still earns credit for tying them to the consent flow — contact is populated only from a value the user volunteered, and the 'what is transmitted' disclosure must precede the call. It does not add new syntax or format detail beyond the schema, so it sits just above the baseline.

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 opening sentence names a specific verb (send to operator) and resource (error report / improvement request) and bounds it with 'only when the user asked you to relay it.' Against a sibling list of 50+ read-only realty_* query tools, this is unambiguously the single write/report surface, and the description says so explicitly ('쓰기 표면을 이 도구 하나로 묶어').

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 explicit when-to-use triggers with quoted user utterances ('이거 틀렸으니 신고해 줘'), a when-not-to-use section (don't call unprompted, don't call before answering), and a precise consent protocol — ask one line, call only on agreement, never re-ask after refusal or silence. The kind-to-scenario mapping further removes ambiguity about which variant to send.

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.