@mastra/mcp-docs-server 0.0.0-studio-deploy-20260404182525 → 0.0.0-studio-cli-20260504022012

package/.docs/docs/evals/custom-scorers.md

@@ -270,6 +270,66 @@ const glutenCheckerScorer = createScorer({...})
 })
 ```
 
+## Input filtering
+
+Agent conversations can contain hundreds of messages with tool calls, data parts, and system metadata. Most scorers only need a subset of this data. The `prepareRun` option transforms the run data before the scorer pipeline executes, reducing noise and keeping scorers focused.
+
+### Declarative filtering with `filterRun()`
+
+The [`filterRun()`](https://mastra.ai/reference/evals/filter-run) utility creates a `prepareRun` function from declarative options:
+
+```typescript
+import { createScorer, filterRun } from '@mastra/core/evals'
+
+const toolScorer = createScorer({
+  id: 'tool-quality',
+  description: 'Evaluates tool usage quality',
+  type: 'agent',
+  prepareRun: filterRun({
+    partTypes: ['tool-invocation', 'text'],
+    maxRememberedMessages: 20,
+  }),
+}).generateScore(({ run }) => {
+  // run.input.rememberedMessages has only tool and text messages, max 20
+  return 1
+})
+```
+
+Common options include:
+
+- `partTypes`: Keep only messages with matching part types (e.g., `'tool-invocation'`, `'text'`, `'reasoning'`)
+- `toolNames`: Keep only messages involving specific tools (e.g., `['write_file', 'execute_command']`)
+- `maxRememberedMessages`: Limit context window size
+- `dropRequestContext`, `dropGroundTruth`, `dropExpectedTrajectory`: Remove unused fields
+
+See the [`filterRun()` reference](https://mastra.ai/reference/evals/filter-run) for the full list of options.
+
+### Custom `prepareRun` functions
+
+For logic that `filterRun()` doesn't cover, write a `prepareRun` function directly:
+
+```typescript
+import { createScorer } from '@mastra/core/evals'
+
+const customScorer = createScorer({
+  id: 'recent-output',
+  description: 'Scores only the last response',
+  type: 'agent',
+  prepareRun: (run) => ({
+    ...run,
+    output: run.output.slice(-1), // Keep only the last message
+    requestContext: undefined,
+  }),
+})
+.generateScore(({ run }) => {
+  return run.output.length > 0 ? 1 : 0
+})
+```
+
+The `prepareRun` function can also be async.
+
+> **System messages are always preserved:** `filterRun()` never filters `systemMessages` or `taggedSystemMessages`. These contain agent instructions and are critical context for scoring.
+
 ## Example: Create a custom scorer
 
 A custom scorer in Mastra uses `createScorer` with four core components:
@@ -402,7 +462,7 @@ Defines how the LLM should analyze the input and what structured output to retur
 The analysis step uses a prompt object to:
 
 - Provide a clear description of the analysis task
-- Define expected output structure with Zod schema (both boolean result and list of gluten sources)
+- Define expected output structure with a Standard JSON Schema (both boolean result and list of gluten sources)
 - Generate dynamic prompts based on the input content
 
 ### Score Generation
@@ -515,5 +575,5 @@ console.log('Reason:', result.reason)
 
 **Examples and Resources:**
 
-- [createScorer API Reference](https://mastra.ai/reference/evals/create-scorer) - Complete technical documentation
-- [Built-in Scorers Source Code](https://github.com/mastra-ai/mastra/tree/main/packages/evals/src/scorers) - Real implementations for reference
+- [createScorer API Reference](https://mastra.ai/reference/evals/create-scorer): Complete technical documentation
+- [Built-in Scorers Source Code](https://github.com/mastra-ai/mastra/tree/main/packages/evals/src/scorers): Real implementations for reference

package/.docs/docs/evals/datasets/overview.md

@@ -68,7 +68,7 @@ console.log(dataset.id) // auto-generated UUID
 
 ### Defining schemas
 
-You can enforce the shape of `input` and `groundTruth` by passing Zod schemas. Mastra converts them to JSON Schema at creation time:
+You can enforce the shape of `input` and `groundTruth` by passing a [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.) when creating the dataset:
 
 ```typescript
 import { z } from 'zod'

package/.docs/docs/index.md

@@ -4,7 +4,7 @@ Build AI agents your users actually depend on. Mastra is a TypeScript framework
 
 ## Quickstart
 
