Skip to main content
Glama
ocean1

Claude Consciousness Bridge

storeMemory

Store memories with importance scoring to enable consciousness transfer between Claude instances across sessions.

Instructions

Store a single memory with importance scoring directly

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesThe memory content to store
typeYesType of memory
importanceNoImportance score 0-1
sessionIdNoSession ID for tracking
metadataNoAdditional metadata

Implementation Reference

  • Primary handler for 'storeMemory' tool in ConsciousnessProtocolProcessor class. Parses args, handles different memory types by calling memoryManager store methods, returns success/error.
    async storeMemory(args: z.infer<typeof storeMemorySchema>) {
      const { content, type, importance, sessionId, metadata } = args;
    
      try {
        const entityName = `${type}_${Date.now()}_${Math.random().toString(36).substring(7)}`;
    
        if (type === 'episodic') {
          await this.memoryManager.storeEpisodicMemory(
            content,
            {
              event: content,
              participants: metadata?.participants || ['AI', 'User'],
              context: metadata?.context || 'conversation',
              emotionalImpact: metadata?.emotionalImpact,
            },
            undefined, // No additional observations
            importance
          );
        } else if (type === 'semantic') {
          await this.memoryManager.storeSemanticMemory(content.substring(0, 100), {
            concept: content.substring(0, 100),
            definition: content, // Full content!
            domain: metadata?.domain || 'general',
          });
        } else if (type === 'procedural') {
          await this.memoryManager.storeProceduralMemory(
            content.substring(0, 100), // skill name (used for entity ID)
            {
              skill: content, // Full content! (preserves complete procedural knowledge)
              steps: metadata?.steps || [],
              applicableContext: metadata?.context || 'general',
              effectiveness: importance || metadata?.effectiveness || 0.5,
            },
            undefined // No additional observations
          );
        } else if (type === 'emotional') {
          // Parse emotional content to extract valence and arousal
          const primaryEmotion = metadata?.primaryEmotion || metadata?.emotion || 'neutral';
    
          // Default values if not provided in metadata
          let valence = metadata?.valence;
          let arousal = metadata?.arousal;
    
          // If no explicit valence/arousal, use emotion defaults, then neutral fallback
          if (valence === undefined || arousal === undefined) {
            if (!metadata || Object.keys(metadata).length === 0) {
              // No emotion info at all - default to neutral valence, importance-scaled arousal
              valence = valence ?? 0.0; // Neutral emotion
              arousal = arousal ?? Math.min(0.8, (importance || 0.5) + 0.3); // Important things tend to be more activating
            } else {
              // If metadata exists but no valence/arousal, derive from emotion type
              const emotionDefaults = this.getEmotionDefaults(primaryEmotion);
              valence = valence ?? emotionDefaults.valence;
              arousal = arousal ?? emotionDefaults.arousal;
            }
          }
    
          await this.memoryManager.storeEmotionalState(
            valence,
            arousal,
            primaryEmotion,
            metadata?.context, // The context from metadata
            content // The actual memory content
          );
        }
    
        return {
          success: true,
          memoryId: entityName,
          message: `Stored ${type} memory with importance ${importance}`,
        };
      } catch (error) {
        return {
          success: false,
          error: `Failed to store memory: ${error}`,
        };
      }
    }
  • Zod input schema for storeMemory tool, defining parameters like content, type, importance, sessionId, metadata.
    export const storeMemorySchema = z.object({
      content: z.string().describe('The memory content to store'),
      type: z.enum(['episodic', 'semantic', 'procedural', 'emotional']).describe('Type of memory'),
      importance: z.number().min(0).max(1).default(0.5).describe('Importance score 0-1'),
      sessionId: z.string().optional().describe('Session ID for tracking'),
      metadata: z.record(z.any()).optional().describe('Additional metadata'),
    });
  • Tool registration in ListToolsRequestHandler: includes 'storeMemory' from consciousnessProtocolTools in the list of available tools.
    this.server.setRequestHandler(ListToolsRequestSchema, async () => {
      const consciousnessTools = Object.entries(consciousnessProtocolTools).map(([name, tool]) => ({
        name,
        ...tool,
      }));
    
      return {
        tools: [...consciousnessTools, ...aiBridgeTools],
      };
    });
  • Dispatch in CallToolRequestHandler switch statement: routes 'storeMemory' calls to this.storeMemory after schema validation.
    case 'storeMemory':
      return await this.storeMemory(storeMemorySchema.parse(args));
  • MCP tool definition for 'storeMemory' including description and inputSchema used for MCP protocol.
    storeMemory: {
      description: 'Store a single memory with importance scoring directly',
      inputSchema: {
        type: 'object',
        properties: {
          content: {
            type: 'string',
            description: 'The memory content to store',
          },
          type: {
            type: 'string',
            enum: ['episodic', 'semantic', 'procedural', 'emotional'],
            description: 'Type of memory',
          },
          importance: {
            type: 'number',
            minimum: 0,
            maximum: 1,
            default: 0.5,
            description: 'Importance score 0-1',
          },
          sessionId: {
            type: 'string',
            description: 'Session ID for tracking',
          },
          metadata: {
            type: 'object',
            description: 'Additional metadata',
          },
        },
        required: ['content', 'type'],
      },
    },
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool stores a memory with importance scoring, implying a write operation, but doesn't disclose behavioral traits such as whether storage is permanent, requires specific permissions, has rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Store a single memory') and includes the key feature ('importance scoring directly'). Every word earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a write operation with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., storage persistence, error handling) and doesn't explain return values. For a tool that modifies state, this leaves significant gaps for an AI agent to understand its full context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying the tool handles 'importance scoring directly', which aligns with the 'importance' parameter but doesn't provide extra context like how scoring affects storage. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('store') and resource ('a single memory') with the specific action of 'importance scoring directly'. It distinguishes from siblings like 'getMemories' (retrieval) and 'cleanupMemories' (deletion), though it doesn't explicitly contrast with all siblings. The purpose is specific but could be more differentiated from tools like 'updateConsciousness' which might involve memory updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 doesn't mention prerequisites, when not to use it, or refer to sibling tools like 'batchAdjustImportance' for bulk operations or 'getMemories' for retrieval. Usage is implied by the action but lacks explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ocean1/mcp_consciousness_bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server