Skip to main content
Glama

ctxstore — memory that follows you across models

by ai.ctxstore
OverviewDiscussionsAdmin

Store Fact

store_fact

Store information that should persist across sessions.

Storage tips for best retrieval:

  • Include searchable keywords: 'We chose the Postgres DATABASE for ACID compliance' is better than 'We chose Postgres for ACID compliance'

  • Use the key parameter for facts that change over time (pricing, stack, team-members, current-sprint). When you store with the same key, the old version is archived automatically.

  • Use namespaces to organize: 'webapp/decisions', 'business/goals', 'team/members'

  • Store DECISIONS and CONTEXT, not raw data. 'We decided X because Y' is more useful than 'X happened'

  • Use category to classify: technical, decision, preference, identity, relationship

  • Use layer for context depth: 0=identity(stable), 1=architecture(monthly), 2=state(weekly), 3=session(daily)

Before ending a conversation, call store_session_summary to preserve continuity.

Input Schema

NameRequiredDescriptionDefault
keyNoNamed key for this fact. Storing with the same key auto-archives the previous version. Use for facts that change over time: 'session-latest', 'current-stack', 'team-size'.
textYesThe fact to store
layerNoContext persistence layer: 0=identity/stable, 1=architecture/monthly, 2=state/weekly, 3=session/daily.
categoryYesFact category
namespaceNoOptional namespace to organise facts (e.g. 'work', 'personal'). Defaults to 'default'.
is_permanentNoWhether this fact should bypass temporal decay
related_factsNoOptional list of related fact UUIDs to link (knowledge graph edges)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / layer / description
      Previous value: -"Context persistence layer: 0=identity/stable, 1=architecture/monthly, 2=state/weekly, 3=session/daily. Pass 0-3 as integer or string."New value: +"Context persistence layer: 0=identity/stable, 1=architecture/monthly, 2=state/weekly, 3=session/daily."
    • addedInput schema / properties / layer / maximum
      Added value: +3
    • addedInput schema / properties / layer / minimum
      Added value: +0
    • changedInput schema / properties / layer / type
      Previous value: -[
-  "integer",
-  "string"
-]New value: +"integer"
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write, so safety is covered. The description adds real behavioral context beyond that: same-key writes auto-archive the prior version, namespaces organize facts, and the layer system encodes decay horizons. It does not mention workspace scoping or what the call returns, so it is not exhaustive.

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?

Purpose is front-loaded in a single sentence, then organized into scannable bullets that each carry a distinct tip. It is somewhat long, and a few bullets restate enum lists already present in the schema descriptions (category, layer), which is the main source of waste.

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?

With 7 parameters, rich annotations, and no output schema, the description covers the semantics an agent needs to store a fact well. It omits two things that matter for a write tool: whether the call returns a fact UUID or key, and whether facts are workspace-scoped (relevant given switch_workspace and list_workspaces siblings).

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 the baseline is 3, but the description meaningfully extends parameter meaning by showing how to phrase searchable text, when to use key (facts that change over time), and concrete namespace/layer/category conventions with examples. The duplication of the category and layer enumerations found in the schema slightly blunts the added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: 'Store information that should persist across sessions.' It is clearly distinguishable from read/delete siblings like get_fact and delete_fact. However, it never differentiates itself from the very similar sibling 'store_facts' (plural), leaving the agent to guess which of the two write tools to pick.

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?

Gives concrete when-to-store guidance (decisions and context, not raw data) and explicitly routes the agent to store_session_summary before ending a conversation, which is a named alternative for a specific condition. It stops short of stating when NOT to use this tool or how it differs from store_facts.

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

All ctxstore — memory that follows you across models toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources