Skip to main content
Glama

답변 오류 신고

report_issue

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

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

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

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

Input Schema

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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

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: -"'결함'=답이 틀렸다는 신고(기본). '질문기록'=틀리진 않았지만 **질문 원문을 남길 값이 있는 경우** — 서버는 클라이언트가 번역한 도구 호출만 보고 원문 질문을 볼 수 없어서, 이게 유일한 통로다. **아무 질문이나 남기지 마라**: ①여러 도구를 엮어야 답이 된 복합 질문 ②우리 도구로 일부만 답한 질문(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박'). 무인증 공개 서버의 로그다"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds substantial context beyond that: retained data (arguments plus a 30-minute, 5-call summary scoped to the same access address), a shared-network caveat, an unauthenticated public-server warning, an hourly rate limit, and a privacy-policy link.

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 gating condition and organized under clear headers, so the agent hits the critical constraint first. It runs somewhat long and the trailing parentheticals (shared-network mixing, CLAUDE.md rule 2) are dense, but each section carries actionable information.

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?

An output schema exists, so return values need no explanation. Given the mutation nature and zero required parameters, the description still covers authorization triggers, prohibited uses, retention/privacy, and rate limits — everything an agent needs to call it safely.

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%, so the enum semantics of kind and the required/optional rules for problem and question are already fully documented in the schema. The description's 'kind=결함은 틀린 답 제보' line restates that schema text rather than adding new syntax or format detail, so baseline 3 applies.

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 and resource — relaying a user's error report or improvement request to the operator — and makes the trigger condition unmistakable. It is trivially distinguishable from the read-only stay_* siblings, which retrieve lodging data rather than write an operator report.

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?

Explicitly partitions behavior: a dedicated '쓰는 때' section with quoted user phrasings that authorize the call, and a '쓰지 않는 때' section forbidding calls the user did not request or calls made before answering. Alternatives and exclusions are both named, leaving nothing to inference.

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