Skip to main content
Glama

ctxstore — memory that follows you across models

by ai.ctxstore
OverviewDiscussionsAdmin

Load Context

load_context
Read-onlyIdempotent

Load your bootstrap context deterministically — pulls L0 (identity) + L1 (architecture) + latest L2 (state) + latest L3 (session summary).

Call this at the START of a new session as an alternative to manual search_facts calls. Returns your layered memory structured for immediate use.

Optional: pass profile='worker-dev' (or another platform:profile: slug) to execute that profile's boot recipe — the server reads platform:profile::current, follows the pointer, parses LOAD/REQUIRE/HANDLER lines, fetches every named fact, and returns the merged bundle in one round trip. vars= supplies values for $TASK_FACT_KEY and similar recipe variables.

Input Schema

NameRequiredDescriptionDefault
fullNoReturn the full (uncapped, 32KB) bundle via the complete compose path. The MCP initialize response already inlines an ~8KB wake bundle for returning agents, and a plain load_context() serves that same cached bundle cheaply; pass full=true when you explicitly need everything (e.g. the inlined bundle was truncated). Default false.
hintNoAmbient query for the baton section: what this session is about before the user has said anything (e.g. the git branch + last commit subject, the project directory, the calendar). Searched alongside your previous self's agent:<id>:wake-baton:current queries; the hits not already in the layered bundle are appended as a baton section. A hinted bundle is compiled fresh (not served from the cache).
varsNoVariable substitutions for the recipe (e.g. {'TASK_FACT_KEY': 'comms:dispatch:dev:42'}). Unknown variables remain literal in the resolved keys.
scopeNoOptional project/tenant-scope prefix (e.g. 'chad' or a project slug like 'emily-core'). Used for profile lookup AND, when agent_id is set, for project-scoped self-note lookups (project:<scope>:agent:<agent_id>:self-note:closing preferred over global agent:<agent_id>:self-note:closing).
profileNoOptional profile slug (e.g. 'worker-dev', 'orchestrator', 'analyst', 'cold'). Server reads <scope>:profile:<profile>:current in tenant first (if scope set), then platform:profile:<profile>:current in platform_facts.
sectionNoExpand one section of the wake index: every pointer (key — headline) in that key family, ranked permanent → active → newest. Section names are the headers in the inlined index (e.g. 'conventions', 'people', 'project:emily-core', 'agent:<your id>'). Bodies stay a get_fact away.
agent_idNoCalling agent's identity slug (e.g. 'emily_code_4.7'). When set, self-note injection uses exact-key lookups (agent:<agent_id>:self-note:closing/opening) instead of tenant-wide substring scans — required for correct behaviour on multi-agent tenants where another agent's note would otherwise leak in. When omitted, falls back to the legacy substring scan for backwards compatibility.
max_fact_charsNoPer-fact body cap. Facts exceeding this length are truncated in the bundle with an explicit get_fact() pointer for the full body. Default 1500. Tunable up if you legitimately need more, but consider splitting large facts instead.
max_total_charsNoTotal bundle cap. If the assembled bundle exceeds this, a BUNDLE WARNINGS section is appended with the size signal. The bundle is NOT truncated at this limit — the warning lets the caller decide whether to lower top_k_per_layer or use targeted get_fact queries. Default 32000.
top_k_per_layerNoMax facts to return per layer (default 10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: deterministic layer composition, a single-round-trip merged bundle for profile recipes, and the profile boot algorithm (read pointer, parse LOAD/REQUIRE/HANDLER, fetch named facts). It does not restate truncation/caching limits, which live in the schema.

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 behavior and structured into default-load, then profile-recipe usage. It is dense and slightly long, but for a 10-parameter tool with no output schema nearly every sentence carries load; minor redundancy with the schema's own parameter prose.

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 no output schema, the description correctly explains what comes back (layered memory and merged bundles). It covers the default and profile flows well, but omits mention of the section-expansion and hint flows, which an agent must discover from parameter descriptions.

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 description coverage is 100%, so the baseline is 3, but the description meaningfully supplements it: profile semantics (server reads platform:profile:<profile>:current, follows the pointer, merges results) and vars supplying $TASK_FACT_KEY-style recipe variables are not obvious from the schema alone.

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 ('Load your bootstrap context') and decomposes exactly what is loaded (L0 identity, L1 architecture, L2 state, L3 session summary). It also distinguishes itself from the sibling search_facts, so an agent can tell it apart without opening another schema.

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?

'Call this at the START of a new session as an alternative to manual search_facts calls' gives explicit timing and names the alternative it replaces. It does not state when NOT to use it (e.g. mid-session refreshes vs. targeted get_fact), so it falls short of full routing guidance.

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