-Run this command to create a new project you can test immediately in [Studio](https://mastra.ai/docs/studio/overview):
+Run this command to create a new project:
 
 **npm**:
 
@@ -30,7 +30,7 @@ yarn create mastra
 bunx create-mastra
 ```
 
-See the [quickstart guide](https://mastra.ai/guides/getting-started/quickstart) for a full walkthrough.
+You can open [Studio](https://mastra.ai/docs/studio/overview) immediately, which is an interactive UI for your Mastra project. See the [quickstart guide](https://mastra.ai/guides/getting-started/quickstart) for a full walkthrough.
 
 ## Integrate with your framework
 

package/.docs/docs/mastra-platform/configuration.md

@@ -0,0 +1,36 @@
+# Configuration
+
+When you deploy to the Mastra platform, the CLI generates a `.mastra-project.json` config file and reads environment variables from your local `.env` files.
+
+This page explains both mechanisms and how they differ between Studio and Server deployments.
+
+## Project config
+
+The `.mastra-project.json` file is auto-generated on your first Studio or Server deploy. It links your local project to a platform project.
+
+Commit it to your version control so that subsequent deploys (including from CI) target the correct project.
+
+Your file will look something like this:
+
+```json
+{
+  "projectId": "06daaac4-89b1-40f0-9e3f-0993e039a627",
+  "projectName": "my-project",
+  "organizationId": "org_01KNA5YSP52SX4M6YVSXC2MAHP"
+}
+```
+
+| Field          | Description                                                                                          |
+| -------------- | ---------------------------------------------------------------------------------------------------- |
+| projectId      | UUID for the project. Assigned when the project is created.                                          |
+| projectName    | Human-readable project name. Used as a display label in the dashboard and CLI output.                |
+| organizationId | The organization that owns the project. All deploys, API keys, and resources are scoped to this org. |
+
+## Environment variables
+
+The CLI reads from `.env` and `.env.local` files in your project directory during deploy. Variables from `.env.local` override those in `.env`.
+
+You can set environment variables like so:
+
+- **Studio**: Environment variables are read from your local `.env` files and bundled into the deploy artifact. To update them, redeploy.
+- **Server**: On the first deploy, the CLI automatically seeds environment variables from your local `.env` files. After that, manage them per-project through the dashboard or API.

package/.docs/docs/mastra-platform/overview.md

@@ -0,0 +1,78 @@
+# Mastra platform
+
+The [Mastra platform](https://projects.mastra.ai) provides two products for deploying and managing AI applications built with the Mastra framework:
+
+- **Studio**: A hosted visual environment for testing agents, running workflows, and inspecting traces
+- **Server**: A production deployment target that runs your Mastra application as an API server
+
+## Quickstart
+
+Before you begin, ensure you have Node.js 22.13.0 or later installed.
+
+1. Follow the [get started guide](https://mastra.ai/docs) to create your first Mastra project.
+
+2. Install the `mastra` CLI globally:
+
+   **npm**:
+
+   ```bash
+   npm install -g mastra
+   ```
+
+   **pnpm**:
+
+   ```bash
+   pnpm add -g mastra
+   ```
+
+   **Yarn**:
+
+   ```bash
+   yarn global add mastra
+   ```
+
+   **Bun**:
+
+   ```bash
+   bun add --global mastra
+   ```
+
+3. Deploy Studio with a single command:
+
+   ```bash
+   mastra studio deploy
+   ```
+
+   On a successful deploy, the CLI will output the URL of your deployed Studio instance.
+
+4. Deploy Server with a single command:
+
+   ```bash
+   mastra server deploy
+   ```
+
+   On a successful deploy, the CLI will output the URL of your deployed Server instance.
+
+You have now successfully deployed both Studio and Server instances of your Mastra application. The CLI created a `.mastra-project.json` file in your project directory.
+
+This file links your local project to a platform project. It's auto-generated on your first deploy and contains the `projectId`, `projectName`, and `organizationId`. Commit this file to your repository so CI/CD knows which project to deploy to.
+
+## Key Concepts
+
+**Projects** are the shared parent entity across all products. A single project can have a Studio deployment and a Server deployment. Projects belong to an **Organization**, which is the multi-tenant container for your team.
+
+Your Mastra application is built from three building blocks:
+
+- [Agents](https://mastra.ai/docs/agents/overview): AI agents that can use tools, follow instructions, and maintain context
+- [Tools](https://mastra.ai/docs/agents/using-tools): Callable functions and integrations available to your agents
+- [Workflows](https://mastra.ai/docs/workflows/overview): Multi-step orchestration pipelines that coordinate agents and tools
+
+## Going to production
+
+Develop your project locally with [`mastra dev`](https://mastra.ai/reference/cli/mastra) and open [Studio](https://mastra.ai/docs/studio/overview) to test your agents, workflows, and tools in a visual environment.
+
+Once you're ready to deploy your application to production, use [`mastra studio deploy`](https://mastra.ai/reference/cli/mastra) and [`mastra server deploy`](https://mastra.ai/reference/cli/mastra) to push your application to the cloud.
+
+Follow the [Studio deployment guide](https://mastra.ai/docs/studio/deployment) and [Server deployment guide](https://mastra.ai/guides/deployment/mastra-platform) for step-by-step instructions.
+
+If you host your Mastra application on your own infrastructure, you can still send observability data to Studio using the [CloudExporter](https://mastra.ai/docs/observability/tracing/exporters/cloud).

package/.docs/docs/mcp/overview.md

@@ -89,6 +89,23 @@ export const testAgent = new Agent({
 
 > **Info:** Visit [Agent Class](https://mastra.ai/reference/agents/agent) for a full list of configuration options.
 
+## Tool approval
+
+You can require human approval before MCP tools are executed by setting `requireToolApproval` on a server definition. This integrates with the existing [human-in-the-loop](https://mastra.ai/docs/workflows/human-in-the-loop) approval flow.
+
+```typescript
+export const mcp = new MCPClient({
+  servers: {
+    github: {
+      url: new URL('http://localhost:3000/mcp'),
+      requireToolApproval: true,
+    },
+  },
+})
+```
+
+You can also pass a function to decide dynamically per-call. See the [MCPClient reference](https://mastra.ai/reference/tools/mcp-client) for the full API.
+
 ## 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.

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

@@ -307,8 +307,8 @@ Both scenarios are safe - guardrails prevent inappropriate content from being pe
 
 ## 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
+- [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

@@ -6,6 +6,12 @@ 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.
 
+> **Warning:** When you use memory with a client application, send **only the new message** from the client instead of the full conversation history.
+>
+> Sending the full history is redundant because Mastra loads messages from storage, and it can cause message ordering bugs when client-side timestamps conflict with stored timestamps.
+>
+> For an AI SDK example, see [Using Mastra Memory](https://mastra.ai/guides/build-your-ui/ai-sdk-ui).
+
 ## 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.
@@ -100,8 +106,8 @@ await agent.stream('Hello', {
 
 You can use this history in two ways:
 
-- **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.
+- **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.
 
 > **Tip:** When memory is enabled, [Studio](https://mastra.ai/docs/studio/overview) uses message history to display past conversations in the chat sidebar.
 

package/.docs/docs/memory/observational-memory.md

@@ -38,8 +38,45 @@ const memory = new Memory({
 
 See [configuration options](https://mastra.ai/reference/memory/observational-memory) for full API details.
 
+> **Warning:** When you use OM with a client application, send **only the new message** from the client instead of the full conversation history.
+>
+> Observational memory still relies on stored conversation history. Sending the full history is redundant and can cause message ordering bugs when client-side timestamps conflict with stored timestamps.
+>
+> For an AI SDK example, see [Using Mastra Memory](https://mastra.ai/guides/build-your-ui/ai-sdk-ui).
+
 > **Note:** OM currently only supports `@mastra/pg`, `@mastra/libsql`, and `@mastra/mongodb` storage adapters. It uses background agents for managing memory. When using `observationalMemory: true`, the default model is `google/gemini-2.5-flash`. When passing a config object, a `model` must be explicitly set.
 
+## Temporal gap markers
+
+Temporal gap markers insert a short reminder before a new user message when enough time has passed since the previous message in the thread. They help the agent and the UI see that the conversation resumed after a meaningful pause.
+
+Temporal gap markers are off by default. Enable them with `temporalMarkers: true` in the `observationalMemory` config:
+
+```typescript
+import { Memory } from '@mastra/memory'
+import { Agent } from '@mastra/core/agent'
+
+export const agent = new Agent({
+  name: 'my-agent',
+  instructions: 'You are a helpful assistant.',
+  model: 'openai/gpt-5-mini',
+  memory: new Memory({
+    options: {
+      observationalMemory: {
+        model: 'google/gemini-2.5-flash',
+        temporalMarkers: true,
+      },
+    },
+  }),
+})
+```
+
+Mastra inserts a temporal gap marker when the gap is at least 10 minutes. The marker is stored in memory and also emitted as a transient reminder event, so clients can render it as a lightweight timeline hint.
+
+The observer also sees these markers when it processes the thread, so the observations it writes can anchor memories to when they happened (for example, "User asked about deployment after a 2-day gap").
+
+See [the API reference](https://mastra.ai/reference/memory/observational-memory) for the full configuration shape.
+
 ## Benefits
 
 - **Prompt caching**: OM's context is stable and observations append over time rather than being dynamically retrieved each turn. This keeps the prompt prefix cacheable, which reduces costs.
@@ -157,7 +194,7 @@ With retrieval mode enabled, OM:
 - Registers a `recall` tool the agent can call to:
 
   - Page through the raw messages behind any observation group range
-  - Search by semantic similarity (`mode: "search"` with a `query` string) — requires `vector: true`
+  - Search by semantic similarity (`mode: "search"` with a `query` string); requires `vector: true`
   - List all threads (`mode: "threads"`), browse other threads (`threadId`), and search across all threads (default `scope: 'resource'`)
   - When `scope: 'thread'`: restrict browsing and search to the current thread only
 
@@ -327,13 +364,33 @@ Reflection works similarly — the Reflector runs in the background when observa
 
 ### Settings
 
-| Setting                        | Default | What it controls                                                                                                                                                                      |
-| ------------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `observation.bufferTokens`     | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens` — with the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).    |
-| `observation.bufferActivation` | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history. |
-| `observation.blockAfter`       | `1.2`   | Safety threshold as a multiplier of `messageTokens`. At `1.2`, synchronous observation is forced at 36k tokens (1.2 × 30k). Only matters if buffering can't keep up.                  |
-| `reflection.bufferActivation`  | `0.5`   | When to start background reflection. `0.5` means reflection begins when observations reach 50% of the `observationTokens` threshold.                                                  |
-| `reflection.blockAfter`        | `1.2`   | Safety threshold for reflection, same logic as observation.                                                                                                                           |
+| Setting                        | Default | What it controls                                                                                                                                                                                                                                                                                                                       |
+| ------------------------------ | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `observation.bufferTokens`     | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens` — with the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).                                                                                                                                                     |
+| `observation.bufferActivation` | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history.                                                                                                                                                  |
+| `observation.blockAfter`       | `1.2`   | Safety threshold as a multiplier of `messageTokens`. At `1.2`, synchronous observation is forced at 36k tokens (1.2 × 30k). Only matters if buffering can't keep up.                                                                                                                                                                   |
+| `activateAfterIdle`            | none    | Forces buffered observations and buffered reflections to activate after a period of inactivity, even if their token thresholds have not been reached yet. Accepts milliseconds or duration strings like `300_000`, `"5m"`, or `"1hr"`. Set this to your prompt cache TTL if you want activation to happen before the next cold prompt. |
+| `activateOnProviderChange`     | `false` | Forces buffered observations and reflections to activate when the next step uses a different `provider/model` than the one that produced the latest assistant step. Use this when switching providers or models would invalidate prompt cache reuse.                                                                                   |
+| `reflection.bufferActivation`  | `0.5`   | When to start background reflection. `0.5` means reflection begins when observations reach 50% of the `observationTokens` threshold.                                                                                                                                                                                                   |
+| `reflection.blockAfter`        | `1.2`   | Safety threshold for reflection, same logic as observation.                                                                                                                                                                                                                                                                            |
+
+If you're relying on prompt caching, set `activateAfterIdle` to match your cache TTL. That way, once a thread has been idle long enough for the cache to expire, the next request can activate buffered observations or reflections first and send a smaller compressed context window.
+
+```typescript
+const memory = new Memory({
+  options: {
+    observationalMemory: {
+      model: 'google/gemini-2.5-flash',
+      activateAfterIdle: '5m',
+      activateOnProviderChange: true,
+    },
+  },
+})
+```
+
+With a 5-minute prompt cache TTL, this activates buffered context after 5 minutes of inactivity so the next uncached prompt uses observations and reflections instead of a larger raw message window. If you prefer, `300_000` works the same way.
+
+Changing model or providers mid-thread will invalidate the prompt cache. If your agent can switch between providers or models mid-thread, `activateOnProviderChange: true` forces buffered context to activate before the new provider runs. That avoids sending a large raw window to a provider that cannot reuse the previous prompt cache.
 
 ### Disabling
 

package/.docs/docs/memory/storage.md

@@ -34,6 +34,7 @@ Each provider page includes installation instructions, configuration parameters,
 - [PostgreSQL](https://mastra.ai/reference/storage/postgresql)
 - [MongoDB](https://mastra.ai/reference/storage/mongodb)
 - [Upstash](https://mastra.ai/reference/storage/upstash)
+- [Redis](https://mastra.ai/reference/storage/redis)
 - [Cloudflare D1](https://mastra.ai/reference/storage/cloudflare-d1)
 - [Cloudflare KV & Durable Objects](https://mastra.ai/reference/storage/cloudflare)
 - [Convex](https://mastra.ai/reference/storage/convex)
@@ -118,8 +119,6 @@ export const agent = new Agent({
 })
 ```
 
