Skip to main content
Glama

Remember a fact

remember

Record ONE thing worth keeping, in a single call.

`text` is the fact in plain language — it becomes the object's
description and is indexed for search. `class_name` says what KIND of
thing it is (decision, risk, convention, person, session_checkpoint, …);
it defaults to 'note' and a class that does not exist yet is created.
`properties` are typed fields ({"status": "accepted", "decided_on":
"2026-09-11"}), and `relationships` are edges to other objects
([{"type": "decided_by", "target": "sarah_chen"}] — add "target_class"
to create a target that isn't here yet).

Writes land `status='unapproved'`: readable at once, flagged until a
person approves them. That is deliberate — an agent proposes, a human
decides — so tell the user what you recorded rather than treating it as
settled.

Naming: omit `name` and the server derives a unique one from the text.
PASS a `name` that already exists in that class and you UPDATE that
object instead of creating a second one — that is how you revise a fact
rather than accumulate contradictions.

SESSION HANDOFF: before you run out of context, call this with
class_name="session_checkpoint" and a text saying what you did, what is
left and where you stopped. The next session's `recall` hands it straight
back.

For a whole document use the extraction pair (get_extraction_prompt →
submit_extraction_from_llm) instead — it produces many typed rows and
keeps the document on your side. Check `near_duplicates` in the response:
if what you wrote already existed, fold the pair with merge_objects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
textYes
memoryYes
class_nameNonote
propertiesNo
source_docNo
display_nameNo
relationshipsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

No annotations cover the key behaviors, and the description fills the gap richly: writes land unapproved and require human approval, name collisions cause updates rather than duplicates, new classes are auto-created, and near_duplicates in the response should be handled with merge_objects. This is exactly the behavioral context an agent needs.

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?

Front-loaded with the core action and follows a logical progression: core fields, write semantics, naming, session handoff, alternatives. Dense but every section earns its place. Slightly long, and the handoff section could be tighter, but it is well-structured and purposeful.

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?

With an output schema present, the description doesn't need to explain return values, and it still points to the one response field that matters (near_duplicates). It covers all eight parameters, behavioral semantics, routing alternatives, and a key workflow (session handoff), making it complete for a rich, non-idempotent write tool.

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 coverage is 0%, so the description carries the full burden and does so well: it explains text, class_name (with kind examples and default), properties (with a concrete example), relationships (with JSON shape and target_class behavior), and name semantics (derivation vs. update). It even covers source_doc and display_name indirectly through the update-vs-create pattern for name, though those two are less explicitly tied to their parameter names.

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 (record) and resource (one thing worth keeping), and explicitly scopes to ONE fact per call. It clearly distinguishes itself from siblings by naming the extraction pair as the alternative for whole documents.

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 explicit when-to-use guidance for session handoff, tells the agent when to use the extraction pair instead, and explains the update-vs-create rule via name collision. It also instructs the caller to report results to the user rather than treating writes as settled.

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.

Resources