Send user feedback on an agent's action to shape future behavior choices. Choose praise, scold, poke, hug, or ignore, and specify the action name for accurate preference learning.
用户对 PASM 行为的反馈，会塑形后续动作选择。kind: praise(夸奖)/scold(责怪)/poke(调侃)/hug(安慰)/ignore(无视)。必须尽量带 action（被评价的那个动作名），否则偏好会集中在某一个动作上。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| action | No | 被反馈的动作名，强烈建议传 | |
| agent_id | No | default |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that feedback shapes future action selection, and warns about the consequence of omitting 'action' (preferences concentrate on a single action). This is valuable transparency about the tool's side effects, though it doesn't mention persistence, scope (per-agent), or other potential effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences deliver the purpose, the kinds, and the critical usage warning. No fluff, no repetition of schema details already present. The most important guidance (must include action) is front-loaded in the second sentence, making it highly readable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a feedback-recording tool with no output schema and a simple parameter set, the description is complete. It explains what the tool does, what kinds exist, what the critical parameter is and why, and the effect on future behavior. An agent has everything needed to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'action' as 'strongly recommended', and 'kind' has an enum. The description adds value beyond the schema by explaining why 'action' is critical (prevents preference concentration) and by listing the five kinds in prose. Given schema coverage is only 33%, the description compensates meaningfully for the undocumented 'agent_id' and reinforces the purpose of 'kind'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb (feedback) and resource (PASM behavior), and explains the effect (shapes subsequent action selection). It also enumerates the kinds (praise/scold/poke/hug/ignore), making the tool's purpose unmistakable. While it doesn't name a specific sibling, the unique role of collecting user feedback is unambiguous within the pasm_* suite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to always include the 'action' parameter to avoid preference concentration – this is usage guidance for parameters. It doesn't explicitly state when to use this tool versus alternatives, but the purpose (feedback) is so distinct from siblings like pasm_act or pasm_chat that the intended context is obvious. The lack of a when-not clause is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.