stellarion_memory_store

Saves a piece of knowledge to Stellarion's persistent memory store. Memories are indexed for both keyword and semantic search, so they can be retrieved later by meaning, not just exact terms. Use this to capture debugging discoveries, architectural decisions, gotchas, and project-specific knowledge.

When to Use

• You discovered a non-obvious fix and want to remember it for next time
• You want to record an architectural decision and its rationale
• You found a workaround for a tool or library quirk
• You want to annotate a function with context that doesn't belong in code comments

Parameters

Examples

Store a debugging discovery

Natural language:

Remember that the CORS error on /api/upload is caused by the file size exceeding nginx's client_max_body_size, not by missing CORS headers.

MCP call:

{
  "tool": "stellarion_memory_store",
  "arguments": {
    "content": "CORS error on /api/upload is actually caused by nginx client_max_body_size limit (default 1MB). The 413 response lacks CORS headers, making it look like a CORS issue. Fix: set client_max_body_size in nginx config, not CORS headers.",
    "tags": ["nginx", "cors", "upload", "debugging"],
    "category": "debugging",
    "problem": "POST to /api/upload fails with CORS error for large files",
    "solution": "Increase nginx client_max_body_size — the 413 response was missing CORS headers, masking the real error"
  }
}

Store an architectural decision

Natural language:

Record that we chose RocksDB over SQLite for the vector store because of better write throughput for embeddings.

MCP call:

{
  "tool": "stellarion_memory_store",
  "arguments": {
    "content": "Chose RocksDB over SQLite for vector store. RocksDB has 3x better write throughput for batch embedding inserts. SQLite was simpler but bottlenecked on concurrent writes during indexing.",
    "tags": ["architecture", "database", "vector-store"],
    "category": "architecture"
  }
}

Store a project convention

Natural language:

Remember that all API response types in this project use the ApiResponse wrapper.

MCP call:

{
  "tool": "stellarion_memory_store",
  "arguments": {
    "content": "All API handlers must return ApiResponse<T> wrapper type. Direct returns are not allowed — the middleware expects the wrapper for consistent error formatting and pagination metadata.",
    "tags": ["api", "convention", "types"],
    "category": "convention"
  }
}

Output Format

Returns the stored memory:

• id — Unique memory ID (use with stellarion_memory_get or stellarion_memory_invalidate)
• content — The stored content
• tags — Applied tags
• createdAt — Timestamp

Tips

• Use the problem/solution fields for debugging discoveries — they make retrieval more precise when you encounter the same problem again.
• Tags are the primary filtering mechanism. Use consistent tag names across related memories.
• Be specific in content. "Auth is broken" is not useful. "JWT refresh token rotation fails when the old token expires during the rotation window" is.
• Memories persist across sessions. They survive reindexing and server restarts.
• Use stellarion_memory_search to check if a similar memory already exists before creating duplicates.