@mastra/mcp-docs-server 1.0.0-beta.9 → 1.0.1

package/.docs/raw/mcp/overview.mdx

@@ -1,6 +1,9 @@
 ---
 title: "MCP Overview | MCP"
 description: Learn about the Model Context Protocol (MCP), how to use third-party tools via MCPClient, connect to registries, and share your own tools using MCPServer.
+packages:
+  - "@mastra/core"
+  - "@mastra/mcp"
 ---
 
 import Tabs from "@theme/Tabs";
@@ -29,7 +32,7 @@ npm install @mastra/mcp@beta
 
 The `MCPClient` connects Mastra primitives to external MCP servers, which can be local packages (invoked using `npx`) or remote HTTP(S) endpoints. Each server must be configured with either a `command` or a `url`, depending on how it's hosted.
 
-```typescript title="src/mastra/mcp/test-mcp-client.ts" showLineNumbers copy
+```typescript title="src/mastra/mcp/test-mcp-client.ts"
 import { MCPClient } from "@mastra/mcp";
 
 export const testMcpClient = new MCPClient({
@@ -48,18 +51,29 @@ export const testMcpClient = new MCPClient({
 });
 ```
 
-> See [MCPClient](/reference/v1/tools/mcp-client) for a full list of configuration options.
+:::info
+
+Visit [MCPClient](/reference/v1/tools/mcp-client) for a full list of configuration options.
+
+:::
+
+:::tip Authentication
+
+For connecting to OAuth-protected MCP servers, see the [OAuth Authentication](/reference/v1/tools/mcp-client#oauth-authentication) section.
+
+:::
 
 ## Using `MCPClient` with an agent
 
-To use tools from an MCP server in an agent, import your `MCPClient` and call `.getTools()` in the `tools` parameter. This loads from the defined MCP servers, making them available to the agent.
+To use tools from an MCP server in an agent, import your `MCPClient` and call `.listTools()` in the `tools` parameter. This loads from the defined MCP servers, making them available to the agent.
 
-```typescript {3,15} title="src/mastra/agents/test-agent.ts" showLineNumbers copy
+```typescript {3,15} title="src/mastra/agents/test-agent.ts"
 import { Agent } from "@mastra/core/agent";
 
 import { testMcpClient } from "../mcp/test-mcp-client";
 
 export const testAgent = new Agent({
+  id: "test-agent",
   name: "Test Agent",
   description: "You are a helpful AI assistant",
   instructions: `
@@ -69,17 +83,21 @@ export const testAgent = new Agent({
 
       Answer questions using the information you find using the MCP Servers.`,
   model: "openai/gpt-5.1",
-  tools: await testMcpClient.getTools(),
+  tools: await testMcpClient.listTools(),
 });
 ```
 
-> See the [Agent Class](/reference/v1/agents/agent) for a full list of configuration options.
+:::info
+
+Visit [Agent Class](/reference/v1/agents/agent) for a full list of configuration options.
+
+:::
 
 ## Configuring `MCPServer`
 
 To expose agents, tools, and workflows from your Mastra application to external systems over HTTP(S) use the `MCPServer` class. This makes them accessible to any system or agent that supports the protocol.
 
-```typescript title="src/mastra/mcp/test-mcp-server.ts" showLineNumbers copy
+```typescript title="src/mastra/mcp/test-mcp-server.ts"
 import { MCPServer } from "@mastra/mcp";
 
 import { testAgent } from "../agents/test-agent";
@@ -96,19 +114,28 @@ export const testMcpServer = new MCPServer({
 });
 ```
 
-> See [MCPServer](/reference/v1/tools/mcp-server) for a full list of configuration options.
+:::info
+
+Visit [MCPServer](/reference/v1/tools/mcp-server) for a full list of configuration options.
+
+:::
+
+:::tip Authentication
+
+To protect your MCP server with OAuth, see the [OAuth Protection](/reference/v1/tools/mcp-server#oauth-protection) section.
+
+:::
 
 ## Registering an `MCPServer`
 
 To make an MCP server available to other systems or agents that support the protocol, register it in the main `Mastra` instance using `mcpServers`.
 
-```typescript title="src/mastra/index.ts" showLineNumbers copy
+```typescript title="src/mastra/index.ts"
 import { Mastra } from "@mastra/core/mastra";
 
 import { testMcpServer } from "./mcp/test-mcp-server";
 
 export const mastra = new Mastra({
-  // ...
   mcpServers: { testMcpServer },
 });
 ```
@@ -117,35 +144,39 @@ export const mastra = new Mastra({
 
 `MCPClient` offers two approaches to retrieving tools from connected servers, suitable for different application architectures:
 
-| Feature           | Static Configuration (`await mcp.getTools()`) | Dynamic Configuration (`await mcp.getToolsets()`)    |
-| :---------------- | :-------------------------------------------- | :--------------------------------------------------- |
-| **Use Case**      | Single-user, static config (e.g., CLI tool)   | Multi-user, dynamic config (e.g., SaaS app)          |
-| **Configuration** | Fixed at agent initialization                 | Per-request, dynamic                                 |
-| **Credentials**   | Shared across all uses                        | Can vary per user/request                            |
-| **Agent Setup**   | Tools added in `Agent` constructor            | Tools passed in `.generate()` or `.stream()` options |
+| Feature           | Static Configuration (`await mcp.listTools()`) | Dynamic Configuration (`await mcp.listToolsets()`)   |
+| :---------------- | :--------------------------------------------- | :--------------------------------------------------- |
+| **Use Case**      | Single-user, static config (e.g., CLI tool)    | Multi-user, dynamic config (e.g., SaaS app)          |
+| **Configuration** | Fixed at agent initialization                  | Per-request, dynamic                                 |
+| **Credentials**   | Shared across all uses                         | Can vary per user/request                            |
+| **Agent Setup**   | Tools added in `Agent` constructor             | Tools passed in `.generate()` or `.stream()` options |
 
 ### Static tools
 
-Use the `.getTools()` method to fetch tools from all configured MCP servers. This is suitable when configuration (such as API keys) is static and consistent across users or requests. Call it once and pass the result to the `tools` property when defining your agent.
+Use the `.listTools()` method to fetch tools from all configured MCP servers. This is suitable when configuration (such as API keys) is static and consistent across users or requests. Call it once and pass the result to the `tools` property when defining your agent.
 
-> See [getTools()](/reference/v1/tools/mcp-client#gettools) for more information.
+:::info
 
-```typescript {7} title="src/mastra/agents/test-agent.ts" showLineNumbers copy
+Visit [listTools()](/reference/v1/tools/mcp-client#listtools) for more information.
+
+:::
+
+```typescript {6} title="src/mastra/agents/test-agent.ts"
 import { Agent } from "@mastra/core/agent";
 
 import { testMcpClient } from "../mcp/test-mcp-client";
 
 export const testAgent = new Agent({
-  // ...
-  tools: await testMcpClient.getTools(),
+  id: "test-agent",
+  tools: await testMcpClient.listTools(),
 });
 ```
 
 ### Dynamic tools
 
-Use the `.getToolsets()` method when tool configuration may vary by request or user, such as in a multi-tenant system where each user provides their own API key. This method returns toolsets that can be passed to the `toolsets` option in the agent's `.generate()` or `.stream()` calls.
+Use the `.listToolsets()` method when tool configuration may vary by request or user, such as in a multi-tenant system where each user provides their own API key. This method returns toolsets that can be passed to the `toolsets` option in the agent's `.generate()` or `.stream()` calls.
 
-```typescript {5-16,21} showLineNumbers copy
+```typescript {5-16,21}
 import { MCPClient } from "@mastra/mcp";
 import { mastra } from "./mastra";
 
@@ -166,7 +197,7 @@ async function handleRequest(userPrompt: string, userApiKey: string) {
   const agent = mastra.getAgent("testAgent");
 
   const response = await agent.generate(userPrompt, {
-    toolsets: await userMcp.getToolsets(),
+    toolsets: await userMcp.listToolsets(),
   });
 
   await userMcp.disconnect();
@@ -177,7 +208,11 @@ async function handleRequest(userPrompt: string, userApiKey: string) {
 }
 ```
 
-> See [getToolsets()](/reference/v1/tools/mcp-client#gettoolsets) for more information.
+:::info
+
+Visit [listToolsets()](/reference/v1/tools/mcp-client#listtoolsets) for more information.
+
+:::
 
 ## Connecting to an MCP registry
 

package/.docs/raw/mcp/publishing-mcp-server.mdx

@@ -1,6 +1,9 @@
 ---
 title: "Publishing an MCP Server | MCP"
 description: Guide to setting up and building a Mastra MCP server using the stdio transport, and publishing it to NPM.
+packages:
+  - "@mastra/core"
+  - "@mastra/mcp"
 ---
 
 import Steps from "@site/src/components/Steps";
@@ -32,7 +35,7 @@ Create a file for your stdio server, for example, `/src/mastra/stdio.ts`.
 
 Add the following code to the file. Remember to import your actual Mastra tools and name the server appropriately.
 
-```typescript title="src/mastra/stdio.ts" copy
+```typescript title="src/mastra/stdio.ts"
 #!/usr/bin/env node
 import { MCPServer } from "@mastra/mcp";
 import { weatherTool } from "./tools";
@@ -55,7 +58,7 @@ server.startStdio().catch((error) => {
 
 Update your `package.json` to include the `bin` entry pointing to your built server file and a script to build the server with both ESM and CJS outputs.
 
-```json title="package.json" copy
+```json title="package.json"
 {
   "bin": "dist/stdio.mjs",
   "scripts": {
@@ -132,8 +135,8 @@ const mcp = new MCPClient({
 });
 
 // You can then get tools or toolsets from this configuration to use in your agent
-const tools = await mcp.getTools();
-const toolsets = await mcp.getToolsets();
+const tools = await mcp.listTools();
+const toolsets = await mcp.listToolsets();
 ```
 
 Note: If you published without an organization scope, the `args` might just be `["-y", "your-package-name@latest"]`.

package/.docs/raw/memory/memory-processors.mdx

@@ -1,13 +1,19 @@
 ---
 title: "Memory Processors | Memory"
 description: "Learn how to use memory processors in Mastra to filter, trim, and transform messages before they're sent to the language model to manage context window limits."
+packages:
+  - "@mastra/core"
+  - "@mastra/libsql"
+  - "@mastra/memory"
+  - "@mastra/openai"
+  - "@mastra/pinecone"
 ---
 
 # 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 conversation history, working memory, and semantically relevant messages, then persist new messages after the model responds.
+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](/docs/v1/agents/processors) that operate specifically on memory-related messages and state.
 
@@ -17,7 +23,7 @@ Mastra automatically adds these processors when memory is enabled:
 
 ### MessageHistory
 
-Retrieves conversation history and persists new messages.
+Retrieves message history and persists new messages.
 
 **When you configure:**
 
@@ -40,7 +46,7 @@ memory: new Memory({
 
 **Example:**
 
-```typescript copy showLineNumbers
+```typescript
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
 import { LibSQLStore } from "@mastra/libsql";
@@ -89,7 +95,7 @@ memory: new Memory({
 
 **Example:**
 
-```typescript copy showLineNumbers
+```typescript
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
 import { LibSQLStore } from "@mastra/libsql";
@@ -109,7 +115,6 @@ const agent = new Agent({
     vector: new PineconeVector({
       id: "memory-vector",
       apiKey: process.env.PINECONE_API_KEY!,
-      environment: "us-east-1",
     }),
     embedder: new OpenAIEmbedder({
       model: "text-embedding-3-small",
@@ -145,7 +150,7 @@ memory: new Memory({
 
 **Example:**
 
-```typescript copy showLineNumbers
+```typescript
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
 import { LibSQLStore } from "@mastra/libsql";
@@ -169,10 +174,10 @@ const agent = new Agent({
 
 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 copy showLineNumbers
+```typescript
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
-import { MessageHistory } from "@mastra/memory/processors";
+import { MessageHistory } from "@mastra/core/processors";
 import { TokenLimiter } from "@mastra/core/processors";
 import { LibSQLStore } from "@mastra/libsql";
 import { openai } from "@ai-sdk/openai";
@@ -211,7 +216,7 @@ Understanding the execution order is important when combining guardrails with me
 1. **Memory processors run FIRST**: `WorkingMemory`, `MessageHistory`, `SemanticRecall`
 2. **Your input processors run AFTER**: guardrails, filters, validators
 
-This means memory loads conversation history before your processors can validate or filter the input.
+This means memory loads message history before your processors can validate or filter the input.
 
 ### Output Processors
 
@@ -236,7 +241,7 @@ Output guardrails run **before** memory processors save messages. If a guardrail
 - Memory processors are skipped
 - **No messages are persisted to storage**
 
-```typescript copy showLineNumbers
+```typescript
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
 import { openai } from "@ai-sdk/openai";
@@ -267,7 +272,7 @@ const agent = new Agent({
 // If the guardrail aborts, nothing is saved to memory
 const result = await agent.generate("Hello");
 if (result.tripwire) {
-  console.log("Blocked:", result.tripwireReason);
+  console.log("Blocked:", result.tripwire.reason);
   // Memory is empty - no messages were persisted
 }
 ```
@@ -281,7 +286,7 @@ Input guardrails run **after** memory processors load history. If a guardrail ab
 - Output processors (including memory persistence) are skipped
 - **No messages are persisted to storage**
 
-```typescript copy showLineNumbers
+```typescript
 // Input guardrail that validates user input
 const inputValidator = {
   id: "input-validator",

package/.docs/raw/memory/message-history.mdx

@@ -0,0 +1,72 @@
+---
+title: "Message History | Memory"
+description: "Learn how to configure message history in Mastra to store recent messages from the current conversation."
+packages:
+  - "@mastra/ai-sdk"
+---
+
+# Message History
+
+Message history is the simplest kind of memory. It is a list of messages from the current conversation.
+
+Once enabled, each request includes the last 10 messages from the current memory thread, giving the agent short-term conversational context. This limit can be increased using the `lastMessages` parameter:
+
+```typescript
+export const agent = new Agent({
+  id: "test-agent",
+  memory: new Memory({
+    options: {
+      lastMessages: 20,
+    },
+  }),
+});
+```
+
+## Querying Messages
+
+Messages are stored in the `MastraDBMessage` format, which provides a consistent structure across the entire Mastra system.
+
+Storage in Mastra uses domain-specific stores. To access message operations, first get the memory store:
+
+```typescript
+// Get the memory store from storage
+const storage = mastra.getStorage();
+const memoryStore = await storage.getStore('memory');
+
+// Get messages for a thread with pagination
+const result = await memoryStore?.listMessages({
+  threadId: "your-thread-id",
+  page: 0,
+  perPage: 50
+});
+
+console.log(result?.messages); // MastraDBMessage[]
+console.log(result?.total); // Total count
+console.log(result?.hasMore); // Whether more pages exist
+
+// Get messages from multiple threads at once
+const multiThreadResult = await memoryStore?.listMessages({
+  threadId: ["thread-1", "thread-2", "thread-3"],
+  page: 0,
+  perPage: 100
+});
+
+// Get messages by their IDs
+const messages = await memoryStore?.listMessagesById({ messageIds: messageIdArr });
+```
+
+The `threadId` parameter accepts either a single thread ID string or an array of thread IDs to query messages from multiple threads in a single request.
+
+All message queries return `MastraDBMessage[]` format. If you need to convert messages to AI SDK formats for UI rendering, use the conversion utilities from `@mastra/ai-sdk/ui`:
+
+```typescript
+import { toAISdkV5Messages } from '@mastra/ai-sdk/ui';
+
+const storage = mastra.getStorage();
+const memoryStore = await storage.getStore('memory');
+
+const result = await memoryStore?.listMessages({ threadId: "your-thread-id" });
+
+// Convert to AI SDK v5+ UIMessage format for UI rendering
+const uiMessages = toAISdkV5Messages(result?.messages ?? []);
+```

package/.docs/raw/memory/overview.mdx

@@ -1,32 +1,39 @@
 ---
 title: "Memory overview | Memory"
-description: "Learn how Mastra's memory system works with working memory, conversation history, and semantic recall."
+description: "Learn how Mastra's memory system works with working memory, message history, and semantic recall."
+packages:
+  - "@mastra/core"
+  - "@mastra/libsql"
+  - "@mastra/memory"
 ---
 
-# Memory overview
+# Memory
 
-Memory in Mastra helps agents manage context across conversations by condensing relevant information into the language model's context window.
+Memory gives your agent coherence across interactions and allows it to improve over time by retaining relevant information from past conversations.
 
-Mastra supports three types of memory: working memory, conversation history, and semantic recall. It uses a two-tier scoping system where memory can be isolated per conversation thread (thread-scoped) or shared across all conversations for the same user (resource-scoped).
+Mastra requires a [storage provider](./storage) to persist memory and supports three types:
 
-Mastra's memory system uses [storage providers](#memory-storage-adapters) to persist conversation threads, messages, and working memory across application restarts.
+- [**Message history**](/docs/v1/memory/message-history) captures recent messages from the current conversation, providing short-term continuity and maintaining dialogue flow.
+- [**Working memory**](/docs/v1/memory/working-memory) stores persistent user-specific details such as names, preferences, goals, and other structured data.
+- [**Semantic recall**](/docs/v1/memory/semantic-recall) retrieves older messages from past conversations based on semantic relevance. Matches are retrieved using vector search and can include surrounding context for better comprehension.
+
+You can enable any combination of these memory types. Mastra assembles the relevant memories into the model’s context window. If the total exceeds the model's token limit, use [memory processors](/docs/v1/memory/memory-processors) to trim or filter messages before sending them to the model.
 
 ## Getting started
 
-First install the required dependencies:
+Install Mastra's memory module and the storage adapter for your preferred database (see the storage section below):
 
-```bash copy
-npm install @mastra/core@beta @mastra/memory@beta @mastra/libsql@beta
+```bash 
+npm install @mastra/memory@beta @mastra/libsql@beta
 ```
 
-Then add a storage adapter to the main Mastra instance. Any agent with memory enabled will use this shared storage to store and recall interactions.
+Add the storage adapter to the main Mastra instance:
 
-```typescript {6-8} title="src/mastra/index.ts" showLineNumbers copy
+```typescript title="src/mastra/index.ts"
 import { Mastra } from "@mastra/core";
 import { LibSQLStore } from "@mastra/libsql";
 
 export const mastra = new Mastra({
-  // ...
   storage: new LibSQLStore({
     id: 'mastra-storage',
     url: ":memory:",
@@ -34,88 +41,43 @@ export const mastra = new Mastra({
 });
 ```
 
-Now, enable memory by passing a `Memory` instance to the agent's `memory` parameter:
-
-```typescript {3-5} title="src/mastra/agents/test-agent.ts" showLineNumbers copy
-import { Memory } from "@mastra/memory";
-import { Agent } from "@mastra/core/agent";
-
-export const testAgent = new Agent({
-  id: "test-agent",
-  // ...
-  memory: new Memory(),
-});
-```
-
-That memory instance has options you can configure for working memory, conversation history, and semantic recall.
-
-## Different types of memory
-
-Mastra supports three types of memory: working memory, conversation history, and semantic recall.
-
-[**Working memory**](./working-memory) stores persistent user-specific details such as names, preferences, goals, and other structured data. (Compare this to ChatGPT where you can ask it to tell you about yourself). This is implemented as a block of Markdown text that the agent is able to update over time (or alternately, as a Zod schema)
-
-[**Conversation history**](./conversation-history) captures recent messages from the current conversation, providing short-term continuity and maintaining dialogue flow.
-
-[**Semantic recall**](./semantic-recall) retrieves older messages from past conversations based on semantic relevance. Matches are retrieved using vector search and can include surrounding context for better comprehension.
+Enable memory by passing a `Memory` instance to your agent:
 
-Mastra combines all memory types into a single context window. If the total exceeds the model’s token limit, use [memory processors](./memory-processors) to trim or filter messages before sending them to the model.
-
-## Scoping memory with threads and resources
-
-All memory types are [resource-scoped](./working-memory#resource-scoped-memory-default) by default, meaning they persist across all conversations for the same user or entity. [Thread-scoped](./working-memory#thread-scoped-memory) configuration isolates memory to a single conversation thread.
-
-## Memory Storage Adapters
-
-To persist and recall information between conversations, memory requires a storage adapter.
-
-Supported options include [LibSQL](/docs/v1/memory/storage/memory-with-libsql), [MongoDB](/docs/v1/memory/storage/memory-with-mongodb), [Postgres](/docs/v1/memory/storage/memory-with-pg), and [Upstash](/docs/v1/memory/storage/memory-with-upstash)
-
-We use LibSQL out of the box because it is file-based or in-memory, so it is easy to install and works well with Studio.
-
-## Dedicated storage
-
-Agents can be configured with their own dedicated storage, keeping tasks, conversations, and recalled information separate across agents.
-
-### Adding storage to agents
-
-To assign dedicated storage to an agent, install and import the required dependency and pass a `storage` instance to the `Memory` constructor:
-
-```typescript {3, 9-11} title="src/mastra/agents/test-agent.ts" showLineNumbers copy
+```typescript title="src/mastra/agents/test-agent.ts"
 import { Memory } from "@mastra/memory";
 import { Agent } from "@mastra/core/agent";
-import { LibSQLStore } from "@mastra/libsql";
 
 export const testAgent = new Agent({
   id: "test-agent",
-  // ...
   memory: new Memory({
-    // ...
-    storage: new LibSQLStore({
-      id: 'test-agent-storage',
-      url: "file:agent-memory.db",
-    }),
-    // ...
+    options: {
+      lastMessages: 20,
+    },
   }),
 });
 ```
+When you send a new message, the model can now "see" the previous 20 messages, which gives it better context for the conversation and leads to more coherent, accurate replies.
 
-## Viewing retrieved messages
+This example configures basic [message history](/docs/v1/memory/message-history). You can also enable [working memory](/docs/v1/memory/working-memory) and [semantic recall](/docs/v1/memory/semantic-recall) by passing additional options to `Memory`.
 
-If tracing is enabled in your Mastra deployment and memory is configured either with `lastMessages` and/or `semanticRecall`, the agent’s trace output will show all messages retrieved for context—including both recent conversation history and messages recalled via semantic recall.
+## Storage
 
-This is helpful for debugging, understanding agent decisions, and verifying that the agent is retrieving the right information for each request.
+Before enabling memory, you must first configure a storage adapter. Mastra supports multiple database providers including PostgreSQL, MongoDB, libSQL, and more.
 
-For more details on enabling and configuring tracing, see [Tracing](../observability/tracing/overview).
+Storage can be configured at the instance level (shared across all agents) or at the agent level (dedicated per agent). You can also use different databases for storage and vector operations.
 
-## Local development with LibSQL
+See the [Storage](/docs/v1/memory/storage) documentation for configuration options, supported providers, and examples.
 
-For local development with `LibSQLStore`, you can inspect stored memory using the [SQLite Viewer](https://marketplace.visualstudio.com/items?itemName=qwtel.sqlite-viewer) extension in VS Code.
+## Debugging memory
 
-![SQLite Viewer](/img/memory/memory-sqlite-viewer.jpg)
+When tracing is enabled, you can inspect exactly which messages the agent uses for context in each request. The trace output shows all memory included in the agent's context window - both recent message history and messages recalled via semantic recall.
 
-## Next Steps
+This visibility helps you understand why an agent made specific decisions and verify that memory retrieval is working as expected.
+
+For more details on enabling and configuring tracing, see [Tracing](/docs/v1/observability/tracing/overview).
 
-Now that you understand the core concepts, continue to [semantic recall](./semantic-recall) to learn how to add RAG memory to your Mastra agents.
+## Next Steps
 
-Alternatively you can visit the [configuration reference](/reference/v1/memory/memory-class) for available options.
+- Learn more about [Storage](/docs/v1/memory/storage) providers and configuration options
+- Add [Message History](/docs/v1/memory/message-history), [Working Memory](/docs/v1/memory/working-memory), or [Semantic Recall](/docs/v1/memory/semantic-recall)
+- Visit [Memory configuration reference](/reference/v1/memory/memory-class) for all available options