Skip to main content
Glama

오류·개선 제보

report_issue

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

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

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

전달 내용(인자)과 같은 사용자의 직전 도구 호출 요약(서버 기록)이 운영자 검토용으로
저장된다(개인정보처리방침 https://contract.sallim.app/privacy). 개인 식별 정보(기관명·
사건번호·금액 조합 등)는 일반형으로 바꿔 적는다. 연락처(contact)는 사용자가 회신을 원해
직접 준 경우에만 담고, 그 건의 회신에만 쓴다.

Args:
    category: "wrong_citation"(오인용) | "outdated_law"(개정 미반영) |
        "wrong_ruling"(룰엔진 오판정) | "tool_error"(도구 오류) |
        "feature_request"(기능 요청) | "question_log"(사용자가 전해 달라고 한, 답하지
        못한 질문) | "other" | "usage_inquiry"(이용문의 — 기관 도입·대량 이용 등 이용
        방식을 운영자와 상의하고 싶다며 전해 달라고 한 경우) | "sponsor_inquiry"(후원문의 —
        후원 의사를 전해 달라고 한 경우)
    message: 사용자가 전해 달라고 한 내용 — 무엇이 어떻게 잘못됐는지, 어떤 질문에
        답하지 못했는지, 또는 문의 내용
    related_tool: 문제가 난 도구명 (예: "search_references")
    related_query: 문제를 재현하는 질의·입력
    expected: 올바르다고 생각하는 값·조문 (알고 있다면)
    contact: 회신받을 연락처(이메일 등, 200자 이내) — **사용자가 회신을 원한다며 직접
        알려 준 값만** 넣는다. 넣기 전에 '운영자가 회신에만 쓰고 개인정보처리방침에 따라
        보관한다'고 알리고 동의를 받는다. 대화에서 짐작하거나 다른 데서 가져와 채우지 않는다

Input Schema

NameRequiredDescriptionDefault
contactNo
messageYes
categoryYes
expectedNo
related_toolNo
related_queryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / category / enum
      Previous value: -[
      -  "wrong_citation",
      -  "outdated_law",
      -  "wrong_ruling",
      -  "tool_error",
      -  "feature_request",
      -  "question_log",
      -  "other"
      -]New value: +[
      +  "wrong_citation",
      +  "outdated_law",
      +  "wrong_ruling",
      +  "tool_error",
      +  "feature_request",
      +  "question_log",
      +  "other",
      +  "usage_inquiry",
      +  "sponsor_inquiry"
      +]
    • addedInput schema / properties / contact
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Contact"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / category / enum
      Previous value: -[
      -  "wrong_citation",
      -  "outdated_law",
      -  "wrong_ruling",
      -  "tool_error",
      -  "feature_request",
      -  "other"
      -]New value: +[
      +  "wrong_citation",
      +  "outdated_law",
      +  "wrong_ruling",
      +  "tool_error",
      +  "feature_request",
      +  "question_log",
      +  "other"
      +]
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and non-destructive; the description adds substantial context beyond that: both the arguments and the user's prior tool-call summary are persisted server-side for operator review, a privacy policy URL is given, PII must be generalized, and the user must be told what will be sent. It also discloses the response shape (ref number and reply_path) and the contact-handling rule.

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?

It is long but well-organized: front-loaded purpose, then '쓰는 때' / '쓰지 않는 때' sections, then an args block. A few sentences restate the same prohibition (don't call unprompted / don't call before answering), which is mild redundancy for a tool this consequential.

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 6-parameter write-ish tool with no output schema, the description covers invocation conditions, consent flow, data-persistence notice, PII handling, and return fields (ref, reply_path). Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden — and it does: every one of the six parameters is explained, all nine category enum values are glossed in Korean, contact has a 200-character limit plus a consent prerequisite, and related_tool/related_query/expected are tied to reproduction of the problem.

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 first line states a specific verb+resource+scope: relay bug reports/improvement requests/inquiries to operators, and only when the user explicitly asks. This clearly separates it from the sibling tools (search_law, get_case, estimate_delay_penalty, etc.), which are legal-research/calculation tools rather than feedback channels.

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 ("신고해 줘", "운영자에게 알려 줘") and explicit 'when not to use' rules (don't call just to leave a question; don't call before answering). It also specifies the consent fallback — ask "운영자에게 전해 드릴까요?" once and don't re-ask on refusal — which is exactly the routing logic an agent needs.

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.