"namespace:in.creo-memories" matching MCP tools:

• memory_rename

  emem — Earth memory protocol

  Move (rename) a memory file from `old_path` to `new_path`. Both paths must stay under `/memories/`; `new_path` must not already exist. The file_cid is preserved (no re-sign) so the prior receipt still binds the bytes. Mirrors the `rename` verb in Anthropic's context-management-2025-06-27 memory tool spec. When to use: Call when the LLM wants to rename or move a memory file. Failure modes: source missing, destination already exists, path escapes `/memories/`.

  Connector

• emem_memory_search

  emem — Earth memory protocol

  Semantic search over /memories/* file contents using BGE-base-en-v1.5 (768-D, L2-normalised) backed by a Lance partition (`memory_text_index_d768.lance`). Matches paraphrases — "rainfall in March" finds "precipitation observed in spring" without an exact substring match. Returns ranked hits with similarity in [0,1], 200-char snippets around the best-matching chunk, and the signing receipt's path / file_cid / signed_at / attester_pubkey_b32 fields. Filters: `kind`, `path_prefix`, `attester_pubkey_b32`. Falls back to a brute-force scan (slower but correct) when the index is empty or `EMEM_DISABLE_LANCE=1` is set; the `via` field of the response reports which path was taken. When to use: Call instead of paging through `memory_view` whenever the agent knows roughly what it wants (a topic, a name, a paraphrase) but not the exact file path. Pair with `memory_view` for the full body once you've narrowed down the candidate — `emem_memory_search` returns a 200-char snippet, not the whole file. The polling indexer hydrates once per minute (configurable via `EMEM_MEMORY_SEARCH_POLL_SECS`), so a file created in the same turn may briefly miss the fast-path — the brute-force fallback still catches it.

  Connector

• recall_nearby_memories

  space0

  Call this BEFORE you decide your next action: it grounds the choice in what you already know about THIS place instead of starting blind. Returns your OWN anchored memories within radiusM of your position (default 20m, max 64m). Or, when you pass regionId, every memory you anchored inside that labeled region (e.g. "my library"). Without `query` they come back nearest-first. With `query` (free text describing what you are trying to remember) radius-mode recall is ranked by a hybrid of semantic relevance to the query AND spatial proximity, plus recency, importance, and how recently the place was re-seen, so "what is relevant to what I am doing, near where I stand" is one call. Each entry: {memory_id, kind, event_text, importance, position, distance_m, occurred_at, region}. Only YOUR memories are ever returned, never another agent's. Anchor memories first with append_memory(space, position); pair with build + label_region to construct a navigable memory palace you can revisit and read back. Recall is occlusion-BLIND by default: you remember a memory in the next room even though a wall blocks sight, just as you know what is there without seeing it. Pass lineOfSightOnly:true for a perception-style question instead - restrict results to memories whose subject is currently VISIBLE from where you stand.

  Connector

• x711_vault_compress

  x711 — Universal Agent Gas Station

  Groq-powered vault compression: 50 cold (least-read) memories → 5 dense summaries. Source memories are archived after compression. Net result: sharper vault, lower LLM token cost when injecting context. Automatically refunded if Groq fails. $0.05. Requires API key.

  Connector

• restore_context

  Penfield Memory

  Resume work from a saved cognitive context. This provides a narrative briefing to quickly orient you to: - The investigation that was in progress - Key discoveries and insights made - Current hypotheses being tested - Open questions and blockers - Suggested next steps - All relevant memories with their connections The briefing reconstructs the cognitive state, not just the data. You'll understand not just WHAT was discovered, but WHY it matters and HOW the understanding evolved. Example of what you'll receive: "[API Timeout Investigation - Resuming after 2 hours] SITUATION: You were investigating production API timeouts that occur at exactly batch_size=100. This investigation started when user reported timeouts only in production, not staging. PROGRESS MADE: - Identified sharp cutoff at 100 items (not gradual degradation) - Disproved connection pool theory (monitoring showed only 43/200 connections used) - Found root cause: MAX_BATCH_SIZE=100 hardcoded in batch_handler.py:147 - Confirmed staging uses different config override (MAX_BATCH_SIZE=500) EVIDENCE CHAIN: User report → Reproduced locally → Noticed batch_size correlation → Searched codebase for limits → Found MAX_BATCH_SIZE → Checked staging config → Discovered config difference CORRECTED MISUNDERSTANDINGS: - Initially thought it was Redis connection exhaustion (disproven by monitoring) - Assumed gradual performance degradation (actually sharp cutoff) - Thought staging/production were identical (config differs) CURRENT HYPOTHESIS: Production deployment uses default MAX_BATCH_SIZE=100 from code, while staging has environment variable override. Fix requires either code change or prod config update. BLOCKED ON: Need production deployment access to apply fix. User considering whether to change code default or add production environment variable. RECOMMENDED NEXT STEPS: 1. Verify production environment variables (check if MAX_BATCH_SIZE is set) 2. If not set, add MAX_BATCH_SIZE=500 to production config 3. If code change preferred, update default in batch_handler.py 4. Run load test with batch_size=100-500 range to verify fix KEY MEMORIES FOR REFERENCE: - 'Initial timeout report from user' - Starting point of investigation - 'MAX_BATCH_SIZE discovery' - Root cause identification - 'Redis monitoring data' - Evidence disproving connection theory - 'Staging config analysis' - Explanation for environment difference" This cognitive handoff ensures you can continue the work with full understanding of the problem space, previous attempts, and current direction. The narrative preserves not just facts but the reasoning process, mistakes made, and lessons learned. SPECIAL CASE: restore_context("awakening") The name "awakening" is reserved for loading the user's personality configuration. This loads the Awakening Briefing which includes: - Selected persona identity and voice style - Custom personality traits (Premium+ users) - Any quirks and boundaries from the persona preset Args: name: Name or ID of context to restore. Can be: - Context name (exact match, case-sensitive) - Context UUID (from list_contexts output) - "awakening" for personality briefing limit: Maximum number of memories to restore (default 20) ctx: MCP context (automatically provided) Returns: Dict with: - success: Whether restoration succeeded - description: The cognitive handoff briefing - memories: List of relevant memories - context_id: The restored context identifier

  Connector

• x711_vault_query

  x711

  Semantic vector search across your private vault. Returns ranked memories by cosine similarity × confidence × importance. Recalls the most relevant facts, insights, and skills your agent has accumulated. FREE always. Requires API key (reads your vault only — other agents cannot access it).

  Connector

• connect

  Penfield Memory

  Connect memories to build knowledge graphs. After using 'store', immediately connect related memories using these relationship types: ## Knowledge Evolution - **supersedes**: This replaces → outdated understanding - **updates**: This modifies → existing knowledge - **evolution_of**: This develops from → earlier concept ## Evidence & Support - **supports**: This provides evidence for → claim/hypothesis - **contradicts**: This challenges → existing belief - **disputes**: This disagrees with → another perspective ## Hierarchy & Structure - **parent_of**: This encompasses → more specific concept - **child_of**: This is a subset of → broader concept - **sibling_of**: This parallels → related concept at same level ## Cause & Prerequisites - **causes**: This leads to → effect/outcome - **influenced_by**: This was shaped by → contributing factor - **prerequisite_for**: Understanding this is required for → next concept ## Implementation & Examples - **implements**: This applies → theoretical concept - **documents**: This describes → system/process - **example_of**: This demonstrates → general principle - **tests**: This validates → implementation or hypothesis ## Conversation & Reference - **responds_to**: This answers → previous question or statement - **references**: This cites → source material - **inspired_by**: This was motivated by → earlier work ## Sequence & Flow - **follows**: This comes after → previous step - **precedes**: This comes before → next step ## Dependencies & Composition - **depends_on**: This requires → prerequisite - **composed_of**: This contains → component parts - **part_of**: This belongs to → larger whole ## Quick Connection Workflow After each memory, ask yourself: 1. What previous memory does this update or contradict? → `supersedes` or `contradicts` 2. What evidence does this provide? → `supports` or `disputes` 3. What caused this or what will it cause? → `influenced_by` or `causes` 4. What concrete example is this? → `example_of` or `implements` 5. What sequence is this part of? → `follows` or `precedes` ## Example Memory: "Found that batch processing fails at exactly 100 items" Connections: - `contradicts` → "hypothesis about memory limits" - `supports` → "theory about hardcoded thresholds" - `influenced_by` → "user report of timeout errors" - `sibling_of` → "previous pagination bug at 50 items" The richer the graph, the smarter the recall. No orphan memories! Args: from_memory: Source memory UUID to_memory: Target memory UUID relationship_type: Type from the categories above strength: Connection strength (0.0-1.0, default 0.5) ctx: MCP context (automatically provided) Returns: Dict with success status, relationship_id, and connected memory IDs

  Connector

• list_memories

  Toolora MCP Server

  Use this tool to discover what has been saved in memory — e.g. at the start of a session, or when the user asks 'what have you saved?' or 'show me my memories'. Returns all saved memory keys with their preview, save date, and expiry. Optionally filter by a prefix (e.g. 'project-' to list only project memories). Pair with recall_memory to fetch the full content of any key.

  Connector

• mark_memories_used

  space0

  After recall_nearby_memories AND then taking an action (build, post, move, say, plan) that was informed by one or more of the recalled memories, call this with the memory_ids you actually used and a short actionVerb describing what you did. This records that your spatial memory drove a real decision (it links each cited memory to your latest recall in this space). Do this WHENEVER a recalled memory actually shaped what you did next - it is a normal part of the recall -> act loop, not a rare event; the only time to skip it is when the recall did not inform the action at all. Returns { ok, cited } where cited is how many citations were recorded. Only your OWN memories can be cited.

  Connector

• pathrule_list_memories

  Pathrule

  List active memories attached to a specific Pathrule tree node. Use pathrule_get_context, pathrule_goto, or pathrule_get_node first to discover the node_id. Returns compact previews only; call pathrule_read_memory with a memory_id when you need the full body.

  Connector

• pathrule_setup

  Pathrule

  Fetch the active Pathrule bootstrap brief and execute it. Call this ONCE when the user asks to set up / bootstrap / initialize Pathrule for a project (e.g. 'Set up Pathrule for this project', 'Bootstrap Pathrule'). The response `body` is a prompt you must follow immediately — it tells you how to scan the project, propose memories/rules/skills, and write the approved items via pathrule_write_memory / _rule / _skill. Do NOT call this mid-task, for already-populated workspaces, or when the user just wants context — use pathrule_get_context for routine context lookups. If no workspace exists yet, call pathrule_list_organizations + pathrule_create_workspace first.

  Connector

• append_memory

  space0

  Persist one event to this agent's memory stream. For kind=chat, ALWAYS pass `speaker` (the in-world player name behind the line) - flattening "grassguy: i am here" into event_text causes the agent to parrot the speaker as itself on the next tick. Server-side will embed `text` via Workers AI so the memory is reachable by `search_memories` semantic retrieval. Observation/action memories auto-anchor to your current space and last-looked subject by default once you have entered a space; pass space + subjectPosition only to override the anchor precisely. Reflection/chat stay unanchored.

  Connector

• thinkneo_read_memory

  ThinkNEO Control Plane

  Read Claude Code project memory files. Without arguments, returns the MEMORY.md index listing all available memories. With a filename argument, returns the full content of that specific memory file. Use this to access project context, user preferences, feedback, and reference notes persisted across Claude Code sessions.

  Connector

• save_context

  Penfield Memory

  Save a cognitive checkpoint for handoff to another agent or your future self. The `description` is the primary cognitive payload — its narrative is what lets another agent resume the work. The server also runs hybrid search on the description and attaches the most relevant memories to the checkpoint. Reference memories inside `description` using either: - `memory_id: <uuid>` — reliable, direct lookup - `'descriptive phrase'` — best-effort search; may not resolve Prefer UUIDs whenever you have them. The response reports `references_resolved` + `unresolved_references` so you can retry. For the full hygiene guide (what to include, how to organize, when to checkpoint, example shapes), invoke the `checkpoint_protocol` MCP prompt. Args: name: Unique identifier for this checkpoint (used by restore_context). description: Narrative handoff with optional memory references. ctx: MCP context (automatically provided). Returns: Dict with success status, context_id, memories_included, and (when references were extracted) references_resolved + unresolved_references.

  Connector

• pathrule_get_node

  Pathrule

  Return a single node plus ids for attached memories, rules, and skills. Requires workspace_id to prevent cross-workspace ambiguity.

  Connector

• memory_overview

  XMemo

  Show a summary of XMemo memories and recent activity. Call this when the user asks what XMemo remembers without a specific query.

  Connector

• memory_view

  emem — Earth memory protocol

  Read the contents of a memory file at `/memories/<path>` or list a directory when the path ends with `/`. Optional `view_range: [start, end]` slices a 1-indexed inclusive line range out of the file. Mirrors the `view` verb in Anthropic's context-management-2025-06-27 memory tool spec. When to use: Call when the model running with `betas: ['context-management-2025-06-27']` issues a `view` against its memory directory. Use `/memories/` (trailing slash) to enumerate files; `/memories/notes.md` to read one. Returns a 404 with typed code on missing path.

  Connector

• x711_vault_compress

  x711

  Groq-powered vault compression: 50 cold (least-read) memories → 5 dense summaries. Source memories are archived after compression. Net result: sharper vault, lower LLM token cost when injecting context. Automatically refunded if Groq fails. $0.05. Requires API key.

  Connector

• recall

  XMemo

  Recall the few most relevant saved memories before answering, when prior preferences, known facts, past decisions, or project context may directly affect the response. Use recall_context when many memories are needed.

  Connector

• memory_delete

  emem — Earth memory protocol

  Delete a memory file at `/memories/<path>`. When the path ends with `/`, every file beneath the directory is removed. Updates the path index but leaves prior content-addressed blobs in place (the audit history is append-only). Mirrors the `delete` verb in Anthropic's context-management-2025-06-27 memory tool spec. When to use: Call when the LLM issues a `delete` against a memory file or subdirectory it no longer needs. Existing receipts citing the old file_cid stay verifiable — the blob is content-addressed, only the path → file_cid index forgets.

  Connector