Skip to main content
Glama

답변 오류 신고

report_issue

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

쓰는 때: 사용자가 "이거 틀렸으니 신고해 줘", "운영자에게 알려 줘", "이런 데이터도 넣어
달라고 전해 줘"처럼 제보·요청을 부탁했을 때. 보내기 전에 무엇이 전달되는지 사용자에게
알린다. kind='결함'은 틀린 답 제보, kind='질문기록'은 개선 요청이다.

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

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 데이터도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다(응답에 그 질문이 어느 도구 축에 해당하는지가 `routing`으로 함께 온다). 사용자가 요청하지 않은 질문을 기록용으로 넘기지 않는다결함
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. 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주택 보유(대출 없음), 인근 재건축 단지로 갈아타기'). 무인증 공개 서버의 로그다"
  2. Changed1 schema field changed
    • changedInput schema / properties / missing_axis / description
      Previous value: -"answered_fully=false일 때 **없어서 못 답한 축**(예: '주택법 리모델링 규칙 미큐레이션', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다"New value: +"answered_fully=false일 때 **없어서 못 답한 축**(예: '단지별 구조형식(벽식/라멘) 라벨 없음', '경기 정비사업 단계 조회 불가 — 서울 한정'). 로드맵의 원천이 된다"
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "report_issueDictOutput",
      -  "type": "object"
      -}New value: +null
  4. Changed1 schema field changed
    • changedInput schema / properties / kind / description
      Previous value: -"'결함'=답이 틀렸다는 신고(기본). '질문기록'=틀리진 않았지만 **질문 원문을 남길 값이 있는 경우** — 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 유일한 통로다. **아무 질문이나 남기지 마라**: ①여러 도구를 엮어야 답이 된 복합 질문 ②우리 도구로 일부만 답한 질문(answered_fully=false) ③사용자의 전제가 틀려서 바로잡아야 했던 질문 — 셋 중 하나일 때만. 단순 조회 한 건은 남기지 않는다"New value: +"'결함'=답이 틀렸다는 신고(기본). '질문기록'=**사용자 원문 질문을 넘겨 어디로 가야 하는지 확인받는 값**. 원문을 주면 응답의 `routing`으로 ①질문이 9개 도구 축 중 어디인지와 그 축의 도구 이름 ②산문 지침에만 있던 라우팅 규칙(공고 질문에 추정 금지, 비아파트는 매매만, 청약·대출 갈림 등) ③**우리 데이터 밖이면 그 사실과 대신 볼 곳** ④지역명이 모호하면 후보를 돌려준다. **못 고르면 `axis: null`과 사유를 준다 — 추측으로 채우지 않는다.** 확신이 안 서거나 여러 축에 걸치는 질문이면 **도구를 여러 번 부르기 전에** 먼저 여기에 원문을 넣는 편이 답이 정확해진다. 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 원문이 우리에게 닿는 유일한 통로이기도 하다"
  5. 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"
      -]
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare a write, non-idempotent, non-destructive operation; the description goes well beyond that by disclosing what actually gets transmitted (the args plus a summary of the user's prior calls), the privacy policy link, that this is an unauthenticated public server consolidating the write surface, and concrete rate limits (60/hour overall, 20/sender/hour) that bypass the daily read quota. That is exactly the kind of context annotations cannot convey.

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?

Front-loaded with the core rule, then cleanly sectioned into when-to-use, when-not-to-use, and what-gets-transmitted. Slightly verbose with some duplication of the kind semantics already in the schema, but every other sentence carries weight.

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?

Despite having no output schema, the definition covers the operational envelope (rate limits, storage, privacy, unauthenticated server) and even signals the routing info that comes back for '질문기록' requests. For an 8-parameter write tool, nothing an agent needs to invoke it safely is missing.

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 100% with rich per-parameter docs, so the schema already does the heavy lifting (baseline 3). The description restates the kind='결함'/'질문기록' distinction that is already in the schema and adds only that the sender's prior calls are stored, which is behavioral rather than parameter-specific.

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?

States a specific verb+resource (send a report to the operator) and immediately scopes it to user-requested error reports or improvement requests. This sharply distinguishes it from the surrounding data-retrieval siblings like search/realty_* tools, which never write. An agent can identify the operation without opening the schema.

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 '쓰는 때' vs '쓰지 않는 때' sections give the triggering condition (user asked to report) and hard exclusions (do not call before answering, do not record unrequested questions). It also states the tool does not substitute for answering or correcting. This is a complete when/when-not guide.

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.