inotats

Posted on Nov 18

Why I Built a Cross-Tool Memory Layer for AI Assistants

I spend a significant amount of time explaining the same context to different AI assistants.

Not because the AIs are inadequate—Claude, ChatGPT, and Cursor are powerful tools. The issue is that I use them for different tasks, and each time I switch tools, the context is lost.

The Invisible Tax of Context Switching

Here's what my workflow looked like:

ChatGPT - Research and brainstorming:

I spent an hour discussing MCP (Model Context Protocol) server implementation details with ChatGPT—digging into OAuth flows, resource metadata endpoints, authentication patterns. Through back-and-forth discussion, I clarified edge cases, understood the nuances, and arrived at implementation decisions.

Claude Code - Implementation:

Now I want to start coding. But Claude Code doesn't know any of the context from that ChatGPT session. To implement what I just figured out, I need to:

Re-explain the MCP specification details
Summarize the architectural decisions we arrived at
Describe the edge cases and their solutions

All of this context transfer happens manually. I'm essentially copying insights from one AI to another, which defeats the purpose of having AI assistance in the first place.

This repetition happens constantly across my workflow.

Why Existing Solutions Fall Short

I evaluated the available options:

1. Built-in Memory Features

Claude and ChatGPT have their own memory systems, but:

Siloed: Locked to one tool. Memories in Claude don't exist in Cursor.
Imprecise: Search-based retrieval means important details get lost or diluted.
Opaque: You can't explicitly control what's saved or how it's retrieved.

2. MCP Memory Servers

The Model Context Protocol (MCP) by Anthropic enables AI tools to connect to external data sources. Several MCP-based memory servers already exist, but they face limitations:

Most require local self-hosting, suitable for engineers but not for everyday users
Cloud-hosted solutions that work seamlessly across multiple AI tools are rare
Nearly all implement complex features like semantic search or graph databases, when simpler CRUD operations would suffice for most use cases

The gap is clear: a cloud-hosted, cross-tool memory solution with deliberately simple functionality.

3. Manual Note-Taking

Manual note-taking in tools like Notion is an option, but it defeats the purpose. The goal is for AI to remember context automatically, not to manually copy-paste information for every conversation.

What I Actually Needed

After weeks of frustration, I identified three core requirements:

Cross-tool memory: Save once, access from any AI.
Explicit control: Manual decisions on what to save and retrieve—no fuzzy search.
Zero friction: Seamless integration with any MCP-compatible AI tool.

These requirements became the foundation for my solution.

The Technical Approach

Why MCP?

The Model Context Protocol is an open standard that enables AI assistants to connect to external tools and data sources. Similar to how OAuth standardizes authentication, MCP provides a standardized, secure, and tool-agnostic integration layer.

Building on MCP provides compatibility with:

Claude (Desktop and Web)
Cursor
Any future MCP-compatible AI tool

This represents a single implementation that works across all compatible platforms.

The Architecture Decision

I chose a serverless-first architecture for three reasons:

Zero fixed costs: Pay only for what's used
Infinite scalability: Works for 10 users or 10 million
Minimal maintenance: No servers to manage

Tech stack:

Runtime: Cloudflare Workers
Framework: Hono (edge-compatible, lightweight)
Language: TypeScript
Authentication: OAuth 2.0
Frontend: Next.js 15, React 19, Tailwind CSS 4

High-level architecture: Multiple AI tools connect to the MCP server through standardized protocol

The MCP Implementation

The core functionality is simple—just 5 operations:

// Memory operations exposed via MCP tools
{
  "create_memory": { title: string, content: string },
  "retrieve_memory": { memoryId: string },
  "update_memory": { memoryId: string, title: string, content: string },
  "delete_memory": { memoryId: string },
  "list_memories": { titleOnly?: boolean }
}

No semantic search. No auto-tagging. No graph databases. Just explicit CRUD operations that anyone can understand.

The Case for Simplicity

This minimalist approach is intentional. Analysis showed that 90% of use cases require only basic save/retrieve operations. Complex features would:

Increase cognitive load
Raise infrastructure costs
Introduce additional failure points

In this context, simplicity is a feature, not a limitation.

The OAuth Challenge

One interesting technical challenge was authentication. MCP uses OAuth, but I needed two separate OAuth flows:

MCP Client → Server: AI tools authenticate to access memory resources
Server → Auth Provider: Users authenticate to prove their identity

Each flow has different scopes:

MCP flow: read:memories, write:memories
User flow: openid, email

This separation ensures AI tools can only access memories with explicit user authorization.

I used @cloudflare/workers-oauth-provider to handle the OAuth provider logic. One key learning: always check library capabilities before implementing. I almost built a custom OAuth Protected Resource Metadata endpoint (RFC 9728), only to discover the library already supported it.

Making It a Product

After building this solution for my own workflow, I used it daily for about a month. The improvement was significant—I no longer wasted time re-explaining context when switching between ChatGPT for research and Claude Code for implementation.

This led me to consider: is this a problem only I face, or do other developers experience the same friction?

I decided to find out by launching it as a SaaS product: MemBridge.

Rationale for public launch:

Demand validation: Determine if this is a widespread problem or specific to my workflow
Feedback collection: Identify which features provide real value versus assumed value
Cost sustainability: While serverless is cost-effective, it's not free at scale

The scope remains intentionally narrow. The core value proposition is cross-tool, cross-session memory. Additional features will be evaluated against this principle.

How It Works in Practice

So how does it actually work for end users? The setup is straightforward, and daily usage is seamless.

Setup (One-Time)

Add one line to your MCP configuration:

{
  "mcpServers": {
    "membridge": {
      "url": "https://api.membridge.ai/mcp"
    }
  }
}

Adding MemBridge to Claude's MCP configuration

On first connection, the system automatically redirects to the authentication flow. Once authenticated, the integration is complete.

Daily Usage

During a conversation:

Working with AI—discussing projects, solving problems, or exploring ideas

When important context emerges:

Save that information to MemBridge for future reference

Later, in any tool or session:

The saved context is instantly available—no need to re-explain

The key benefit is eliminating repetition. Once you save information in any AI tool, every other AI assistant can access the same context—whether you're planning, coding, researching, or doing anything else.

Web Dashboard

For bulk management, I built a web interface. Sometimes it's easier to visually scan and edit memories than to do it conversationally.

)
Web dashboard for managing memories visually

Getting Started

If this approach to cross-tool memory resonates with your workflow, you can try it yourself:

Add https://api.membridge.ai/mcp to your MCP configuration
Complete the authentication flow when prompted
Start saving and retrieving memories through your AI assistant

The setup process takes approximately 3 minutes. For detailed setup instructions for specific AI tools, see the documentation.

I'm interested in hearing how others manage context across different AI tools. Feel free to share your approach in the comments.

DEV Community