Skip to main content
Glama

Save a note

save_memory

Stores a project session note capturing what was done, decided, or found, so coding agents can recall narrative context across sessions.

Instructions

Save a session note (what was done, decided or found) for this project. Use remember for durable facts; use this for narrative.

Input Schema

NameRequiredDescriptionDefault
tagsNoComma-separated
typeNoOne of task_completed, decision, note, change, issue, discovery; anything else is stored as a note. Default note
scopeNoDefault project: visible from every branch
titleNoOne-line summary; derived from the content when omitted
contentYesDetails

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare this is a non-destructive, non-open-world write, so safety is covered. The description adds the qualitative nature of what lands in storage (narrative session note vs durable fact), which is genuinely useful. It doesn't say whether notes are later retrievable via recall/what_do_i_know or how they interact with correct_fact/worklog, so a 3 is right.

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?

Two short sentences with zero waste, and the core purpose comes first ahead of the sibling disambiguation. Nothing to trim.

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 five-parameter, single-required-field write tool with annotations and no output schema, the definition is nearly sufficient. The one missing piece is the read-side pairing — telling the agent that saved notes surface through recall/what_do_i_know — which would close the loop with a very crowded sibling set.

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 the schema already explains tags, type, scope, title and content; baseline 3 applies. The description adds only a loose mapping from 'done, decided or found' to the type enum values, which is marginal but nonzero added meaning.

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 ('Save a session note') and defines the payload semantically ('what was done, decided or found'). It also names the sibling it is not (remember), so an agent can separate the two note-writing tools without reading either 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?

Gives an explicit routing rule: 'Use remember for durable facts; use this for narrative.' That names the alternative and the condition that selects it, which is exactly the decision an agent has to make among the memory siblings. The only gap is that it doesn't mention which tool reads these notes back (recall/what_do_i_know), but the write-side choice is fully covered.

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