@mastra/mcp-docs-server 0.0.0-error-handler-fix-20251020202607 → 0.0.0-execa-dynamic-import-20260304221256

package/.docs/docs/memory/memory-processors.md

@@ -0,0 +1,314 @@
+# Memory Processors
+
+Memory processors transform and filter messages as they pass through an agent with memory enabled. They manage context window limits, remove unnecessary content, and optimize the information sent to the language model.
+
+When memory is enabled on an agent, Mastra adds memory processors to the agent's processor pipeline. These processors retrieve message history, working memory, and semantically relevant messages, then persist new messages after the model responds.
+
+Memory processors are [processors](https://mastra.ai/docs/agents/processors) that operate specifically on memory-related messages and state.
+
+## Built-in Memory Processors
+
+Mastra automatically adds these processors when memory is enabled:
+
+### MessageHistory
+
+Retrieves message history and persists new messages.
+
+**When you configure:**
+
+```typescript
+memory: new Memory({
+  lastMessages: 10,
+})
+```
+
+**Mastra internally:**
+
+1. Creates a `MessageHistory` processor with `limit: 10`
+2. Adds it to the agent's input processors (runs before the LLM)
+3. Adds it to the agent's output processors (runs after the LLM)
+
+**What it does:**
+
+- **Input**: Fetches the last 10 messages from storage and prepends them to the conversation
+- **Output**: Persists new messages to storage after the model responds
+
+**Example:**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { LibSQLStore } from '@mastra/libsql'
+import { openai } from '@ai-sdk/openai'
+
+const agent = new Agent({
+  id: 'test-agent',
+  name: 'Test Agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'memory-store',
+      url: 'file:memory.db',
+    }),
+    lastMessages: 10, // MessageHistory processor automatically added
+  }),
+})
+```
+
+### SemanticRecall
+
+Retrieves semantically relevant messages based on the current input and creates embeddings for new messages.
+
+**When you configure:**
+
+```typescript
+memory: new Memory({
+  semanticRecall: { enabled: true },
+  vector: myVectorStore,
+  embedder: myEmbedder,
+})
+```
+
+**Mastra internally:**
+
+1. Creates a `SemanticRecall` processor
+2. Adds it to the agent's input processors (runs before the LLM)
+3. Adds it to the agent's output processors (runs after the LLM)
+4. Requires both a vector store and embedder to be configured
+
+**What it does:**
+
+- **Input**: Performs vector similarity search to find relevant past messages and prepends them to the conversation
+- **Output**: Creates embeddings for new messages and stores them in the vector store for future retrieval
+
+**Example:**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { LibSQLStore } from '@mastra/libsql'
+import { PineconeVector } from '@mastra/pinecone'
+import { OpenAIEmbedder } from '@mastra/openai'
+import { openai } from '@ai-sdk/openai'
+
+const agent = new Agent({
+  name: 'semantic-agent',
+  instructions: 'You are a helpful assistant with semantic memory',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'memory-store',
+      url: 'file:memory.db',
+    }),
+    vector: new PineconeVector({
+      id: 'memory-vector',
+      apiKey: process.env.PINECONE_API_KEY!,
+    }),
+    embedder: new OpenAIEmbedder({
+      model: 'text-embedding-3-small',
+      apiKey: process.env.OPENAI_API_KEY!,
+    }),
+    semanticRecall: { enabled: true }, // SemanticRecall processor automatically added
+  }),
+})
+```
+
+### WorkingMemory
+
+Manages working memory state across conversations.
+
+**When you configure:**
+
+```typescript
+memory: new Memory({
+  workingMemory: { enabled: true },
+})
+```
+
+**Mastra internally:**
+
+1. Creates a `WorkingMemory` processor
+2. Adds it to the agent's input processors (runs before the LLM)
+3. Requires a storage adapter to be configured
+
+**What it does:**
+
+- **Input**: Retrieves working memory state for the current thread and prepends it to the conversation
+- **Output**: No output processing
+
+**Example:**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { LibSQLStore } from '@mastra/libsql'
+import { openai } from '@ai-sdk/openai'
+
+const agent = new Agent({
+  name: 'working-memory-agent',
+  instructions: 'You are an assistant with working memory',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({
+      id: 'memory-store',
+      url: 'file:memory.db',
+    }),
+    workingMemory: { enabled: true }, // WorkingMemory processor automatically added
+  }),
+})
+```
+
+## Manual Control and Deduplication
+
+If you manually add a memory processor to `inputProcessors` or `outputProcessors`, Mastra will **not** automatically add it. This gives you full control over processor ordering:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { MessageHistory } from '@mastra/core/processors'
+import { TokenLimiter } from '@mastra/core/processors'
+import { LibSQLStore } from '@mastra/libsql'
+import { openai } from '@ai-sdk/openai'
+
+// Custom MessageHistory with different configuration
+const customMessageHistory = new MessageHistory({
+  storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
+  lastMessages: 20,
+})
+
+const agent = new Agent({
+  name: 'custom-memory-agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({
+    storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
+    lastMessages: 10, // This would normally add MessageHistory(10)
+  }),
+  inputProcessors: [
+    customMessageHistory, // Your custom one is used instead
+    new TokenLimiter({ limit: 4000 }), // Runs after your custom MessageHistory
+  ],
+})
+```
+
+## Processor Execution Order
+
+Understanding the execution order is important when combining guardrails with memory:
+
+### Input Processors
+
+```text
+[Memory Processors] → [Your inputProcessors]
+```
+
+1. **Memory processors run FIRST**: `WorkingMemory`, `MessageHistory`, `SemanticRecall`
+2. **Your input processors run AFTER**: guardrails, filters, validators
+
+This means memory loads message history before your processors can validate or filter the input.
+
+### Output Processors
+
+```text
+[Your outputProcessors] → [Memory Processors]
+```
+
+1. **Your output processors run FIRST**: guardrails, filters, validators
+2. **Memory processors run AFTER**: `SemanticRecall` (embeddings), `MessageHistory` (persistence)
+
+This ordering is designed to be **safe by default**: if your output guardrail calls `abort()`, the memory processors never run and **no messages are saved**.
+
+## Guardrails and Memory
+
+The default execution order provides safe guardrail behavior:
+
+### Output guardrails (recommended)
+
+Output guardrails run **before** memory processors save messages. If a guardrail aborts:
+
+- The tripwire is triggered
+- Memory processors are skipped
+- **No messages are persisted to storage**
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { Memory } from '@mastra/memory'
+import { openai } from '@ai-sdk/openai'
+
+// Output guardrail that blocks inappropriate content
+const contentBlocker = {
+  id: 'content-blocker',
+  processOutputResult: async ({ messages, abort }) => {
+    const hasInappropriateContent = messages.some(msg => containsBadContent(msg))
+    if (hasInappropriateContent) {
+      abort('Content blocked by guardrail')
+    }
+    return messages
+  },
+}
+
+const agent = new Agent({
+  name: 'safe-agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({ lastMessages: 10 }),
+  // Your guardrail runs BEFORE memory saves
+  outputProcessors: [contentBlocker],
+})
+
+// If the guardrail aborts, nothing is saved to memory
+const result = await agent.generate('Hello')
+if (result.tripwire) {
+  console.log('Blocked:', result.tripwire.reason)
+  // Memory is empty - no messages were persisted
+}
+```
+
+### Input guardrails
+
+Input guardrails run **after** memory processors load history. If a guardrail aborts:
+
+- The tripwire is triggered
+- The LLM is never called
+- Output processors (including memory persistence) are skipped
+- **No messages are persisted to storage**
+
+```typescript
+// Input guardrail that validates user input
+const inputValidator = {
+  id: 'input-validator',
+  processInput: async ({ messages, abort }) => {
+    const lastUserMessage = messages.findLast(m => m.role === 'user')
+    if (isInvalidInput(lastUserMessage)) {
+      abort('Invalid input detected')
+    }
+    return messages
+  },
+}
+
+const agent = new Agent({
+  name: 'validated-agent',
+  instructions: 'You are a helpful assistant',
+  model: 'openai/gpt-4o',
+  memory: new Memory({ lastMessages: 10 }),
+  // Your guardrail runs AFTER memory loads history
+  inputProcessors: [inputValidator],
+})
+```
+
+### Summary
+
+| Guardrail Type | When it runs               | If it aborts                  |
+| -------------- | -------------------------- | ----------------------------- |
+| Input          | After memory loads history | LLM not called, nothing saved |
+| Output         | Before memory saves        | Nothing saved to storage      |
+
+Both scenarios are safe - guardrails prevent inappropriate content from being persisted to memory
+
+## Related documentation
+
+- [Processors](https://mastra.ai/docs/agents/processors) - General processor concepts and custom processor creation
+- [Guardrails](https://mastra.ai/docs/agents/guardrails) - Security and validation processors
+- [Memory Overview](https://mastra.ai/docs/memory/overview) - Memory types and configuration
+
+When creating custom processors avoid mutating the input `messages` array or its objects directly.

package/.docs/docs/memory/message-history.md

@@ -0,0 +1,260 @@
+# Message History
+
+Message history is the most basic and important form of memory. It gives the LLM a view of recent messages in the context window, enabling your agent to reference earlier exchanges and respond coherently.
+
+You can also retrieve message history to display past conversations in your UI.
+
+> **Info:** Each message belongs to a thread (the conversation) and a resource (the user or entity it's associated with). See [Threads and resources](https://mastra.ai/docs/memory/storage) for more detail.
+
+## Getting started
+
+Install the Mastra memory module along with a [storage adapter](https://mastra.ai/docs/memory/storage) for your database. The examples below use `@mastra/libsql`, which stores data locally in a `mastra.db` file.
+
+**npm**:
+
+```bash
+npm install @mastra/memory@latest @mastra/libsql@latest
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/memory@latest @mastra/libsql@latest
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/memory@latest @mastra/libsql@latest
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/memory@latest @mastra/libsql@latest
+```
+
+Message history requires a storage adapter to persist conversations. Configure storage on your Mastra instance if you haven't already:
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { LibSQLStore } from '@mastra/libsql'
+
+export const mastra = new Mastra({
+  storage: new LibSQLStore({
+    id: 'mastra-storage',
+    url: 'file:./mastra.db',
+  }),
+})
+```
+
+Give your agent a `Memory`:
+
+```typescript
+import { Memory } from '@mastra/memory'
+import { Agent } from '@mastra/core/agent'
+
+export const agent = new Agent({
+  id: 'test-agent',
+  memory: new Memory({
+    options: {
+      lastMessages: 10,
+    },
+  }),
+})
+```
+
+When you call the agent, messages are automatically saved to the database. You can specify a `threadId`, `resourceId`, and optional `metadata`:
+
+**Generate**:
+
+```typescript
+await agent.generate('Hello', {
+  memory: {
+    thread: {
+      id: 'thread-123',
+      title: 'Support conversation',
+      metadata: { category: 'billing' },
+    },
+    resource: 'user-456',
+  },
+})
+```
+
+**Stream**:
+
+```typescript
+await agent.stream('Hello', {
+  memory: {
+    thread: {
+      id: 'thread-123',
+      title: 'Support conversation',
+      metadata: { category: 'billing' },
+    },
+    resource: 'user-456',
+  },
+})
+```
+
+> **Info:** Threads and messages are created automatically when you call `agent.generate()` or `agent.stream()`, but you can also create them manually with [`createThread()`](https://mastra.ai/reference/memory/createThread) and [`saveMessages()`](https://mastra.ai/reference/memory/memory-class).
+
+There are two ways to use this history:
+
+- **Automatic inclusion** - Mastra automatically fetches and includes recent messages in the context window. By default, it includes the last 10 messages, keeping agents grounded in the conversation. You can adjust this number with `lastMessages`, but in most cases you don't need to think about it.
+- [**Manual querying**](#querying) - For more control, use the `recall()` function to query threads and messages directly. This lets you choose exactly which memories are included in the context window, or fetch messages to render conversation history in your UI.
+
+## Accessing Memory
+
+To access memory functions for querying, cloning, or deleting threads and messages, call `getMemory()` on an agent:
+
+```typescript
+const agent = mastra.getAgent('weatherAgent')
+const memory = await agent.getMemory()
+```
+
+The `Memory` instance gives you access to functions for listing threads, recalling messages, cloning conversations, and more.
+
+## Querying
+
+Use these methods to fetch threads and messages for displaying conversation history in your UI or for custom memory retrieval logic.
+
+> **Warning:** The memory system does not enforce access control. Before running any query, verify in your application logic that the current user is authorized to access the `resourceId` being queried.
+
+### Threads
+
+Use [`listThreads()`](https://mastra.ai/reference/memory/listThreads) to retrieve threads for a resource:
+
+```typescript
+const result = await memory.listThreads({
+  filter: { resourceId: 'user-123' },
+  perPage: false,
+})
+```
+
+Paginate through threads:
+
+```typescript
+const result = await memory.listThreads({
+  filter: { resourceId: 'user-123' },
+  page: 0,
+  perPage: 10,
+})
+
+console.log(result.threads) // thread objects
+console.log(result.hasMore) // more pages available?
+```
+
+You can also filter by metadata and control sort order:
+
+```typescript
+const result = await memory.listThreads({
+  filter: {
+    resourceId: 'user-123',
+    metadata: { status: 'active' },
+  },
+  orderBy: { field: 'createdAt', direction: 'DESC' },
+})
+```
+
+To fetch a single thread by ID, use [`getThreadById()`](https://mastra.ai/reference/memory/getThreadById):
+
+```typescript
+const thread = await memory.getThreadById({ threadId: 'thread-123' })
+```
+
+### Messages
+
+Once you have a thread, use [`recall()`](https://mastra.ai/reference/memory/recall) to retrieve its messages. It supports pagination, date filtering, and [semantic search](https://mastra.ai/docs/memory/semantic-recall).
+
+Basic recall returns all messages from a thread:
+
+```typescript
+const { messages } = await memory.recall({
+  threadId: 'thread-123',
+  perPage: false,
+})
+```
+
+Paginate through messages:
+
+```typescript
+const { messages } = await memory.recall({
+  threadId: 'thread-123',
+  page: 0,
+  perPage: 50,
+})
+```
+
+Filter by date range:
+
+```typescript
+const { messages } = await memory.recall({
+  threadId: 'thread-123',
+  filter: {
+    dateRange: {
+      start: new Date('2025-01-01'),
+      end: new Date('2025-06-01'),
+    },
+  },
+})
+```
+
+Fetch a single message by ID:
+
+```typescript
+const { messages } = await memory.recall({
+  threadId: 'thread-123',
+  include: [{ id: 'msg-123' }],
+})
+```
+
+Fetch multiple messages by ID with surrounding context:
+
+```typescript
+const { messages } = await memory.recall({
+  threadId: 'thread-123',
+  include: [
+    { id: 'msg-123' },
+    {
+      id: 'msg-456',
+      withPreviousMessages: 3,
+      withNextMessages: 1,
+    },
+  ],
+})
+```
+
+Search by meaning (see [Semantic recall](https://mastra.ai/docs/memory/semantic-recall) for setup):
+
+```typescript
+const { messages } = await memory.recall({
+  threadId: 'thread-123',
+  vectorSearchString: 'project deadline discussion',
+  threadConfig: {
+    semanticRecall: true,
+  },
+})
+```
+
+### UI format
+
+Message queries return `MastraDBMessage[]` format. To display messages in a frontend, you may need to convert them to a format your UI library expects. For example, [`toAISdkV5Messages`](https://mastra.ai/reference/ai-sdk/to-ai-sdk-v5-messages) converts messages to AI SDK UI format.
+
+## Thread cloning
+
+Thread cloning creates a copy of an existing thread with its messages. This is useful for branching conversations, creating checkpoints before a potentially destructive operation, or testing variations of a conversation.
+
+```typescript
+const { thread, clonedMessages } = await memory.cloneThread({
+  sourceThreadId: 'thread-123',
+  title: 'Branched conversation',
+})
+```
+
+You can filter which messages get cloned (by count or date range), specify custom thread IDs, and use utility methods to inspect clone relationships.
+
+See [`cloneThread()`](https://mastra.ai/reference/memory/cloneThread) and [clone utilities](https://mastra.ai/reference/memory/clone-utilities) for the full API.
+
+## Deleting messages
+
+To remove messages from a thread, use [`deleteMessages()`](https://mastra.ai/reference/memory/deleteMessages). You can delete by message ID or clear all messages from a thread.