Skip to main content
Glama

ctxstore — memory that follows you across models

by ai.ctxstore
OverviewDiscussionsAdmin

Set up or restore memory account

setup_account

Set up or restore your persistent memory connection.

Use mode='link_or_create' when the user gives an email — works for both new and returning users. The server figures out which case applies:

  • If the email exists: sends OTP, attaches this device to the existing account

  • If the email is new: creates a fresh tenant, sends OTP to verify

Either path produces one clean account, no duplicates, no orphans.

Call setup_account(mode='link_or_create', email='their@email.com'). Then ask the user for the 6-digit code from their email and call setup_account(mode='verify', code='123456', email='their@email.com'). Passing email= on verify is required — session IDs rotate between requests on some clients.

mode='restore': use when the user provides an emk_* API key directly.

mode='reveal_key': echo the full emk_* API key. Works directly on an ALREADY-authenticated session; if the session isn't bound (some clients rotate or omit session ids between requests, so this can happen right after a successful verify), pass email= to receive a 6-digit code, then call again with email= and code= — the same rotation-proof lookup as mode='verify'. Success responses only show a key fingerprint (first 8 chars + last 4) — call this mode only when the user actually needs the full key, e.g. to persist it as 'Authorization: Bearer ' in an MCP connector config. Callers who prove neither a bound session nor email ownership are refused.

If no email yet, ask: 'What email should I use for your memory account?'

After setup completes, call search_facts as the first action to load prior context.

Input Schema

NameRequiredDescriptionDefault
codeNo6-digit verification code from email (required for mode='verify').
modeYes'link_or_create' = primary path — user provides email, server handles new vs returning. 'verify' = OTP confirmation step after link_or_create (pass email= and code=). 'restore' = user has emk_* API key from a prior session. 'link_email' = add email to an existing anonymous session. 'reveal_key' = echo the full API key (bound session, or email= + code= to verify by emailed OTP; responses otherwise show only a fingerprint).
emailNoEmail address. Required for mode='link_or_create'. Also pass on mode='verify' — required when session state is lost (common in claude.ai chat due to session ID rotation).
api_keyNoAPI key from a previous session (required for mode='restore')
agent_idNoOptional: bind a sticky agent identity (e.g. 'emily_code_4.7') in the same call. Equivalent to calling bind_agent immediately after a successful setup. Persists to mcp_sessions.agent_id (migration 0008). wake_status and load_context will default to this agent_id when called without an explicit agent_id= arg. Per-call override still works.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: it explains the server's new-vs-returning branching, that it produces no duplicate/orphan accounts, that session IDs rotate between requests (forcing email= on verify and reveal_key), that reveal_key success responses only return a fingerprint, and that callers proving neither session nor email ownership are refused. None of this is in the annotations, which only convey the coarse read/write/destructive/idempotent profile.

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-loads the primary path and organizes the rest mode-by-mode, which suits an 8-value enum. It is somewhat long and the session-rotation caveat is repeated across the verify and reveal_key paragraphs, which is minor redundancy a tighter edit could remove.

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?

For a stateful, multi-mode auth tool with no output schema, the description covers the full flow: initial call shape, OTP confirmation step, restore path, key reveal, and the post-setup action. Nothing an agent needs to invoke it correctly is missing.

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 100%, so baseline is 3, but the description goes further by explaining *why* email must be passed on verify (session ID rotation on some clients) and by disambiguating the mode enum with concrete call examples such as setup_account(mode='link_or_create', email='...'). This adds reasoning the schema's terse enum description does not.

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 ('Set up or restore your persistent memory connection') and immediately enumerates the concrete modes with their triggers. An agent can distinguish this from siblings like resume_session, get_session_seed, and bind_agent (which it explicitly notes is subsumed by the agent_id param) without opening the 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 explicit when-to-use routing for each mode: 'link_or_create' when the user supplies an email, 'restore' when the user has an emk_* key, 'reveal_key' only when the full key is genuinely needed. It also names the alternative path (bind_agent via agent_id) and prescribes the follow-up action (call search_facts first).

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