Design note: memory capture tiers and MCP chat proxy #38

Memory capture tiers

Three distinct tiers of memory capture depending on how Ragger is accessed:

Tier 1 — Client-driven (MCP or HTTP memory-only)

The client (e.g. OpenClaw) handles LLM calls itself and calls Ragger's
memory tools selectively. What gets stored is determined by:

• Client-side trigger rules (e.g. OC plugin's CAPTURE_TRIGGERS keyword list)
• LLM tool calls (memory_store) when the agent decides something is worth keeping
• Both can be tuned by the agent itself — writing better triggers or adjusting
  the system prompt to encourage proactive storage is an agent-manageable task,
  no code change needed

Coverage: partial. Misses turns that don't match triggers and conversations
where the LLM doesn't invoke memory_store.

Tier 2 — Ragger-chat direct (CLI `ragger chat` or HTTP web UI)

Ragger is the chat interface. Every turn is captured unconditionally — user
message and assistant response — before any summarization or housekeeping.
No client-side trigger logic involved.

Tier 3 — Ragger-chat proxy (HTTP LM proxy)

Ragger sits between the client and the LLM endpoint, intercepting the full
OpenAI-compatible stream. Every turn passing through is captured regardless
of which client sent it. Highest coverage, but requires routing all LLM
calls through Ragger's proxy port.

MCP chat proxy — feasibility

Question: Can Ragger proxy a full chat session through MCP (JSON-RPC over
stdin/stdout), similar to `ragger chat` but without the CLI prompts?

Answer: Yes, technically. This would be a new MCP tool, e.g. `chat` or
`send_message`:

```json
{
"name": "chat",
"description": "Send a message; Ragger injects memory context, calls the configured LLM, captures the turn, returns the response.",
"inputSchema": {
"type": "object",
"properties": {
"message": { "type": "string" },
"session_id": { "type": "string" }
},
"required": ["message"]
}
}
```

Ragger would:

1. Search memory for relevant context
2. Build the prompt (system + injected memories + session history)
3. Call the configured LLM (LM Studio or other inference provider)
4. Capture both sides of the turn
5. Return the response text as the tool result

Key tradeoff — streaming:
Standard MCP tool results are returned whole, after the LLM finishes. No
token-by-token streaming to the caller. MCP progress notifications exist
but are not universally supported by clients.

Suitable for:

• Automation / scripting (response latency is acceptable)
• Custom integrations that speak MCP and want chat + memory in one call
• Headless agents where streaming UX doesn't matter

Not suitable for:

• Interactive chat where the user watches tokens arrive
• Replacing OpenClaw's own LLM routing (OC handles model selection,
  tool use, conversation state — routing through Ragger's MCP would
  remove that control)

For interactive use, `ragger chat` (CLI) and the HTTP web UI remain the
right paths. The HTTP proxy covers the "every turn captured" requirement
for non-interactive OpenAI-compatible clients.

Related

• Issue Labeled API tokens for non-local users #36 — labeled API tokens (auth for non-local MCP callers)
• LM proxy implementation in src/server.cpp