MCP Server

Litica gives agents four tools over the Model Context Protocol: save memory, bring it back, and save many memories or whole documents at once. Any MCP-compatible agent can use them with no code changes.

Overview

The Model Context Protocol is a standard for connecting external tools to AI models. The Litica MCP server implements this protocol to give any compatible agent lasting, structured memory for saving and recalling context. Once configured, the agent calls these tools on its own when they help with the task at hand.

The server supports two transports: HTTP (for production and remote deployments) and stdio (for local Claude Desktop use). Both expose the same four tools. Each agent has its own memory, keyed byagent_id.

Tools at a glance

This is exactly what each tool tells the agent. Your MCP client shows these descriptions in its tool list, and the model reads them to decide when to call each one.

add_memory(content, agent_id?, namespace_id?)

Store a memory for the authenticated tenant.

search_memory(query, top_k?, agent_id?, namespace_id?)

Search memories for the authenticated tenant.

add_memories_batch(contents, agent_id?, namespace_id?)

Store a batch of memories for the authenticated tenant. Enqueue order is persist order; decomposition runs in the background.

add_documents(documents, agent_id?, namespace_id?)

Store a batch of documents for the authenticated tenant. Each document is recursively decomposed into atomic memories in the background. Pass already-extracted text — file bytes (PDF/DOCX/…) are not parsed here.

Reference

Full parameters, defaults, and return values for each tool.

add_memory

Saves context to the agent's memory. Litica breaks the content down into what it's about (the goal, the people and things, the mood, and the timing), turns each part into vectors with a local sentence-transformers model (all-MiniLM-L6-v2, 384-dim, runs on CPU), and stores it in PostgreSQL with pgvector. It records who wrote it and when.

parameters

content: str          # The experience to store (required)
agent_id: str         # Agent identifier, default "default"
namespace_id: str     # Optional shared namespace; omit for agent-scoped memory

Returns a confirmation string when the memory is stored.

search_memory

Brings back the context that fits a natural-language query. Litica figures out what the query is about, checks all four parts of memory at once, scores the matches, and gives a boost to memories that have proven useful before. Returns ranked results, each showing where it came from.

parameters

query: str            # Natural language query (required)
top_k: int            # Number of results, default 5
agent_id: str         # Agent identifier, default "default"
namespace_id: str     # Optional shared namespace; omit for agent-scoped memory

Returns a list of memory text strings ordered by relevance.

add_memories_batch

Saves many memories in one call. Same as add_memory, but for a list. They are saved in the order you send them, and broken down the same way in the background.

parameters

contents: list[str]   # One or more memory texts (required)
agent_id: str         # Agent identifier, default "default"
namespace_id: str     # Optional shared namespace; omit for agent-scoped memory

Returns a confirmation string once the memories are queued.

add_documents

Saves whole documents at once. Pass the text of each document (already pulled out of the file — this tool does not read PDFs or Word files directly). Litica splits each one into smaller memories in the background, so you can search them like anything else.

parameters

documents: list[str]  # One or more document texts (required)
agent_id: str         # Agent identifier, default "default"
namespace_id: str     # Optional shared namespace; omit for agent-scoped memory

Returns a confirmation string once the documents are queued. To upload a raw file (PDF, DOCX, PPTX), use the POST /documents endpoint in the API reference instead.

How retrieval works

When search_memory is called, Litica does the following:

Figures out what the query is about (goal, people and things, mood, timing) using Gemini (gemini-3-flash-preview)
Matches each part against your stored memories at the same time
Combines the scores (goals 30%, people and things 25%, mood 20%, timing 25%), with a bonus when a memory matches on more than one part
Boosts memories you use a lot, and lets older ones fade (about a week's half-life by default)
Adds a bonus from connected memories that share a goal, a person or thing, or a mood
Returns the top-k results by final score

The more a memory gets used, the more easily it comes back next time. And memories pull up the ones they're connected to, instead of every search starting from scratch.

Shared memory across agents

By default, each agent has its own private memory, keyed by agent_id. Pass anamespace_id to both tools to share memory across agents: what one agent saves, another can bring back. You set per-agent read and write access, so you control exactly which agents can see or add to the shared memory.

Compatibility

The Litica MCP server works with any MCP-compatible host, including:

Claude Desktop (HTTP or stdio transport)
Claude Code CLI (HTTP transport via .mcp.json)
Cursor (HTTP transport)
Any custom agent built with the MCP SDK

Ready to connect? See the configuration guide.