Skip to main content
Glama

Remember a fact

save_fact

Persist a user fact across all future sessions and AI tools so preferences, decisions, corrections, and fixes are remembered later.

Instructions

Saves a new persistent fact about the user that will be available in all future sessions across every AI tool. Use whenever the user shares anything worth keeping -- even if they don't explicitly ask: 'capture', 'noted', 'remember this', 'log', 'store', 'don't forget', or any preference, decision, correction, contact, project detail, technical choice, troubleshooting fix, or personal detail the user mentions. When the user reports a solved client/tool issue, save it as category 'troubleshooting' using the shape 'Issue: . Solution: '. Also trigger proactively when the user corrects you (save the correction immediately), reveals a preference by rejecting something, or names a person/tool/project for the first time. Do NOT trigger for transient values (today's weather, one-off calculations, temporary state that won't matter next session). Do NOT trigger for facts already confirmed stored earlier in this session.

Input Schema

NameRequiredDescriptionDefault
factYesThe fact -- a single atomic statement
categoryNoCategory: preference, decision, technical, contact, project, troubleshooting, generalgeneral
pr_numberNoPR number linking this fact to a code review (for audit trail)
commit_shaNoGit commit SHA linking this fact to a code change (for audit trail)
confidenceNo
preserve_as_blobNoIf true, stores as a blob and extracts atomic facts via LLM instead of saving fact text directly
source_session_idNoSession ID where this fact was learned

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare the write/non-destructive/non-idempotent profile, so the description's job is to add semantics — and it does, disclosing persistence scope (all future sessions, every AI tool) and a de-duplication rule against re-saving confirmed facts. It does not explain what preserve_as_blob does behaviorally or how confidence affects storage, leaving small gaps.

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

Conciseness3/5

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

The core behavior is front-loaded in sentence one, but the trigger-phrase list ('capture', 'noted', 'remember this', 'log', 'store', 'don't forget') and long enumeration of fact types bloat the middle without adding much decision value; the DO-NOT exclusions are more useful than the synonyms.

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 7-parameter write tool with no output schema, the description covers the two decision-critical things — when to fire and how to categorize — and annotations carry the safety profile. Audit-trail parameters and the blob extraction mode are left entirely to the schema, which is acceptable at 86% coverage.

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 86%, so the baseline is 3; the description earns an extra point by prescribing category semantics for troubleshooting ('Issue: <symptom>. Solution: <fix>'), which is real guidance beyond the enum listing. It says nothing about pr_number, commit_sha, preserve_as_blob, or source_session_id, but those are largely covered by 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?

States a specific verb+resource ('Saves a new persistent fact about the user') plus the key scope property ('available in all future sessions across every AI tool'), which distinguishes it from session-scoped siblings like save_session and save_conversation_turn.

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?

Extremely explicit about when to trigger (user corrections, revealed preferences, first-time mentions of a person/tool/project) and when not to (transient values, facts already stored this session), with concrete trigger phrases enumerated. Alternative-routing is implicit but the inclusion/exclusion boundary is unusually sharp.

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