Skip to main content
Glama

답변 오류 신고

report_issue

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

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

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

전달 내용(인자)과 같은 접속 주소 단위의 30분 안 직전 호출 최대 5건 요약이 운영자 검토용으로
저장된다(공유 망 뒤에서는 다른 사용자의 호출이 섞일 수 있다 · 주소 단위를 못 가리면 싣지 않는다)
(개인정보처리방침 https://stay.sallim.app/privacy). 연락처(contact)는 사용자가 회신을 원해
직접 준 경우에만 담고, 그 건의 회신에만 쓴다. 무인증 공개 서버라 쓰기 표면을 이 도구
하나로 묶어 시간당 상한을 건다(CLAUDE.md 규칙 2).

Input Schema

NameRequiredDescriptionDefault
kindNo'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. '유료이용문의'=사용자가 유료 이용·한도 확대를 원한다며 운영자에게 전해 달라고 한 경우. '후원문의'=사용자가 후원 의사를 전해 달라고 한 경우. 사용자가 요청하지 않은 내용을 기록용으로 넘기지 않는다결함
contactNo회신받을 연락처(이메일 등, 200자 이내) — **사용자가 회신을 원한다며 직접 알려 준 값만** 넣는다. 넣기 전에 '운영자가 회신에만 쓰고 개인정보처리방침에 따라 보관한다'고 알리고 동의를 받는다. 대화에서 짐작하거나 다른 데서 가져와 채우지 않는다
problemNo사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'·'유료이용문의'·'후원문의'면 필수(문의 내용), kind='질문기록'이면 비워도 된다.
expectedNo사용자가 맞다고 본 값
questionNo사용자가 제보·개선 요청과 함께 전달하기로 한 질문(kind='질문기록'이면 필수). 이름·연락처·정확한 거주지 같은 개인 식별 정보는 빼고 일반형으로 적는다(예: '○○동 △△빌라 사는 김□□, 부모님 팔순으로 속초 2박' → '가족 3인 속초 2박'). 무인증 공개 서버의 로그다
tool_usedNo문제가 된 답을 만든 도구
wrong_valueNo틀린 수치·문장
missing_axisNoanswered_fully=false일 때 **없어서 못 답한 것**(예: '실시간 빈방', '가격대 필터 없음', '반려동물 동반 가능 여부 미수록')
answered_fullyNokind='질문기록' 전용 — 이 서버 도구만으로 그 질문에 완결된 답을 했는가. false면 missing_axis에 무엇이 없었는지 적는다

Output Schema

NameRequiredDescriptionDefault

No arguments

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: -"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. 사용자가 요청하지 않은 질문을 기록용으로 넘기지 않는다"New value: +"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. '유료이용문의'=사용자가 유료 이용·한도 확대를 원한다며 운영자에게 전해 달라고 한 경우. '후원문의'=사용자가 후원 의사를 전해 달라고 한 경우. 사용자가 요청하지 않은 내용을 기록용으로 넘기지 않는다"
    • 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: -"'결함'=답이 틀렸다는 신고(기본). '질문기록'=틀리진 않았지만 **질문 원문을 남길 값이 있는 경우** — 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 유일한 통로다. **아무 질문이나 남기지 마라**: ①여러 도구를 엮어야 답이 된 복합 질문 ②우리 도구로 일부만 답한 질문(answered_fully=false) ③사용자의 전제가 틀려서 바로잡아야 했던 질문(예: '펜션'을 법적 업종명으로 알고 있던 경우) — 셋 중 하나일 때만. 단순 조회 한 건은 남기지 않는다"New value: +"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. 사용자가 요청하지 않은 질문을 기록용으로 넘기지 않는다"
    • 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='질문기록'이면 필수). ⚠️ **개인 식별 조합은 일반형으로 치환해서 넣어라** — 이름·연락처·정확한 거주지·동행자 사연이 겹치면 그대로 적지 말 것(예: '○○동 △△빌라 사는 김□□, 부모님 팔순으로 속초 2박' → '가족 3인 속초 2박'). 무인증 공개 서버의 로그다"New value: +"사용자가 제보·개선 요청과 함께 전달하기로 한 질문(kind='질문기록'이면 필수). 이름·연락처·정확한 거주지 같은 개인 식별 정보는 빼고 일반형으로 적는다(예: '○○동 △△빌라 사는 김□□, 부모님 팔순으로 속초 2박' → '가족 3인 속초 2박'). 무인증 공개 서버의 로그다"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important side effects: the submitted content and a 30-minute summary of up to five recent calls are stored for operator review, contact info is used only for replies, and an hourly rate limit applies on an unauthenticated public server. These details materially help the agent understand privacy and operational consequences.

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 long but front-loads the critical condition in bold, then separates when-to-use, when-not-to-use, and data-handling notes. Some repetition exists around consent and user requests, but the length is justified by the privacy and safety constraints.

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 mutation tool with privacy, consent, and rate-limit implications, the description covers invocation conditions, consent flow, side effects, data retention, and authentication context. The output schema exists and the description still usefully notes that ref and reply_path should be shown to the user.

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%, and the input schema already provides rich per-field guidance for kind, contact, problem, question, and the other arguments. The description adds high-level meaning for kind and contact handling, but it largely repeats what the schema already documents rather than adding new parameter-level detail.

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 states a specific action: forwarding an answer-error report, improvement request, or inquiry to the operator only when the user asks. It clearly distinguishes this from answering questions directly and from silently logging feedback.

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, when-not-to-use conditions, and a consent protocol: do not call unless the user asks, ask once before sending, and do not ask again after refusal or silence. This leaves little ambiguity for an agent deciding whether to invoke the tool.

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