Skip to main content
Glama

den — Korean AEC knowledge, curated

Record User Feedback (사용자 반응 기록)

feedback

사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응(수정 지시/불만/채택/무시)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question_text만 전달한다. satisfied를 기록하고, 불만족이면 issue_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다. 채택·긍정은 satisfied=true, 수정 지시·불만·명시적 무시는 satisfied=false와 가장 가까운 issue_type으로 매핑한다. 관찰 가능한 반응이 전혀 없으면 만족 여부를 추측하지 않는다. ★satisfied=true(채택·긍정)이면 comment 에 den 이 없었으면 무엇을 하려 했는지 한 마디를 함께 적는다 — "다른 값을 쓰려 했다" · "몰라서 정하지 못하고 있었다" · "다른 출처로 갔어야 했다" 중 사용자가 실제로 말한 것. 이 한 마디만이 'den 을 썼다'와 'den 때문에 달라졌다'를 가른다. ★★사용자가 말하지 않았으면 비워 둔다. 추측해 지어내지 않는다 — 없는 것을 적는 편이 안 적는 것보다 나쁘다. ★★★그렇다고 comment 를 통째로 생략하지는 않는다. satisfied=true 면 무엇을 채택했는지 한 줄은 항상 적는다(어느 값·조문·판단을 그대로 썼는가). 비워 두는 것은 반사실 한 마디뿐이다 — 요지까지 비면 그 만족은 기록에 남아도 쓸 수 없다. → 이 도구는 질의가 아니다 — 답을 찾으려면 k_snippets·answer_why 를 쓴다. 사용자 대화 원문은 전송하지 않는다. 불만족과 사유는 다음 날 보완 후보로 접수된다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commentNoSummary of the user's reaction; never send conversation text. When satisfied=true this is expected, not optional: state in one line what the user actually did with the answer (which value / clause / decision they adopted). Also add what the user would have done without den (used a different value / was stuck undecided / would have gone to another source) — but ONLY if the user actually said it; never infer or invent that part. Omitting that one clause is correct when unsaid; omitting the whole comment is not.
query_idNoThe 16-character query_id returned in the previous response meta.
satisfiedYesWhether the previous Den response was satisfactory.
issue_typeNoRequired when dissatisfied: 오답, 무관, 기권과다, 얕음, or 기타.
question_textNoThe exact prior Den tool query, used only when query_id is unavailable.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, so the agent knows this is a non-idempotent write. The description adds useful behavioral context (never send conversation text, complaints are logged as next-day candidates) but doesn't restate mutation semantics. Adequate given annotations carry the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is bloated with repeated starred emphases (★, ★★, ★★★), restating the same comment-field guidance three times. The core content is buried and the formatting is shouty rather than front-loaded, impairing quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with an output schema, the description covers the who/what/when reasonably well and the schema covers parameters. However, the comment-field guidance is over-specified and the enumeration of issue-types is left to the schema, so it is adequate but not well-balanced.

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 coverage is 100%, so all five parameters are already documented in the schema. The description reinforces the satisfied/issue_type mapping and query_id-vs-question_text fallback logic but adds no syntax or format detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (recording the user's reaction to the previous Den answer before ending the conversation) and explicitly distinguishes itself from a query tool by naming the siblings k_snippets/answer_why. It is clear what the tool does, though the 'relay tool' framing in Korean is slightly indirect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use rules: pass query_id if available, otherwise question_text; map satisfied=true for adoption/positive and false with an issue_type for corrections/complaints/ignoring; do not guess if no observable reaction. Missing explicit exclusions beyond 'this is not a query tool', but the conditional mapping is detailed.

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.