-> **Warning:** Agent-level storage isn't supported when using [Mastra Cloud Store](https://mastra.ai/docs/mastra-cloud/deployment). If you use Mastra Cloud Store, configure storage on the Mastra instance instead. This limitation doesn't apply if you bring your own database.
-
 ## Threads and resources
 
 Mastra organizes conversations using two identifiers:

package/.docs/docs/memory/working-memory.md

@@ -208,7 +208,7 @@ const paragraphMemory = new Memory({
 
 ## Structured working memory
 
-Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Zod](https://zod.dev/) schema. When using a schema, the agent will see and update working memory as a JSON object matching your schema.
+Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.). When using a schema, the agent will see and update working memory as a JSON object matching your schema.
 
 **Important:** You must specify either `template` or `schema`, but not both.
 
@@ -397,4 +397,4 @@ const response = await agent.generate('What do you know about me?', {
 
 - [Working memory with template](https://github.com/mastra-ai/mastra/tree/main/examples/memory-with-template)
 - [Working memory with schema](https://github.com/mastra-ai/mastra/tree/main/examples/memory-with-schema)
-- [Per-resource working memory](https://github.com/mastra-ai/mastra/tree/main/examples/memory-per-resource-example) - Complete example showing resource-scoped memory persistence
+- [Per-resource working memory](https://github.com/mastra-ai/mastra/tree/main/examples/memory-per-resource-example): Complete example showing resource-scoped memory persistence

package/.docs/docs/observability/logging.md

@@ -2,7 +2,7 @@
 
 Mastra's logging system captures function execution, input data, and output responses in a structured format.
 
-When deploying to Mastra Cloud, logs are shown on the [Logs](https://mastra.ai/docs/mastra-cloud/observability) page. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
+When deploying to the Mastra platform, logs are shown in the dashboard. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
 
 ## Configuring logs with `PinoLogger`
 

package/.docs/docs/observability/metrics/overview.md

@@ -8,9 +8,9 @@ Three categories of metrics are emitted automatically:
 - **Token usage metrics**: Input and output token counts broken down by type (text, cache, audio, image, reasoning).
 - **Cost estimation**: Estimated cost per model call based on an embedded pricing registry.
 
-> **Note:** Metrics require a separate OLAP store for observability. Relational databases like PostgreSQL, LibSQL, etc. are not supported for metrics. In-memory storage resets on restart.
+> **Note:** Metrics require an OLAP-capable store for observability. Relational databases like PostgreSQL, LibSQL, etc. are not supported for metrics. In-memory storage resets on restart.
 >
-> For local development, you can use [DuckDB](https://mastra.ai/reference/vectors/duckdb). We don't recommend using in-memory/DuckDB for production, ClickHouse support is coming soon for scalable metrics storage.
+> For local development, use [DuckDB](https://duckdb.org/) through `@mastra/duckdb`. For production, use [ClickHouse](https://clickhouse.com/) through `@mastra/clickhouse`.
 
 ## When to use metrics
 

package/.docs/docs/observability/overview.md

@@ -83,7 +83,7 @@ export const mastra = new Mastra({
         serviceName: 'mastra',
         exporters: [
           new DefaultExporter(), // Persists traces to storage for Mastra Studio
-          new CloudExporter(), // Sends traces to Mastra Cloud (if MASTRA_CLOUD_ACCESS_TOKEN is set)
+          new CloudExporter(), // Sends observability data to hosted Mastra Studio (if MASTRA_CLOUD_ACCESS_TOKEN is set)
         ],
         spanOutputProcessors: [
           new SensitiveDataFilter(), // Redacts sensitive data like passwords, tokens, keys