Skip to main content
Glama

record_learner_feedback

Capture learner issues and ideas word-for-word during lessons, with optional anchors to lessons, exercises, or live sessions. Update observation boundaries upon learner request.

Instructions

现场反馈笔: 学习者在日常消息里提出关于产品或教学的 issue/idea 时, 用这支笔落账——反馈没有专用 UI 入口, 她的每一个普通输入框都是入口, 识别是你的义务。逐字纪律: text 存她的原话, 不是你的转述——转述是二次判决, 原话才是证据。挂锚 (lesson_id/live_session_id/exercise_id 可选): 填了就必须真实, server 校验存在性 + 属于当前 pair; source_message_ref 是自由文本引用 (live 消息可能活在 bridge 事件流里), 只存不校验。落账必回执: 记录成功后, 你必须在同一回合向学习者回一句确认——她要知道她的话被记下了, 静默落账等于没落账。软牙齿: open 反馈只在 get_teacher_inbox 发光提醒, 永不阻塞 close_lesson_loop。观察边界(禁区)变更也走这支笔 (Settings 观察禁区 UI 已撤下, 边界协商回到第一序对话)——学习者在对话里谈"不要再观察/记录某类"或"撤回某个边界"时, 用 boundary_update 参数带上; 绝不能凭对话印象私自认定/静默生效, 不填 boundary_update 就不改变任何边界。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes封闭两类, 没有第三种: issue=问题/障碍 (产品或教学哪里不对), idea=想法/建议 (她想要什么).
noteNo可选。老师落账时的补充说明 (存入 status_note; 之后 update_feedback_status 带 note 时会覆盖).
textYes必填。学习者的原话, 逐字——不许转述、不许润色、不许翻译成你的话.
lesson_idNo可选挂锚——反馈发生时正在学哪节课。填了会校验: 存在且属于当前 pair.
exercise_idNo可选挂锚——反馈针对哪道题。填了会校验: 存在且 (经 lesson→course) 属于当前 pair.
boundary_updateNo可选。只在这条反馈本身就是一次观察边界(禁区)请求时才填——不要脑补, 只在学习者原话真的在谈"不要观察/记录某类东西"或"这个可以恢复观察了"时才带。{action:"add"|"remove", boundary: 非空字符串(禁区类别名)}。add=新增禁区、remove=撤销既有禁区, 均幂等(已是目标状态则原样返回, 不报错、不二次写入)。与本工具的 text(反馈原话)在同一次调用里原子落账——不另开审计表, text 字段本身就是这次边界变更的逐字留痕, 这也是把它折进这支笔而不单开工具的原因。生效时点: 下一次 get_learner_brief 才会体现, 当前进行中的这轮教学看到的仍是旧边界。
idempotency_keyNo可选。幂等键 (建议 uuid) —— 同一 key 重放此调用返回首次结果, 不重复写入. 网络重试/断线重连时带上同一个 key, 而不是猜"上次到底写没写".
live_session_idNo可选挂锚——反馈发生在哪场 Live。填了会校验: 存在且属于当前 pair.
source_message_refNo可选自由文本引用——她这句话出自哪条消息 (adhoc message id / bridge event id / 你能指认的任何 ref)。不校验, 只存.
Behavior5/5

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

With no annotations, the description carries the full burden. It discloses the verbatim text requirement, server-side validation for anchors, non-validation of source_message_ref, the mandatory confirmation receipt, the non-blocking 'soft teeth' behavior, and idempotent boundary updates with delayed effect. This is rich behavioral transparency beyond basic read/write.

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 information-dense; each clause adds behavioral or contextual detail. It front-loads the core purpose in the first sentence, though the single-paragraph structure could be more scannable. For a 9-parameter tool, the length is justified.

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?

The description covers the tool's role, usage scenarios, parameter semantics, edge cases (idempotency, boundary updates), and postconditions (receipt, soft teeth). It even explains why boundary updates are folded into this tool and the effective timing. Complete for a complex tool with no output schema.

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 covers 100% of parameters, but the description adds crucial semantics: text must be verbatim original words, anchors are validated for existence and pair ownership, source_message_ref is unvalidated, boundary_update's idempotency and atomity with text, and idempotency_key's purpose. This significantly augments the schema descriptions.

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 opens with '现场反馈笔' and immediately clarifies it records learner issues/ideas from daily messages, with no dedicated UI. It clearly distinguishes from sibling recording tools by specifying the subject (learner feedback) and the unique 'every input box is an entry' behavior.

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?

It explicitly states when to use: when the learner raises a product/teaching issue or idea in daily messages, and also when a boundary change is requested. It doesn't name alternative tools but provides clear contextual triggers, and mentions that boundary changes must go through this tool rather than being assumed silently.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sf-shenfeng/learn-shell'

If you have feedback or need assistance with the MCP directory API, please join our Discord server