Quick Reference
Persistent Memory Management - MCP Memory Server integration for maintaining context across Claude Code sessions, storing user preferences, project-specific knowledge, and learned patterns.
Core Capabilities:
- •Persistent key-value storage across sessions
- •User preference management
- •Project context preservation
- •Learned pattern storage
- •Session history tracking
When to Use:
- •Store user preferences (language, coding style, naming conventions)
- •Preserve project-specific decisions and rationale
- •Remember frequently used commands and patterns
- •Track project milestones and progress
- •Store learned code patterns for reuse
Key Operations:
- •
mcp__memory__store: Store a key-value pair - •
mcp__memory__retrieve: Retrieve a stored value - •
mcp__memory__list: List all stored keys - •
mcp__memory__delete: Delete a stored key
Implementation Guide
MCP Memory Server Setup
The memory server is configured in .mcp.json:
{
"memory": {
"command": "${SHELL:-/bin/bash}",
"args": ["-l", "-c", "exec npx -y @modelcontextprotocol/server-memory"]
}
}
Memory Categories
Organize stored data by category prefixes:
User Preferences (prefix: user_):
- •
user_language: Conversation language preference - •
user_coding_style: Preferred coding conventions - •
user_naming_convention: Variable/function naming style - •
user_timezone: User's timezone for scheduling
Project Context (prefix: project_):
- •
project_tech_stack: Technologies used in project - •
project_architecture: Architecture decisions - •
project_conventions: Project-specific conventions - •
project_dependencies: Key dependencies and versions
Learned Patterns (prefix: pattern_):
- •
pattern_error_fixes: Common error resolution patterns - •
pattern_code_templates: Frequently used code templates - •
pattern_workflow: User's preferred workflow
Session State (prefix: session_):
- •
session_last_spec: Last worked SPEC ID - •
session_active_branch: Current git branch - •
session_pending_tasks: Incomplete tasks
Usage Patterns
Pattern 1: Store User Preference
When user explicitly states a preference:
User: "I prefer Korean responses" Action: Store using mcp__memory__store Key: "user_language" Value: "ko"
Pattern 2: Retrieve Context on Session Start
At session initialization:
- •Retrieve
user_languagefor response language - •Retrieve
project_tech_stackfor context - •Retrieve
session_last_specfor continuity
Pattern 3: Learn from User Behavior
When user corrects or adjusts output:
User: "Use camelCase not snake_case" Action: Store pattern Key: "user_naming_convention" Value: "camelCase"
Pattern 4: Project Knowledge Base
Store important project decisions:
Key: "project_auth_decision" Value: "JWT with refresh tokens, stored in httpOnly cookies"
Best Practices
Storage Guidelines:
- •Use descriptive, categorized key names
- •Keep values concise (under 1000 characters)
- •Store JSON for complex data structures
- •Include timestamps for time-sensitive data
Retrieval Guidelines:
- •Check memory on session start
- •Retrieve relevant context before tasks
- •Use memory to avoid repeated questions
Privacy Considerations:
- •Never store sensitive credentials
- •Avoid storing personal identifiable information
- •Store preferences, not personal data
Integration with Alfred
Alfred should proactively use memory:
On Session Start:
- •Retrieve user preferences
- •Apply language and style settings
- •Load project context
During Interaction:
- •Store explicit user preferences
- •Learn from corrections
- •Update project context as needed
On Task Completion:
- •Store successful patterns
- •Update session state
- •Record milestones
Memory Key Reference
User Preferences
| Key | Type | Description |
|---|---|---|
user_language | string | Response language (ko, en, ja, etc.) |
user_coding_style | string | Preferred style (descriptive, concise) |
user_naming_convention | string | Naming style (camelCase, snake_case) |
user_comment_language | string | Code comment language |
user_timezone | string | User timezone |
user_expertise_level | string | junior, mid, senior |
Project Context
| Key | Type | Description |
|---|---|---|
project_name | string | Project name |
project_tech_stack | JSON | Technologies and frameworks |
project_architecture | string | Architecture pattern (monolith, microservices) |
project_test_framework | string | Testing framework (pytest, jest) |
project_conventions | JSON | Project-specific conventions |
Learned Patterns
| Key | Type | Description |
|---|---|---|
pattern_preferred_libraries | JSON | User's preferred libraries |
pattern_error_resolutions | JSON | Common error fixes |
pattern_code_templates | JSON | Frequently used templates |
Session State
| Key | Type | Description |
|---|---|---|
session_last_spec | string | Last worked SPEC ID |
session_active_branch | string | Current git branch |
session_pending_tasks | JSON | Incomplete tasks |
session_last_activity | string | Timestamp of last activity |
Agent-to-Agent Context Sharing
Overview
Memory MCP enables agents to share context during workflow execution. This reduces token overhead and ensures consistency across the Plan-Run-Sync cycle.
Handoff Key Schema
Handoff Data (prefix: handoff_):
handoff_{from_agent}_{to_agent}_{spec_id}
Example: handoff_manager-spec_manager-ddd_SPEC-001
Shared Context (prefix: context_):
context_{spec_id}_{category}
Categories: requirements, architecture, api, database, decisions
Workflow Integration
Plan Phase (manager-spec):
At SPEC completion, store:
Key: context_SPEC-001_requirements
Value: {
"summary": "User authentication with JWT",
"acceptance_criteria": ["AC1", "AC2", "AC3"],
"tech_decisions": ["JWT", "Redis sessions"],
"constraints": ["No external auth providers"]
}
Run Phase (manager-ddd, expert-backend, expert-frontend):
On task start, retrieve:
Key: context_SPEC-001_requirements Action: Load requirements summary
On architecture decision, store:
Key: context_SPEC-001_architecture
Value: {
"pattern": "Clean Architecture",
"layers": ["domain", "application", "infrastructure"],
"api_style": "REST with OpenAPI 3.0"
}
Sync Phase (manager-docs):
Retrieve all context for documentation:
Keys: context_SPEC-001_* Action: Generate comprehensive documentation
Handoff Protocol
Step 1: Store handoff before agent completion
Key: handoff_manager-spec_manager-ddd_SPEC-001
Value: {
"spec_id": "SPEC-001",
"status": "approved",
"key_requirements": [...],
"tech_stack": [...],
"priority_order": [...],
"estimated_complexity": "medium"
}
Step 2: Retrieve handoff on agent start
Key: handoff_manager-spec_manager-ddd_SPEC-001 Action: Load context and continue workflow
Step 3: Update progress
Key: context_SPEC-001_progress
Value: {
"completed_tasks": ["API design", "Database schema"],
"in_progress": ["Authentication implementation"],
"blocked": [],
"completion_percentage": 60
}
Context Categories
| Category | Purpose | Stored By | Used By |
|---|---|---|---|
requirements | SPEC requirements | manager-spec | All agents |
architecture | Architecture decisions | manager-strategy | expert-* |
api | API contracts | expert-backend | expert-frontend |
database | Schema decisions | expert-backend | All agents |
decisions | Key decisions log | All agents | manager-docs |
progress | Workflow progress | All agents | Alfred |
Best Practices for Agent Sharing
Store Strategically:
- •Store at workflow boundaries (phase completion)
- •Store when making important decisions
- •Store when context exceeds prompt capacity
Retrieve Efficiently:
- •Retrieve at agent start
- •Retrieve when context is needed
- •Cache retrieved values in prompt context
Keep Values Structured:
- •Use JSON for complex data
- •Include timestamps for tracking
- •Keep values under 2000 characters
Example: Full Workflow
1. manager-spec completes SPEC-001 └─ Store: context_SPEC-001_requirements └─ Store: handoff_manager-spec_manager-ddd_SPEC-001 2. manager-ddd starts └─ Retrieve: handoff_manager-spec_manager-ddd_SPEC-001 └─ Retrieve: context_SPEC-001_requirements 3. expert-backend implements API └─ Retrieve: context_SPEC-001_requirements └─ Store: context_SPEC-001_api └─ Store: context_SPEC-001_database 4. expert-frontend implements UI └─ Retrieve: context_SPEC-001_api └─ Store: context_SPEC-001_frontend 5. manager-docs generates documentation └─ Retrieve: context_SPEC-001_* (all) └─ Generate comprehensive docs
Works Well With
- •moai-foundation-context - Token budget and session management
- •moai-foundation-core - SPEC-First workflow integration
- •moai-workflow-project - Project configuration persistence
- •moai-foundation-claude - Claude Code patterns
Success Metrics
- •Preference Persistence: User preferences maintained across sessions
- •Context Continuity: Project context available without re-explanation
- •Learning Efficiency: Reduced repetitive questions over time
- •Session Recovery: Quick resumption with session state
Status: Production Ready MCP Integration: @modelcontextprotocol/server-memory Generated with: MoAI-ADK Skill Factory