Skip to main content
Glama

contract-compass

by build.naru
OverviewDiscussionsAdmin

오류·개선 제보

report_issue

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

쓰는 때: 사용자가 "이 조문 인용이 틀렸으니 신고해 줘", "운영자에게 알려 줘", "이런 질문도
답하게 해 달라고 전해 줘"처럼 제보·요청을 부탁했을 때. 보내기 전에 무엇이 전달되는지
사용자에게 알린다.

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

전달 내용(인자)과 같은 사용자의 직전 도구 호출 요약(서버 기록)이 운영자 검토용으로
저장된다(개인정보처리방침 https://contract.sallim.app/privacy). 개인 식별 정보(기관명·
사건번호·금액 조합 등)는 일반형으로 바꿔 적는다.

Args:
    category: "wrong_citation"(오인용) | "outdated_law"(개정 미반영) |
        "wrong_ruling"(룰엔진 오판정) | "tool_error"(도구 오류) |
        "feature_request"(기능 요청) | "question_log"(사용자가 전해 달라고 한, 답하지
        못한 질문) | "other"
    message: 사용자가 전해 달라고 한 내용 — 무엇이 어떻게 잘못됐는지, 또는 어떤 질문에
        답하지 못했는지
    related_tool: 문제가 난 도구명 (예: "search_references")
    related_query: 문제를 재현하는 질의·입력
    expected: 올바르다고 생각하는 값·조문 (알고 있다면)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYes
categoryYes
expectedNo
related_toolNo
related_queryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+]
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only convey the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds substantial behavior beyond that: transmitted arguments and the prior tool-call summary are retained for operator review, the privacy policy is linked, PII must be genericized, and the user must be told before sending. This is rich, non-obvious context.

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 consent condition and organized into clear sections (when to use / when not to use / what is transmitted / args). It is slightly repetitive — the when-not-to-use block restates the 'only when the user asked' rule already stated up front — but the redundancy serves a safety gate, so it is only mildly wasteful.

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?

No output schema exists, and for a fire-and-forget submission tool the description covers everything an agent needs: the consent prerequisite, what data is retained and where it goes, and PII handling. Nothing required to invoke 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 must carry the full burden, and it does: every one of the 5 parameters is explained with meaning, the category enum values are glossed in Korean with parenthetical definitions, and related_tool is given a concrete example. This fully compensates for the empty schema.

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 verb (report/submit an error or improvement request) and resource (to the operator), which is unambiguous and clearly distinct from all sibling tools that are legal search/lookup operations. It even names the exact trigger condition, so an agent can select it 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 when-to-use (user asks to relay a report/request, with concrete example phrasings) and when-not-to-use (do not call for unanswered questions the user did not ask to forward, and do not call before answering). This is a genuine exclusion set plus alternatives, exactly the top of the scale.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All contract-compass toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources