The agentcairn server provides a local-first, Obsidian-backed memory system for AI agents, enabling durable storage and retrieval of memories as plain Markdown files. Here's what you can do:
search: Perform hybrid BM25 + semantic vector search over the memory vault, returning a compact index of matching note IDs and snippets. Supports optional reranking, project-scoped boosting, and hard project filtering.
recall: Like search, but retrieves the full text of the top-k matching notes instead of just snippets. Also supports reranking and project scoping.
build_context: Fetch a specific note by permalink along with all its 1-hop linked neighbors (via [[wikilinks]]), enabling graph-aware context expansion.
recent: List the most recently modified notes in the vault, useful for surfacing fresh or updated memories.
remember: Persist a new distilled memory into the vault. Text is automatically redacted of secrets before writing, with optional title and tags for organization.
Provides a rebuildable index using DuckDB for hybrid retrieval (vector search, BM25 full-text search, and graph traversal) over the vault's notes.
Stores memories as human-readable Markdown files in an Obsidian vault, which serves as the source of truth; supports wikilinks, frontmatter, and direct editing.
Optionally uses Ollama for local embeddings to power semantic vector search in the hybrid retrieval index.
A cairn marks a trail for whoever comes next. agentcairn does that for coding agents: it captures durable context from the tools you use, stores it as inspectable Markdown with provenance, and recalls only the most relevant pieces when another agent needs them.
The memory is not hidden behind an admin console or a hosted database. The separate agentcairn-obsidian companion reads the same Markdown files as the agents and exposes provenance, currency, importance, supersession, and related: links.
Dogfood snapshot · 2026-07-15. Across 417 local recalls, the maintainer's vault returned context about
262× smallerthan loading the full vault each time—an estimated136.6M tokens of full-vault context avoidedin aggregate. Token counts use approximately four characters per token. This is not billed-token savings, and agentcairn sends no telemetry.
Related MCP server: auxly-memory-cli
The shortest path is a first-class plugin. It bundles the MCP server, the memory skill, and the host-specific ambient hooks—no separate agentcairn package install. The plugin launches through uvx, so install uv first if uvx --version is not already available.
claude plugin marketplace add ccf/agentcairn
claude plugin install agentcairn@agentcairnClaude Code gets per-turn project-scoped recall, session/compaction capture, and the /agentcairn:recall, /agentcairn:remember, /agentcairn:memory, /agentcairn:savings, and /agentcairn:ingest commands.
codex plugin marketplace add ccf/agentcairn
codex plugin add agentcairn@agentcairnCodex gets the bundled MCP tools and memory skill, live-verified SessionStart recall, and SessionEnd capture with cairn sweep as the out-of-band backstop.
Already use skills.sh or a find-skills workflow? Install the public setup assistant:
npx skills add ccf/agentcairn --skill agentcairn-setup -gThen ask your agent: Use $agentcairn-setup to preview, install, and verify AgentCairn for this coding agent.
This installs setup guidance only—not the AgentCairn runtime, MCP server, plugin, or hooks. The assistant delegates those changes to AgentCairn's preview-first native installer and verifies the resulting integration. The Claude Code and Codex plugin commands above remain the shortest path.
The default vault is ~/agentcairn and is created on first use. A new empty vault has nothing useful to recall yet, so prove the whole loop explicitly:
You → Remember this durable fact: staging deploys use blue-green.
Agent → written and indexed
You → Recall the staging deploy strategy.
Agent → staging deploys use blue-green. ↳ <memory permalink>remember writes the Markdown note and index entry together, so immediate recall is part of the contract. The first local run may download and warm the configured embedding/reranking models.
Promise | What it means in practice |
Markdown is canonical | Notes, frontmatter, and |
The index is disposable | DuckDB is a derived cache. Deleting or rebuilding it does not delete the Markdown vault. |
One vault crosses agents | Supported hosts share the same configured vault instead of building isolated memories per tool. |
History is non-lossy | Derived notes do not silently erase stored notes; superseded and expired facts remain inspectable and are demoted rather than hidden. |
Every result has context | Project, validity status, and permalinks travel with recall so an agent can distinguish current local evidence from cross-project history. |
Capture: host hooks improve immediacy; cairn sweep reads supported transcript stores out-of-band as the durable backstop. AgentCairn redacts recognized credentials, deduplicates, importance-gates, and distills before its automated plaintext writes.
Reconcile: the first read transactionally brings the vault-scoped index in sync with Markdown. A failed rebuild preserves the last good cache and the durable files remain untouched.
Recall: BM25 and semantic vectors are fused with Reciprocal Rank Fusion, then optionally reranked. Model/provider failures visibly fall back to BM25 with diagnostics instead of returning incompatible vectors.
Remember: the MCP tool atomically writes a Markdown note and updates the index under one writer lock, making a successful save immediately recallable.
Local by default. FastEmbed runs locally, the MCP server uses stdio, there is no required daemon or external database, and there is no telemetry.
Plain boundaries. The synced vault contains Markdown; by default, the rebuildable .duckdb index stays outside it. Vault symlinks that escape the configured root are rejected.
Time-aware corrections. valid_from, valid_until, and superseded_by keep old evidence visible while making current facts rank first.
Deterministic graph. [[wikilinks]] and optional cairn link neighbors create an Obsidian-native graph without asking an LLM to invent entities.
Project-aware recall. The current project is boosted by default; cross-project results remain available and are labeled. Automatic recall is project-scoped unless you explicitly opt into all projects.
Every host resolves the same configured vault. cairn install previews detected hosts without writing. MCP configuration writes are backup-first and preserve unrelated servers; plugin-host installs delegate to the host's own CLI.
Host | Integration | Set up with | Ambient memory |
Claude Code | Plugin + MCP + skill |
| ✅ per-turn + SessionStart recall; SessionEnd/PreCompact capture |
Codex | Plugin + MCP + skill |
| ✅ SessionStart recall; SessionEnd capture + sweep |
Cursor | MCP + skill + ingest |
| ◐ out-of-band sweep |
OpenCode | Plugin + MCP + ingest |
| ✅ per-turn recall + idle/compact capture |
Hermes Agent | Native | ✅ auto-recall + session-end capture | |
Antigravity | Plugin + ingest |
| ◐ out-of-band sweep |
VS Code (Copilot) | MCP server |
| — |
Claude Desktop | MCP server |
| — |
Any other MCP host | Portable MCP server |
| host-dependent |
Codex SessionStart was verified live end-to-end with agentcairn 0.24.2 / plugin 0.1.2. The installed SessionEnd command dispatch and detached sweep pass exact handler probes; cairn sweep remains the out-of-band capture backstop. See the OpenCode integration and Hermes integration for their native lifecycle details.
The plugin is the easiest route, but agentcairn is also a standalone CLI and on-demand MCP server. Standalone installs require Python 3.11+.
uv tool install agentcairn
cairn init ~/agentcairn
cairn sweep --vault ~/agentcairn
cairn recall "how did we fix the auth bug?" --vault ~/agentcairn
cairn doctor --vault ~/agentcairnClaude Code's auto-memory can seed the shared vault without changing its source files. The command previews only the current repository by default; add --apply to write the redacted notes and refresh the index.
cairn import claude-memory # preview; writes nothing
cairn import claude-memory --apply # import this repository
cairn import claude-memory --project ../other --applyThe one-way import reads MEMORY.md and its topic Markdown files—never CLAUDE.md or .claude/rules/. Imported notes retain Claude Code, project, and source-file provenance. When a source changes, the prior version remains inspectable but is superseded; when one disappears, its imported version expires. A small .agentcairn/native-memory/ registry preserves that lifecycle without indexing source content twice. Use --source <dir> for a custom, managed, or session-overridden Claude memory directory, or --no-reindex when batching imports.
Prefer an ephemeral process:
uvx agentcairn # MCP server
uvx --from agentcairn cairn recall "..." # CLI; plain `uvx cairn` is a different packagecairn schedule install --vault ~/agentcairn # launchd on macOS / user crontab on Linux
cairn schedule status
cairn link --vault ~/agentcairn # write deterministic related: neighbors
cairn reindex ~/agentcairn # rebuild the disposable cache
cairn savings # local context-efficiency estimate
cairn index-status --vault ~/agentcairnOn other operating systems, run cairn sweep from your scheduler of choice.
Settings live in ~/.agentcairn/config.toml; precedence is CLI flag → environment → config file → default.
cairn config --init
cairn configauto_recall = true
auto_recall_k = 3
auto_recall_scope = "project" # use "all" only as an explicit cross-project opt-inLocal nomic-embed-text-v1.5 embeddings are the default. Voyage, OpenAI-compatible embeddings, and the Anthropic durability judge are opt-in. With a cloud provider enabled, remaining secret-redacted note chunks and queries leave the machine; changing the embedding model re-embeds the vault and may incur real latency or API cost.
The repository ships a revision-pinned, reproducible LongMemEval-S + LoCoMo harness. The default is local nomic-embed-text-v1.5 plus the cross-encoder reranker.
Dataset / granularity | Metric | BM25 only | Hybrid RRF | Hybrid + reranker |
LoCoMo · turn | recall@5 | 0.527 | 0.562 | 0.662 |
LongMemEval-S · session | recall@5 | 0.920 | 0.954 | 0.969 |
LongMemEval-S · turn | recall@5 | 0.680 | 0.640 | 0.788 |
Context returned at the default k=10 is much smaller than the complete indexed history:
Dataset | Mean full history | Mean recalled | Reduction |
LoCoMo (3 conversations) | 25,646 tokens | 529 tokens | 51.1× |
LongMemEval-S (full 500) | 136,552 tokens | 2,207 tokens | 64.7× |
Read the numbers honestly:
Retrieval recall is not QA accuracy. These tables compare controlled retrieval arms, not end-user answer quality or another product's leaderboard score.
Token counts use an approximately four-characters-per-token heuristic. The reduction compares the indexed haystack with returned chunks; it is not billed cost savings.
Graph boost is inert on these chat corpora because they contain no native [[wikilink]] graph. It is designed for real interlinked vaults.
The optional QA judge uses Anthropic rather than the papers' GPT-4o setup, so those QA results are useful for relative ablations—not published-leaderboard comparisons.
Full metrics, embedding sweeps, latency measurements, licenses, commands, and caveats live in benchmarks/README.md.
The vault is plaintext by design, not encrypted storage. AgentCairn redacts recognized credential patterns before its automated body/title/tag writes; unknown patterns and hand edits remain your responsibility.
Vault files are owner-only (0600/0700). Because the vault is plaintext and redaction is best-effort, the file mode is effectively its only access control. Shared-GID setups (e.g. two Docker containers on the same group but different UIDs) need group access, so vault_group_writable = true widens new vault notes and directories to 0660/0770. It is opt-in on purpose: on macOS every local user's primary group is staff, so a group-readable default would expose your memories to other accounts on the machine. The knob never widens anything outside the vault — the index, ledgers, lock files, and ~/.agentcairn/config.toml stay private.
Cloud features are explicit egress. The default stays local. Opting into a cloud embedder or LLM judge sends the remaining redacted text to that provider.
The project is beta. Standalone use requires Python 3.11+, and the first local model load can take time. The published retrieval evidence is strongest for conversational memory, not a universal code-search claim.
Ambient behavior varies by host. The matrix above is intentional: Cursor and Antigravity rely on sweep capture; generic MCP hosts may expose tools without lifecycle hooks.
Automation is platform-specific. Managed scheduling targets macOS launchd and Linux user crontab; use your own scheduler elsewhere.
agentcairn uses uv exclusively for dependency management and tooling.
uv sync
uv run pre-commit install
uv run pytest
uv run ruff format .
uv run ruff check --fix .
uv run pre-commit run --all-filesRun the offline benchmark regression without API keys:
uv run pytest benchmarks/tests/Apache License 2.0 — permissive, with an explicit patent grant. Copyright © 2026 Charles C. Figueiredo.
Return a note plus its 1-hop linked neighbors.
| Name | Required | Description | Default |
|---|---|---|---|
| permalink | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (returning neighbors) but does not specify whether it is read-only, side effects, error handling, or output structure. The minimal 'return' phrasing implies a read operation, but no additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded with the essential action. However, it is borderline too sparse, lacking any elaboration that might justify additional detail. It earns a high conciseness score for efficiency, but not a 5 due to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimal. It does not explain the return format, clarify the meaning of '1-hop', or provide any usage context. Given the existence of sibling tools, the description is incomplete because it offers no guidance on when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (permalink) with 0% schema description coverage. The description does not explain what permalink is, its format, or its role in the operation. Since coverage is low, the description was expected to compensate but fails to add any semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a note plus its 1-hop linked neighbors, using a specific verb ('Return') and resource ('note') with a defined scope. It distinguishes from sibling tools like search, recall, recent, and remember, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, intended scenarios, or exclusions, leaving the agent to infer based solely on the function description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search then hydrate the top-k notes' full text.
Reranks by default (set CAIRN_RERANK=0 to disable, or pass rerank=false).
Recall prefers your current project's memories (boosted, non-lossy): pass
project (a repo name) to target another project, else the server's working
directory is used. scope="project" hard-limits results to that project.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| scope | No | all | |
| rerank | No | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses meaningful runtime behavior: reranking is enabled by default with disable paths, current-project memories are boosted and non-lossy, and `scope="project"` hard-limits results. It does not describe output shape or error behavior, but the disclosed details go beyond a generic retrieve statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a one-sentence purpose statement followed by only high-value behavioral details. Nothing is wasted; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no output schema and no annotations, the description gives enough context to select, invoke, and scope the tool correctly: full text returned, k, rerank default, project fallback, and strict project scoping. Minor gaps remain in the available `scope` values and relationship to `search`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters; it explains `project`, `scope`, and `rerank` meaningfully, and `query`/`k` are covered by the 'search' and 'top-k' phrasing. It does not enumerate possible `scope` values beyond the `"project"` example, but the added semantic value is substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-plus-resource statement: it searches then hydrates the top-k notes' full text. This clearly indicates a retrieval/recall operation on memory notes, though it does not explicitly contrast itself with the sibling `search` tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed scoping guidance for `project` and `scope`, but no explicit when-to-use or when-not-to-use guidance relative to siblings like `search`, `recent`, or `build_context`. The usage context must be inferred from the niche described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most-recently-modified notes.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose any behavioral traits such as side effects, permissions, or rate limits. It only states it lists notes, implying a read operation, but without explicit statement of safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and object. It is appropriately sized for the tool's simplicity, containing no fluff or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not explain the parameter 'n', nor what the returned list contains (e.g., note titles, IDs, timestamps). It also doesn't specify any edge cases or behavior when no notes exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'n' with a default, but neither the schema nor the description explains its meaning or purpose. Users are left to guess whether 'n' is a count, an offset, or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the most-recently-modified notes, using the verb 'list' and specifying the resource 'notes'. It is distinct from siblings like search or recall, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool compared to alternatives such as search or recall. It provides no usage context or criteria for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a distilled memory (redacted, non-lossy) into the vault.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| text | Yes | ||
| title | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'redacted, non-lossy' which hints at behavior but does not clarify side effects or prerequisites. No annotations are provided, so the description partially discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but arguably too brief for a tool with three parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is insufficient. It does not explain the return value, error conditions, or what 'vault' means, leaving gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the three parameters (text, title, tags). With 0% schema coverage, the description fails to compensate, leaving the agent with no guidance on parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Persist a distilled memory' and the resource 'into the vault', using a specific verb and resource that distinguishes it from sibling tools like recall, search, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for persisting processed memories but gives no explicit guidance on when to use vs alternatives like build_context or recall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hybrid search over memory; returns a compact id+snippet index.
Reranks by default (set CAIRN_RERANK=0 to disable, or pass rerank=false).
Recall prefers your current project's memories (boosted, non-lossy): pass
project (a repo name) to target another project, else the server's working
directory is used. scope="project" hard-limits results to that project.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes | ||
| scope | No | all | |
| rerank | No | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It informs about default reranking and how to disable it (via env var or parameter), the boosting behavior for current project's memories (non-lossy), the fallback to server's working directory, and the hard limiting effect of scope='project'. These are significant behavioral details beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three sentences, starting with a clear purpose and output. The additional sentences provide necessary behavioral context without excessive verbosity. It is slightly dense but well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description adequately outlines the return format (id+snippet index) and key behaviors. Missing details include the meaning of 'k' and possible values for 'scope' beyond the special 'project' case. Overall, it is sufficient for an agent to invoke the tool reliably, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains project (target another project, else working directory), scope (hard-limits to project), and rerank (boolean, default true). It does not mention 'k', which likely controls the number of results, but query is self-evident. Coverage is good but incomplete for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'hybrid search over memory' and returns a 'compact id+snippet index'. This is a specific verb+resource+output that distinguishes it from siblings like 'recall' and 'recent' by emphasizing the hybrid search nature and the indexed output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as recall, recent, or build_context. The description focuses on parameter behavior (project scoping, reranking) but does not state exclusions or recommend usage contexts. The mention of 'Recall prefers your current project's memories' is confusingly worded and does not serve as clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.25.3build_contextrecallrecentsearchv0.25.1build_contextrecallrecentsearchv1.0.0build_contextrecallrecentremembersearchsearch and recall are similar but their outputs differ (index vs full text). build_context, recent, and remember are clearly distinct. No two tools appear to do the exact same thing.
Naming mixes single verbs (search, recall, remember), a verb_noun (build_context), and an adjective (recent). All lowercase and readable, but no consistent pattern.
5 tools is well-scoped for a memory vault: search, recall, context building, recent listing, and writing. Each tool earns its place without redundancy.
Core operations are covered: create (remember), search, retrieve, list, and context expansion. Missing update/delete but these may be out of scope for a memory vault.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Token-efficient MCP memory for Markdown vaults. Tiered search, GraphRAG, AI memories.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ccf/agentcairn'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
