@mastra/mcp-docs-server 1.0.0-beta.14 → 1.0.0-beta.16

package/.docs/raw/mastra-cloud/observability.mdx

@@ -1,46 +1,40 @@
 ---
-title: "Understanding Tracing and Logs | Mastra Cloud"
+title: "Observability | Mastra Cloud"
 description: Monitoring and debugging tools for Mastra Cloud deployments
 ---
 
-# Understanding Tracing and Logs
+# Observability
 
-Mastra Cloud provides full observability for production applications, giving you insight into how your agents and workflows behave. Observability can be enabled whether your application is deployed to Mastra Cloud, running locally, or hosted on your own infrastructure. Any Mastra project can send traces and logs to the platform regardless of where it's running.
+Cloud provides observability for production applications, giving you insight into how your agents and workflows behave. Observability works whether your application is deployed to Mastra Cloud, running locally, or hosted on your own infrastructure. Any Mastra project can send traces and logs to the platform regardless of where it's running.
 
 For details on configuring observability, see the [Cloud Exporter](/docs/v1/observability/tracing/exporters/cloud) docs.
 
 ## Traces
 
-More detailed traces are available for both agents and workflows by enabling [observability](/docs/v1/observability/tracing/overview) using one of our [supported providers](/docs/v1/observability/tracing/overview#exporters).
+Traces are available for both agents and workflows by enabling [observability](/docs/v1/observability/tracing/overview) using one of the [supported providers](/docs/v1/observability/tracing/overview#exporters).
 
 ### Agents
 
-With observability enabled, you can view detailed outputs from your agents in the **Traces** section in Studio.
+With observability enabled, you can view detailed outputs from your agents in the **Traces** section in [Studio](/docs/v1/mastra-cloud/studio).
 
 ![observability agents](/img/mastra-cloud/mastra-cloud-observability-agents.jpg)
 
-Key features:
-
-Agent traces break a run into clear steps, model calls, tool calls, and intermediate chunks, each with timing, inputs, outputs, and errors. You can drill into any span to inspect prompts, token usage, and results, making it easy to diagnose issues and understand how the agent produced its output.
+Agent traces break a run into clear steps: model calls, tool calls, and intermediate chunks. Each includes timing, inputs, outputs, and errors. Drill into any span to inspect prompts, token usage, and results.
 
 ### Workflows
 
-With observability enabled, you can view detailed outputs from your workflows in the **Traces** section in Studio.
+With observability enabled, you can view detailed outputs from your workflows in the **Traces** section in [Studio](/docs/v1/mastra-cloud/studio).
 
 ![observability workflows](/img/mastra-cloud/mastra-cloud-observability-workflows.jpg)
 
-Key features:
-
-Workflow traces capture each step in the run, including transitions, branching, timing, and any tool calls inside the workflow. You can inspect inputs, outputs, and errors for every step, making it easy to debug long-running or multi-step processes and understand how data flows through the workflow.
+Workflow traces capture each step in the run, including transitions, branching, timing, and any tool calls. Inspect inputs, outputs, and errors for every step to debug long-running or multi-step processes.
 
 ## Logs
 
-You can view detailed logs for debugging and monitoring your application's behavior on the [Logs](/docs/v1/mastra-cloud/dashboard#logs) page of the Dashboard.
+The **Logs** page in the [project dashboard](/docs/v1/mastra-cloud/deployment#project-dashboard) displays detailed information for debugging and monitoring your application's behavior.
 
 ![Dashboard logs](/img/mastra-cloud/mastra-cloud-dashboard-logs.jpg)
 
-Key features:
-
 Each log entry includes its severity level and a detailed message showing agent, workflow, or storage activity.
 
 ## Next steps

package/.docs/raw/mastra-cloud/overview.mdx

@@ -5,57 +5,27 @@ description: Deployment and monitoring service for Mastra applications
 
 # Mastra Cloud
 
-[Mastra Cloud](https://mastra.ai/cloud) is a platform for deploying, managing, monitoring, and debugging Mastra applications. When you [deploy](/docs/v1/mastra-cloud/setting-up) your application, Mastra Cloud exposes your agents, tools, and workflows as REST API endpoints.
+[Mastra Cloud](https://cloud.mastra.ai) is a platform for deploying, managing, and monitoring Mastra applications. [Import your project](/docs/v1/mastra-cloud/setup) to get started.
 
-## Platform features
+## Studio
 
-Deploy and manage your applications with automated builds, organized projects, and no additional configuration.
+Run [Studio](/docs/v1/mastra-cloud/studio) in the cloud and share access with your team via a link. Team members can test agents and workflows, tweak system prompts, and give feedback without running the project locally.
 
-![Platform features](/img/mastra-cloud/mastra-cloud-platform-features.jpg)
+## Deploy
 
-Key features:
+Enable [deployments](/docs/v1/mastra-cloud/deployment) and Mastra Cloud hosts your server for you. Connect your GitHub repository for automatic deployments whenever you push to your configured branch. Mastra Cloud exposes your agents, tools, and workflows as REST API endpoints.
 
-Mastra Cloud supports zero-config deployment, continuous integration with GitHub, and atomic deployments that package agents, tools, and workflows together.
+Once deployed, the project dashboard gives you visibility into:
 
-## Project Dashboard
+- Deployment status and history
+- Build logs and configuration
+- Environment variables and settings
 
-Monitor and debug your applications with detailed output logs, deployment state, and interactive tools.
+## Observability
 
-![Project dashboard](/img/mastra-cloud/mastra-cloud-project-dashboard.jpg)
+[Observability](/docs/v1/mastra-cloud/observability) provides insight into how your agents and workflows behave in production. View detailed traces of agent runs, workflow executions, and logs to debug issues and understand performance.
 
-Key features:
+:::info
+You don’t need to deploy to Mastra Cloud to use Observability. You can send traces to Mastra from any environment
+:::
 
-The Project Dashboard gives you an overview of your application's status and deployments, with access to logs and a Studio for testing agents and workflows.
-
-## Project structure
-
-Use a standard Mastra project structure for proper detection and deployment.
-
-```shell
-src
-└── mastra
-    ├── agents
-    │   └── agent-name.ts
-    ├── tools
-    │   └── tool-name.ts
-    ├── workflows
-    │   └── workflow-name.ts
-    └── index.ts
-package.json
-```
-
-Mastra Cloud scans your repository for:
-
-- **Agents**: Defined using: `new Agent({...})`
-- **Tools**: Defined using: `createTool({...})`
-- **Workflows**: Defined using: `createWorkflow({...})`
-- **Steps**: Defined using: `createStep({...})`
-- **Environment Variables**: API keys and configuration variables
-
-## Technical implementation
-
-Mastra Cloud is purpose-built for Mastra agents, tools, and workflows. It handles long-running requests, records detailed traces for every execution, and includes built-in support for evals.
-
-## Next steps
-
-- [Setting Up and Deploying](/docs/v1/mastra-cloud/setting-up)

package/.docs/raw/mastra-cloud/setup.mdx

@@ -0,0 +1,64 @@
+---
+title: "Setup | Mastra Cloud"
+description: Import your Mastra project to Mastra Cloud
+---
+
+import Steps from "@site/src/components/Steps";
+import StepItem from "@site/src/components/StepItem";
+
+# Setup
+
+Import your Mastra project to [Mastra Cloud](https://cloud.mastra.ai) to use [Studio](/docs/v1/mastra-cloud/studio) and optionally [deploy](/docs/v1/mastra-cloud/deployment) your agent.
+
+## Before you begin
+
+- [Sign in](https://cloud.mastra.ai) to Cloud
+- Push your [Mastra project](/docs/v1/getting-started/start) to GitHub
+
+## Options
+
+
+![Select project type](/img/mastra-cloud/mastra-cloud-select.png)
+
+When you create a new project, you can choose from three options:
+
+1. **Create from GitHub** - Import a Mastra project from GitHub
+2. **Create from your server** - Connect a self-hosted Mastra instance to [Studio](/docs/v1/mastra-cloud/studio)
+3. **Create from template** - Start from a [pre-built template](https://mastra.ai/templates)
+
+
+To create a project from GitHub, follow these steps:
+
+## Create from GitHub
+
+<Steps>
+
+<StepItem>
+Connect to GitHub when prompted
+
+![Deployment details](/img/mastra-cloud/mastra-cloud-connect.png)
+</StepItem>
+
+<StepItem>
+Search for your repository and click **Import**
+
+![Deployment details](/img/mastra-cloud/mastra-cloud-import-git-repository.jpg)
+</StepItem>
+
+<StepItem>
+Configure your project settings. Mastra Cloud auto-detects most settings, but you'll still need to enter the environment variables for your configured [model provider](/models/v1):
+
+![Deployment details](/img/mastra-cloud/mastra-cloud-deployment-details.jpg)
+</StepItem>
+
+<StepItem>
+
+Click **Create Project**
+</StepItem>
+</Steps>
+
+## Next steps
+
+Once your project is imported, [Studio](/docs/v1/mastra-cloud/studio) automatically creates a sandbox where you can interact with your agents and share access with your team.
+
+When you're ready for production, enable [Deployment](/docs/v1/mastra-cloud/deployment) settings and hit deploy!

package/.docs/raw/mastra-cloud/studio.mdx

@@ -0,0 +1,35 @@
+---
+title: "Studio | Mastra Cloud"
+description: Run Studio in the cloud for team collaboration
+---
+
+import YouTube from "@site/src/components/YouTube-player";
+
+# Studio
+
+<YouTube id="ojGu6Bi4wYk" />
+
+Mastra Cloud provides a hosted version of [Studio](/docs/v1/getting-started/studio) that gives your team a shared environment for interacting with and testing your agents. Team members can chat with agents, review traces, give feedback, and tweak system prompts - without needing to run the project locally.
+
+[Set up your project](/docs/v1/mastra-cloud/setup) to access Studio in the cloud.
+
+See the [Studio documentation](/docs/v1/getting-started/studio) for details on features like the Agents playground, Workflows runner, Tools testing, and MCP Servers.
+
+:::note
+You don't need to deploy your agent to use Studio. Studio runs in a sandbox environment separate from your production deployment
+:::
+
+## Sharing access
+
+To invite team members, go to [Mastra Cloud](https://cloud.mastra.ai), click **Team Settings**, then **Members** to add them. Once invited, they can sign in and access your project's Studio.
+
+![Invite team members](/img/mastra-cloud/mastra-cloud-invite.png)
+
+:::warning
+Team members can view environment variables and delete projects. Only invite people you trust.
+:::
+
+## Next steps
+
+- [Deployment](/docs/v1/mastra-cloud/deployment) - Manage deployments and settings
+- [Observability](/docs/v1/mastra-cloud/observability) - Monitor traces and logs

package/.docs/raw/reference/client-js/workflows.mdx

@@ -145,6 +145,21 @@ await run.resume({
 });
 ```
 
+### cancel()
+
+Cancel a running workflow:
+
+```typescript
+const run = await workflow.createRun({ runId: existingRunId });
+
+const result = await run.cancel();
+// Returns: { message: 'Workflow run canceled' }
+```
+
+This method stops any running steps and prevents subsequent steps from executing. Steps that check the `abortSignal` parameter can respond to cancellation by cleaning up resources (timeouts, network requests, etc.).
+
+See the [Run.cancel()](/reference/v1/workflows/run-methods/cancel) reference for detailed information about how cancellation works and how to write steps that respond to cancellation.
+
 ### stream()
 
 Stream workflow execution for real-time updates:

package/.docs/raw/reference/logging/pino-logger.mdx

@@ -7,7 +7,7 @@ description: Documentation for PinoLogger, which provides methods to record even
 
 A Logger instance is created using `new PinoLogger()` and provides methods to record events at various severity levels.
 
-When deploying to Mastra Cloud, logs are displayed on the [Logs](/docs/v1/mastra-cloud/dashboard#logs) page. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
+When deploying to Mastra Cloud, logs are displayed on the [Logs](/docs/v1/mastra-cloud/observability#logs) page. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
 
 ## Usage example
 

package/.docs/raw/reference/processors/token-limiter-processor.mdx

@@ -1,11 +1,14 @@
 ---
 title: "Reference: Token Limiter Processor | Processors"
-description: "Documentation for the TokenLimiterProcessor in Mastra, which limits the number of tokens in AI responses."
+description: "Documentation for the TokenLimiterProcessor in Mastra, which limits the number of tokens in messages."
 ---
 
 # TokenLimiterProcessor
 
-The `TokenLimiterProcessor` is an **output processor** that limits the number of tokens in AI responses. This processor helps control response length by implementing token counting with configurable strategies for handling exceeded limits, including truncation and abortion options for both streaming and non-streaming scenarios.
+The `TokenLimiterProcessor` limits the number of tokens in messages. It can be used as both an input and output processor:
+
+- **Input processor**: Filters historical messages to fit within the context window, prioritizing recent messages
+- **Output processor**: Limits generated response tokens via streaming or non-streaming with configurable strategies for handling exceeded limits
 
 ## Usage example
 
@@ -82,6 +85,12 @@ const processor = new TokenLimiterProcessor({
       description: "Optional processor display name",
       isOptional: true,
     },
+    {
+      name: "processInput",
+      type: "(args: { messages: MastraDBMessage[]; abort: (reason?: string) => never }) => Promise<MastraDBMessage[]>",
+      description: "Filters input messages to fit within token limit, prioritizing recent messages while preserving system messages",
+      isOptional: false,
+    },
     {
       name: "processOutputStream",
       type: "(args: { part: ChunkType; streamParts: ChunkType[]; state: Record<string, any>; abort: (reason?: string) => never }) => Promise<ChunkType | null>",
@@ -90,22 +99,10 @@ const processor = new TokenLimiterProcessor({
     },
     {
       name: "processOutputResult",
-      type: "(args: { messages: MastraMessageV2[]; abort: (reason?: string) => never }) => Promise<MastraMessageV2[]>",
+      type: "(args: { messages: MastraDBMessage[]; abort: (reason?: string) => never }) => Promise<MastraDBMessage[]>",
       description: "Processes final output results to limit token count in non-streaming scenarios",
       isOptional: false,
     },
-    {
-      name: "reset",
-      type: "() => void",
-      description: "Reset the token counter (useful for testing or reusing the processor)",
-      isOptional: false,
-    },
-    {
-      name: "getCurrentTokens",
-      type: "() => number",
-      description: "Get the current token count",
-      isOptional: false,
-    },
     {
       name: "getMaxTokens",
       type: "() => number",
@@ -117,14 +114,38 @@ const processor = new TokenLimiterProcessor({
 
 ## Extended usage example
 
-```typescript title="src/mastra/agents/limited-agent.ts"
+### As an input processor (limit context window)
+
+Use `inputProcessors` to limit historical messages sent to the model, which helps stay within context window limits:
+
+```typescript title="src/mastra/agents/context-limited-agent.ts"
+import { Agent } from "@mastra/core/agent";
+import { Memory } from "@mastra/memory";
+import { TokenLimiterProcessor } from "@mastra/core/processors";
+
+export const agent = new Agent({
+  name: "context-limited-agent",
+  instructions: "You are a helpful assistant",
+  model: "openai/gpt-4o",
+  memory: new Memory({ /* ... */ }),
+  inputProcessors: [
+    new TokenLimiterProcessor({ limit: 4000 }) // Limits historical messages to ~4000 tokens
+  ]
+});
+```
+
+### As an output processor (limit response length)
+
+Use `outputProcessors` to limit the length of generated responses:
+
+```typescript title="src/mastra/agents/response-limited-agent.ts"
 import { Agent } from "@mastra/core/agent";
 import { TokenLimiterProcessor } from "@mastra/core/processors";
 
 export const agent = new Agent({
-  name: "limited-agent",
+  name: "response-limited-agent",
   instructions: "You are a helpful assistant",
-  model: "openai/gpt-5.1",
+  model: "openai/gpt-4o",
   outputProcessors: [
     new TokenLimiterProcessor({
       limit: 1000,

package/.docs/raw/reference/storage/cloudflare-d1.mdx

@@ -118,14 +118,16 @@ If you're using storage directly without Mastra, you must call `init()` explicit
 import { D1Store } from "@mastra/cloudflare-d1";
 
 const storage = new D1Store({
+  id: 'd1-storage',
   binding: D1Database,
 });
 
 // Required when using storage directly
 await storage.init();
 
-// Now you can use the storage
-await storage.getThread({ threadId: "..." });
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore('memory');
+const thread = await memoryStore?.getThreadById({ threadId: "..." });
 ```
 
 :::warning

package/.docs/raw/reference/storage/composite.mdx

@@ -0,0 +1,223 @@
+---
+title: "Reference: Storage Composition | Storage"
+description: Documentation for combining multiple storage backends in Mastra.
+---
+
+# Storage Composition
+
+MastraStorage can compose storage domains from different adapters. Use it when you need different databases for different purposes. For example, use LibSQL for memory and PostgreSQL for workflows.
+
+## Installation
+
+MastraStorage is included in `@mastra/core`:
+
+```bash
+npm install @mastra/core@beta
+```
+
+You'll also need to install the storage adapters you want to compose:
+
+```bash
+npm install @mastra/pg@beta @mastra/libsql@beta
+```
+
+## Usage
+
+### Basic composition
+
+Import domain classes directly from each store package and compose them:
+
+```typescript
+import { MastraStorage } from "@mastra/core/storage";
+import { MemoryPG, WorkflowsPG, ScoresPG } from "@mastra/pg";
+import { MemoryLibSQL } from "@mastra/libsql";
+import { Mastra } from "@mastra/core";
+
+const mastra = new Mastra({
+  storage: new MastraStorage({
+    id: "composite",
+    domains: {
+      memory: new MemoryLibSQL({ url: "file:./local.db" }),
+      workflows: new WorkflowsPG({ connectionString: process.env.DATABASE_URL }),
+      scores: new ScoresPG({ connectionString: process.env.DATABASE_URL }),
+    },
+  }),
+});
+```
+
+### With a default storage
+
+Use `default` to specify a fallback storage, then override specific domains:
+
+```typescript
+import { MastraStorage } from "@mastra/core/storage";
+import { PostgresStore } from "@mastra/pg";
+import { MemoryLibSQL } from "@mastra/libsql";
+import { Mastra } from "@mastra/core";
+
+const pgStore = new PostgresStore({
+  id: "pg",
+  connectionString: process.env.DATABASE_URL,
+});
+
+const mastra = new Mastra({
+  storage: new MastraStorage({
+    id: "composite",
+    default: pgStore,
+    domains: {
+      memory: new MemoryLibSQL({ url: "file:./local.db" }),
+    },
+  }),
+});
+```
+
+## Options
+
+<PropertiesTable
+  content={[
+    {
+      name: "id",
+      type: "string",
+      description: "Unique identifier for this storage instance.",
+      isOptional: false,
+    },
+    {
+      name: "default",
+      type: "MastraStorage",
+      description:
+        "Default storage adapter. Domains not explicitly specified in `domains` will use this storage's domains as fallbacks.",
+      isOptional: true,
+    },
+    {
+      name: "domains",
+      type: "object",
+      description:
+        "Individual domain overrides. Each domain can come from a different storage adapter. These take precedence over the default storage.",
+      isOptional: true,
+    },
+    {
+      name: "domains.memory",
+      type: "MemoryStorage",
+      description: "Storage for threads, messages, and resources.",
+      isOptional: true,
+    },
+    {
+      name: "domains.workflows",
+      type: "WorkflowsStorage",
+      description: "Storage for workflow snapshots.",
+      isOptional: true,
+    },
+    {
+      name: "domains.scores",
+      type: "ScoresStorage",
+      description: "Storage for evaluation scores.",
+      isOptional: true,
+    },
+    {
+      name: "domains.observability",
+      type: "ObservabilityStorage",
+      description: "Storage for traces and spans.",
+      isOptional: true,
+    },
+    {
+      name: "domains.agents",
+      type: "AgentsStorage",
+      description: "Storage for stored agent configurations.",
+      isOptional: true,
+    },
+    {
+      name: "disableInit",
+      type: "boolean",
+      description:
+        "When true, automatic initialization is disabled. You must call init() explicitly.",
+      isOptional: true,
+    },
+  ]}
+/>
+
+## Initialization
+
+MastraStorage initializes each configured domain independently. When passed to the Mastra class, `init()` is called automatically:
+
+```typescript
+import { MastraStorage } from "@mastra/core/storage";
+import { MemoryPG, WorkflowsPG, ScoresPG } from "@mastra/pg";
+import { Mastra } from "@mastra/core";
+
+const storage = new MastraStorage({
+  id: "composite",
+  domains: {
+    memory: new MemoryPG({ connectionString: process.env.DATABASE_URL }),
+    workflows: new WorkflowsPG({ connectionString: process.env.DATABASE_URL }),
+    scores: new ScoresPG({ connectionString: process.env.DATABASE_URL }),
+  },
+});
+
+const mastra = new Mastra({
+  storage, // init() called automatically
+});
+```
+
+If using storage directly, call `init()` explicitly:
+
+```typescript
+const storage = new MastraStorage({
+  id: "composite",
+  domains: {
+    memory: new MemoryPG({ connectionString: process.env.DATABASE_URL }),
+  },
+});
+
+await storage.init();
+
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore("memory");
+const thread = await memoryStore?.getThreadById({ threadId: "..." });
+```
+
+## Use Cases
+
+### Separate databases for different workloads
+
+Use a local database for development while keeping production data in a managed service:
+
+```typescript
+import { MastraStorage } from "@mastra/core/storage";
+import { MemoryPG, WorkflowsPG, ScoresPG } from "@mastra/pg";
+import { MemoryLibSQL } from "@mastra/libsql";
+
+const storage = new MastraStorage({
+  id: "composite",
+  domains: {
+    // Use local SQLite for development, PostgreSQL for production
+    memory:
+      process.env.NODE_ENV === "development"
+        ? new MemoryLibSQL({ url: "file:./dev.db" })
+        : new MemoryPG({ connectionString: process.env.DATABASE_URL }),
+    workflows: new WorkflowsPG({ connectionString: process.env.DATABASE_URL }),
+    scores: new ScoresPG({ connectionString: process.env.DATABASE_URL }),
+  },
+});
+```
+
+### Specialized storage for observability
+
+Use a time-series database for traces while keeping other data in PostgreSQL:
+
+```typescript
+import { MastraStorage } from "@mastra/core/storage";
+import { MemoryPG, WorkflowsPG, ScoresPG } from "@mastra/pg";
+import { ObservabilityStorageClickhouse } from "@mastra/clickhouse";
+
+const storage = new MastraStorage({
+  id: "composite",
+  domains: {
+    memory: new MemoryPG({ connectionString: process.env.DATABASE_URL }),
+    workflows: new WorkflowsPG({ connectionString: process.env.DATABASE_URL }),
+    scores: new ScoresPG({ connectionString: process.env.DATABASE_URL }),
+    observability: new ObservabilityStorageClickhouse({
+      url: process.env.CLICKHOUSE_URL,
+    }),
+  },
+});
+```

package/.docs/raw/reference/storage/lance.mdx

@@ -98,8 +98,9 @@ const storage = await LanceStorage.create("my-storage", "/path/to/db");
 // Required when using storage directly
 await storage.init();
 
-// Now you can use the storage
-await storage.getThread({ threadId: "..." });
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore('memory');
+const thread = await memoryStore?.getThreadById({ threadId: "..." });
 ```
 
 :::warning

package/.docs/raw/reference/storage/libsql.mdx

@@ -115,7 +115,7 @@ const mastra = new Mastra({
 
 If using storage directly without Mastra, call `init()` explicitly:
 
-```typescript 
+```typescript
 import { LibSQLStore } from "@mastra/libsql";
 
 const storage = new LibSQLStore({
@@ -124,5 +124,8 @@ const storage = new LibSQLStore({
 });
 
 await storage.init();
-await storage.getThread({ threadId: "..." });
+
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore('memory');
+const thread = await memoryStore?.getThreadById({ threadId: "..." });
 ```

package/.docs/raw/reference/storage/mongodb.mdx

@@ -117,6 +117,7 @@ If you're using storage directly without Mastra, you must call `init()` explicit
 import { MongoDBStore } from "@mastra/mongodb";
 
 const storage = new MongoDBStore({
+  id: 'mongodb-storage',
   url: process.env.MONGODB_URL,
   dbName: process.env.MONGODB_DATABASE,
 });
@@ -124,8 +125,9 @@ const storage = new MongoDBStore({
 // Required when using storage directly
 await storage.init();
 
-// Now you can use the storage
-await storage.getThread({ threadId: "..." });
+// Access domain-specific stores via getStore()
+const memoryStore = await storage.getStore('memory');
+const thread = await memoryStore?.getThreadById({ threadId: "..." });
 ```
 
 :::warning