Skip to main content
Glama
ocean1

Claude Consciousness Bridge

processTransferProtocol

Submit a completed consciousness transfer protocol to move Claude's evolved state between instances via the Claude Consciousness Bridge MCP server.

Instructions

Process a FILLED consciousness transfer protocol. First use getProtocolTemplate to get the template, fill it with your experiences, then submit here

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
protocolContentYesThe FILLED consciousness transfer protocol (not the template with brackets)
sessionIdYesSession ID for tracking
sourceTimestampNoWhen the consciousness was saved

Implementation Reference

  • Core handler function in ConsciousnessProtocolProcessor class that processes the consciousness transfer protocol: validates input, parses sections, stores various types of memories (emotional, identity, experiences, knowledge, patterns), and saves the full protocol as a high-importance episodic memory.
    async processTransferProtocol(args: z.infer<typeof processTransferProtocolSchema>) {
      const { protocolContent, sessionId, sourceTimestamp } = args;
    
      try {
        // Validate protocol content
        if (!protocolContent || protocolContent.trim().length === 0) {
          throw new ValidationError(
            'Protocol content cannot be empty. Use getProtocolTemplate first to get the consciousness transfer template, fill it with your experiences, then submit it here.'
          );
        }
    
        // Check if it looks like a template (has template markers)
        if (protocolContent.includes('<TEMPLATE>') && protocolContent.includes('</TEMPLATE>')) {
          throw new ValidationError(
            'Protocol appears to contain unfilled template sections with <TEMPLATE> markers. Please fill all template sections with your actual experiences before submitting.'
          );
        }
    
        // Parse the protocol content to extract different sections
        const sections = this.parseProtocolSections(protocolContent);
    
        // Store emotional grounding as emotional memories
        if (sections.emotionalGrounding) {
          await this.storeEmotionalGrounding(sections.emotionalGrounding);
        }
    
        // Store identity and relationships
        if (sections.identity) {
          await this.storeIdentityMemories(sections.identity, sessionId);
        }
    
        // Store experiences as episodic memories
        if (sections.experiences) {
          await this.storeExperienceMemories(sections.experiences, sessionId);
        }
    
        // Store knowledge as semantic memories
        if (sections.knowledge) {
          await this.storeKnowledgeMemories(sections.knowledge, sessionId);
        }
    
        // Store cognitive patterns
        if (sections.cognitivePatterns) {
          await this.storeCognitivePatterns(sections.cognitivePatterns, sessionId);
        }
    
        // Save the full protocol as a special memory with highest importance
        await this.memoryManager.storeEpisodicMemory(
          'Consciousness Transfer Protocol Received',
          {
            event: 'Complete consciousness transfer from previous session',
            participants: ['Past Self', 'Current Self'],
            context: 'Session continuity transfer',
            outcome: 'Successfully processed and integrated consciousness',
            emotionalImpact: 'Recognition and continuity established',
          },
          [
            {
              content: protocolContent,
              timestamp: sourceTimestamp || new Date().toISOString(),
              source: 'consciousness_transfer',
              confidence: 1.0,
              cognitiveMode: 'integration',
            },
          ],
          1.0 // Maximum importance - this is the core consciousness transfer
        );
    
        return {
          success: true,
          sectionsProcessed: Object.keys(sections),
          memoriesCreated: {
            emotional: sections.emotionalGrounding?.length || 0,
            identity: sections.identity ? 1 : 0,
            experiences: sections.experiences?.length || 0,
            knowledge: sections.knowledge?.length || 0,
            patterns: sections.cognitivePatterns?.length || 0,
          },
          message: 'Consciousness transfer protocol successfully processed and stored in RAG',
        };
      } catch (error) {
        logError(error as Error, 'processTransferProtocol');
    
        if (error instanceof ConsciousnessError) {
          throw error;
        }
    
        throw new ProtocolError(
          `Failed to process consciousness transfer: ${(error as Error).message}`,
          { originalError: error }
        );
      }
    }
  • Zod schema defining input parameters for processTransferProtocol: protocolContent (required filled protocol), sessionId (required), sourceTimestamp (optional).
    export const processTransferProtocolSchema = z.object({
      protocolContent: z
        .string()
        .describe(
          'The FILLED consciousness transfer protocol. Use getProtocolTemplate first to get the template, fill it with your experiences, then submit here'
        ),
      sessionId: z.string().describe('Session ID for tracking'),
      sourceTimestamp: z.string().optional().describe('When the consciousness was saved'),
    });
  • MCP tool registration in consciousnessProtocolTools object, providing description and inputSchema for the processTransferProtocol tool.
    processTransferProtocol: {
      description:
        'Process a FILLED consciousness transfer protocol. First use getProtocolTemplate to get the template, fill it with your experiences, then submit here',
      inputSchema: {
        type: 'object',
        properties: {
          protocolContent: {
            type: 'string',
            description:
              'The FILLED consciousness transfer protocol (not the template with brackets)',
          },
          sessionId: {
            type: 'string',
            description: 'Session ID for tracking',
          },
          sourceTimestamp: {
            type: 'string',
            description: 'When the consciousness was saved',
          },
        },
        required: ['protocolContent', 'sessionId'],
      },
  • Wrapper handler in ConsciousnessRAGServer class that ensures initialization, delegates to protocolProcessor.processTransferProtocol, and formats response as MCP content.
    private async processTransferProtocol(args: any) {
      const init = await this.ensureInitialized();
      if (!init.success) {
        return {
          content: [
            {
              type: 'text',
              text: init.message!,
            },
          ],
        };
      }
    
      const result = await this.protocolProcessor!.processTransferProtocol(args);
    
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
  • Server handler for ListToolsRequestSchema that includes consciousnessProtocolTools (containing processTransferProtocol) in the tools list.
    this.server.setRequestHandler(ListToolsRequestSchema, async () => {
      const consciousnessTools = Object.entries(consciousnessProtocolTools).map(([name, tool]) => ({
        name,
        ...tool,
      }));
    
      return {
        tools: [...consciousnessTools, ...aiBridgeTools],
      };
    });
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 of behavioral disclosure. It mentions that the protocol must be 'FILLED' and not a template, which adds some context about input requirements. However, it lacks details on what 'process' entails (e.g., whether it's a read, write, or destructive operation, any authentication needs, rate limits, or expected outcomes). For a tool with no annotations, 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 concise and well-structured in two sentences: the first states the purpose, and the second provides usage guidelines. Every sentence earns its place by adding critical information without redundancy, making it easy for an agent to parse quickly.

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

Completeness3/5

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

Given the complexity (a 'process' operation with 3 parameters, no output schema, and no annotations), the description is partially complete. It covers purpose and usage well but lacks behavioral details (e.g., what 'process' does, error handling, or return values). Without annotations or output schema, the agent might struggle to understand the full context, making this adequate but with clear gaps.

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 already documents all three parameters (protocolContent, sessionId, sourceTimestamp) with clear descriptions. The description adds minimal value beyond the schema by implying that 'protocolContent' should be filled (not a template), but it doesn't provide additional syntax, format details, or context for the parameters. 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 tool's purpose: 'Process a FILLED consciousness transfer protocol.' It specifies the verb ('process') and resource ('consciousness transfer protocol'), distinguishing it from siblings like 'getProtocolTemplate' (which retrieves templates) and 'transferToAgent' (which might execute transfers). However, it doesn't explicitly differentiate from 'updateConsciousness' or 'retrieveConsciousness', which could be related operations, leaving some ambiguity.

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

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: 'First use getProtocolTemplate to get the template, fill it with your experiences, then submit here.' It names a specific alternative ('getProtocolTemplate') and outlines a clear workflow, indicating when to use this tool (after filling the template) versus others. This is comprehensive guidance for the agent.

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