# ADR-0001: Start Without MCP-Side Memory
**Date:** 2026-01-22
**Status:** Accepted
**Deciders:** Architecture team
## Context
The Jana MCP Server will provide AI-powered access to environmental data through MCP (Model Context Protocol) clients like Cursor and Claude Code. A key architectural question is whether the MCP server should maintain its own conversation history and session context, or rely on the client to manage this.
MCP clients like Cursor and Claude Code already manage conversation history:
- They maintain the full conversation context
- They send conversation history to the LLM (Claude) with each request
- The LLM sees prior messages and can understand refinement queries like "now filter that by country"
- The MCP server only receives individual tool calls with explicit parameters
This means basic conversational features already work without MCP-side storage:
- Refinement queries ("now compare to LA")
- Follow-up questions ("what about last month?")
- Multi-step analyses (Claude orchestrates multiple tool calls)
However, MCP-side memory could enable additional features:
- Cross-session recall ("resume yesterday's analysis")
- Named queries ("save this as 'coal plants Texas'")
- User preferences ("always use metric units")
- Query audit logs for compliance
## Decision Drivers
- **Time to MVP:** We want to ship a useful MCP server quickly
- **Complexity:** Stateful servers are harder to build, deploy, and debug
- **Client capabilities:** Cursor/Claude Code already handle conversation context well
- **Uncertain value:** Unclear if users need cross-session features
- **Existing infrastructure:** Jana backend already has Redis and PostgreSQL if needed later
## Considered Options
### Option 1: Stateless MCP Server (No Memory)
**Description:** MCP server processes each tool call independently with no server-side state. All conversation context is managed by the MCP client.
**Pros:**
- Simplest architecture
- Fastest to implement
- Easy to deploy (no state management)
- Scales horizontally without session affinity
- Conversation refinement already works via client
**Cons:**
- No cross-session recall
- Cannot save named queries
- No persistent user preferences
- No server-side query audit log
### Option 2: In-Memory Session Storage
**Description:** MCP server maintains session context in memory, lost on restart.
**Pros:**
- Simple implementation
- Fast access
- Enables some session features
**Cons:**
- Lost on server restart
- Doesn't scale across instances
- Memory grows unbounded
- Still no cross-session recall
### Option 3: Redis-Based Session Storage
**Description:** Store session context in Redis with TTL-based expiration.
**Pros:**
- Survives server restarts
- Shared across instances
- TTL handles cleanup
- Jana backend already has Redis
**Cons:**
- Additional complexity
- Still ephemeral (not permanent)
- Requires session ID management
- Over-engineering for unclear value
### Option 4: PostgreSQL Persistent Storage
**Description:** Store queries, preferences, and audit logs in PostgreSQL.
**Pros:**
- Permanent persistence
- Full query history
- Supports named queries
- Audit trail for compliance
**Cons:**
- Most complex option
- Requires schema design and maintenance
- Slowest option
- Overkill for MVP
## Decision
**We will start with Option 1: Stateless MCP Server.**
The MCP server will be stateless, processing each tool call independently without maintaining conversation history or session context. We rely on Cursor/Claude Code to manage conversation context.
**Rationale:**
1. Client-managed context already handles 90% of conversational use cases
2. Stateless architecture is simpler to build, test, and deploy
3. We can ship an MVP faster
4. Cross-session features can be added later if users request them
5. The Jana backend already has Redis/PostgreSQL if we need to add state later
## Consequences
### Positive
- Faster time to MVP
- Simpler codebase (no session management, no database schemas for state)
- Easier deployment (no sticky sessions, horizontal scaling)
- Easier testing (no state to set up/tear down)
- Focus on making individual tools excellent
### Negative
- Cannot support "resume yesterday's analysis" without reimplementation
- Cannot save named queries server-side
- No server-side user preferences
- No built-in query audit log (though calls could be logged elsewhere)
### Neutral
- May need to revisit this decision if users strongly request cross-session features
- Could implement client-side storage (Cursor settings) for preferences instead
- Audit logging could be added to the Jana backend instead of MCP server
## Implementation Notes
The MCP server will:
- Expose tools that accept fully-specified parameters
- Not track session IDs or user context
- Return results directly without storing them
- Let Claude (via the client) handle multi-step orchestration
If we later need to add state, the recommended approach is:
1. Redis for ephemeral session context (TTL 1-24 hours)
2. PostgreSQL for permanent storage (named queries, audit logs)
3. Keep the MCP server itself stateless, with state in external stores
## References
- [MCP Server Brainstorm](../MCP_SERVER_BRAINSTORM.md) - Section 11: Conversational Memory & Context
- [MCP Protocol Documentation](https://modelcontextprotocol.io/)
- Discussion on MCP architecture patterns in design session 2026-01-22
