Skip to main content
Glama
dreamd

dreamd

append_node

Captures a user correction, decision, or note as a raw episodic event in shared filesystem-backed agent memory for cross-session recall.

Instructions

Append a raw episodic event -- use when: the user corrects you, the user states a decision, note that, remember, log this, save this lesson. Writes AGENT_LEARNINGS.jsonl, not LESSONS.md; lessons come from the dream cycle. Put the user's own words in content. One precise event beats several vague ones.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "content": "<content>",
      "source_harness": "<source_harness>",
      "skill_action": "<skill_action>"
    },
    "name": "append_node"
  }
}

Input Schema

NameRequiredDescriptionDefault
painNoPain score 0–10: how disruptive was this if not known?
contentYesThe learning content to store.
importanceNoImportance score 0–10: how broadly applicable is this?
skill_actionYesClustering key describing the skill or action domain (e.g. "rust::async::tokio"). Lowercase `[a-z0-9_]` segments joined by `::` -- no dots, hyphens, or slashes.
source_harnessYesThe agent harness that produced this learning (e.g. "claude-code").
client_dedup_keyNoOptional idempotency key. Duplicate calls with the same key return the cached id without a second write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.4/5.0
Behavior4/5

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

No annotations exist, so the description carries the burden and does disclose real behavior: the concrete write target file, the exclusion of LESSONS.md, and quality guidance ("One precise event beats several vague ones"). It omits what a call returns (no output schema exists, so an id/confirmation note would have helped) and says nothing about idempotency beyond what the schema already covers.

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

Conciseness5/5

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

Extremely dense and front-loaded: verb+resource first, then triggers, then the file-target disambiguation, then content advice. Every clause carries distinct information; nothing is padded.

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

Completeness4/5

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

For a 6-parameter write tool with no annotations and no output schema, the description covers purpose, triggers, destination, and content quality. The remaining gap is the return behavior of the call, which an agent may want when chaining calls.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description earns above that by adding semantic guidance for the key field ("Put the user's own words in content") and a granularity rule for how much to pack into one call. It adds nothing for pain/importance/skill_action, which the schema already documents well.

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?

States a specific verb and resource ("Append a raw episodic event") and pins the exact artifact written ("Writes AGENT_LEARNINGS.jsonl, not LESSONS.md"). That framing cleanly separates it from the sibling search_nodes, which reads rather than appends.

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?

Provides explicit trigger phrases ("the user corrects you, the user states a decision, note that, remember, log this, save this lesson") and a negative boundary (lessons come from the dream cycle, not this tool). It stops short of naming any alternative write path, so it is strong context without full when/when-not/alternatives coverage.

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

Deploy Server

Other Tools