@mastra/mcp-docs-server 1.0.0-beta.0 → 1.0.0-beta.10

package/.docs/raw/guides/migrations/upgrade-to-v1/overview.mdx

@@ -13,71 +13,93 @@ Need help with the migration? Join our [Discord community](https://discord.gg/BT
 
 ## Migration Strategy
 
-### Update all Mastra packages
+### Update all Mastra packages to `beta` tag
 
 Use your package manager to update your project's versions. Be sure to update **all** Mastra packages at the same time to ensure compatibility.
 
+Here's how you update the most commonly used packages:
+
+```shell
+npm install @mastra/core@beta mastra@beta @mastra/loggers@beta @mastra/memory@beta
+```
+
+Install any other Mastra package with the `@beta` tag and you'll get the latest beta version available. Be sure to update all Mastra packages (especially if you're in a monorepo) to avoid version mismatches.
+
 ### Update Node.js version
 
-Mastra v1 requires Node.js 22.13.0 or higher. Update your development and production environments accordingly.
+Mastra v1 requires Node.js **22.13.0** or higher. Update your development and production environments accordingly.
+
+### Go through migration checklist
+
+Work through the [migration checklist](#migration-checklist) below to update your codebase. Each item links to a detailed guide for that specific change.
+
+:::info[Codemods]
+
+We prepared automated [codemods](https://github.com/mastra-ai/mastra/tree/main/packages/codemod) for you. If you want, you can run all v1 codemods at once:
+
+```sh
+npx @mastra/codemod@beta v1
+```
+
+:::
 
 ## Breaking Changes by Area
 
-- **[Mastra Class]/guides/v1/migrations/upgrade-to-v1/mastra)** - Import restructuring and property access changes.
-- **[Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)** - Voice methods moved to namespace and streaming API updates.
-- **[Tools]/guides/v1/migrations/upgrade-to-v1/tools)** - CreateTool execute signature changed to separate input and context.
-- **[Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)** - Function name changes and legacy features removed.
-- **[Memory]/guides/v1/migrations/upgrade-to-v1/memory)** - Configuration now requires explicit parameters and defaults changed.
-- **[Storage]/guides/v1/migrations/upgrade-to-v1/storage)** - Pagination standardized and methods renamed to list pattern.
-- **[Vectors]/guides/v1/migrations/upgrade-to-v1/vectors)** - Vector store methods renamed to list pattern.
-- **[MCP]/guides/v1/migrations/upgrade-to-v1/mcp)** - Tool context reorganized and deprecated client classes removed.
-- **[Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)** - OTEL telemetry replaced with dedicated observability package and exporters.
-- **[Evals & Scorers]/guides/v1/migrations/upgrade-to-v1/evals)** - Scorers API consolidated with new naming conventions.
-- **[CLI]/guides/v1/migrations/upgrade-to-v1/cli)** - Commands and flags removed for simpler interface.
-- **[Client SDKs]/guides/v1/migrations/upgrade-to-v1/client)** - Types and utilities renamed for consistency.
-- **[Voice Packages]/guides/v1/migrations/upgrade-to-v1/voice)** - Packages renamed from speech to voice.
+- **[Mastra Class](/guides/v1/migrations/upgrade-to-v1/mastra)** - Import restructuring and property access changes.
+- **[Agent Class](/guides/v1/migrations/upgrade-to-v1/agent)** - Voice methods moved to namespace and streaming API updates.
+- **[Tools](/guides/v1/migrations/upgrade-to-v1/tools)** - CreateTool execute signature changed to separate input and context.
+- **[Workflows](/guides/v1/migrations/upgrade-to-v1/workflows)** - Function name changes and legacy features removed.
+- **[Memory](/guides/v1/migrations/upgrade-to-v1/memory)** - Configuration now requires explicit parameters and defaults changed.
+- **[Storage](/guides/v1/migrations/upgrade-to-v1/storage)** - Pagination standardized and methods renamed to list pattern.
+- **[Vectors](/guides/v1/migrations/upgrade-to-v1/vectors)** - Vector store methods renamed to list pattern.
+- **[MCP](/guides/v1/migrations/upgrade-to-v1/mcp)** - Tool context reorganized and deprecated client classes removed.
+- **[Tracing](/guides/v1/migrations/upgrade-to-v1/tracing)** - OTEL telemetry replaced with dedicated observability package and exporters.
+- **[Evals & Scorers](/guides/v1/migrations/upgrade-to-v1/evals)** - Scorers API consolidated with new naming conventions.
+- **[CLI](/guides/v1/migrations/upgrade-to-v1/cli)** - Commands and flags removed for simpler interface.
+- **[Client SDKs](/guides/v1/migrations/upgrade-to-v1/client)** - Types and utilities renamed for consistency.
+- **[Voice Packages](/guides/v1/migrations/upgrade-to-v1/voice)** - Packages renamed from speech to voice.
 
 ## Migration Checklist
 
 Work through this checklist in order, starting with high-impact changes that affect most applications.
 
-:::info[Codemod]
+:::info[Codemods]
 
 We prepared automated [codemods](https://github.com/mastra-ai/mastra/tree/main/packages/codemod) for you. Throughout the migration guide you'll find instructions on how to use them for specific changes.
 
 If you want, you can run all v1 codemods at once:
 
 ```sh
-npx @mastra/codemod v1
+npx @mastra/codemod@beta v1
 ```
 
 :::
 
 ### High Impact Changes
 
-- Update `createTool` tool signatures to `(inputData, context)` format - [Tools]/guides/v1/migrations/upgrade-to-v1/tools)
-- Restructure `@mastra/core` imports to use subpath imports - [Mastra Class]/guides/v1/migrations/upgrade-to-v1/mastra)
-- Update pagination from `offset/limit` to `page/perPage` - [Storage]/guides/v1/migrations/upgrade-to-v1/storage)
-- Install `@mastra/observability` and wrap configuration with `new Observability()` - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
-- Migrate from `telemetry:` to `observability:` configuration (if upgrading from 0.x OTEL) - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
+- Update `createTool` tool signatures to `(inputData, context)` format - [Tools](/guides/v1/migrations/upgrade-to-v1/tools)
+- Restructure `@mastra/core` imports to use subpath imports - [Mastra Class](/guides/v1/migrations/upgrade-to-v1/mastra)
+- Update pagination from `offset/limit` to `page/perPage` - [Storage](/guides/v1/migrations/upgrade-to-v1/storage)
+- Install `@mastra/observability` and wrap configuration with `new Observability()` - [Tracing](/guides/v1/migrations/upgrade-to-v1/tracing)
+- Migrate from `telemetry:` to `observability:` configuration (if upgrading from 0.x OTEL) - [Tracing](/guides/v1/migrations/upgrade-to-v1/tracing)
 
 ### Medium Impact Changes
 
-- Rename `RuntimeContext` to `RequestContext` throughout codebase - [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent), [Tools]/guides/v1/migrations/upgrade-to-v1/tools), [Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)
-- Update storage methods from `get*` to `list*` pattern - [Storage]/guides/v1/migrations/upgrade-to-v1/storage)
-- Replace direct property access with getter methods - [Mastra Class]/guides/v1/migrations/upgrade-to-v1/mastra), [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)
-- Update memory scope if relying on default `thread` scope - [Memory]/guides/v1/migrations/upgrade-to-v1/memory)
-- Update vector store calls to use named arguments - [Storage]/guides/v1/migrations/upgrade-to-v1/storage)
-- Remove `format` parameter from agent methods - [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)
-- Update voice methods to use `agent.voice` namespace - [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)
-- Rename configuration property `processors` to `spanOutputProcessors` (if using custom processors) - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
+- Rename `RuntimeContext` to `RequestContext` throughout codebase - [Agent Class](/guides/v1/migrations/upgrade-to-v1/agent), [Tools](/guides/v1/migrations/upgrade-to-v1/tools), [Workflows](/guides/v1/migrations/upgrade-to-v1/workflows)
+- Update storage methods from `get*` to `list*` pattern - [Storage](/guides/v1/migrations/upgrade-to-v1/storage)
+- Replace direct property access with getter methods - [Mastra Class](/guides/v1/migrations/upgrade-to-v1/mastra), [Agent Class](/guides/v1/migrations/upgrade-to-v1/agent)
+- Update memory scope if relying on default `thread` scope - [Memory](/guides/v1/migrations/upgrade-to-v1/memory)
+- Update vector store calls to use named arguments - [Storage](/guides/v1/migrations/upgrade-to-v1/storage)
+- Remove `format` parameter from agent methods - [Agent Class](/guides/v1/migrations/upgrade-to-v1/agent)
+- Update voice methods to use `agent.voice` namespace - [Agent Class](/guides/v1/migrations/upgrade-to-v1/agent)
+- Rename configuration property `processors` to `spanOutputProcessors` (if using custom processors) - [Tracing](/guides/v1/migrations/upgrade-to-v1/tracing)
 
 ### Low Impact Changes
 
-- Rename `createRunAsync` to `createRun` - [Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)
-- Update voice package names from `@mastra/speech-*` to `@mastra/voice-*` - [Voice Packages]/guides/v1/migrations/upgrade-to-v1/voice)
-- Update scorer methods: `runExperiment` → `runEvals`, `getScorerByName` → `getScorerById` - [Evals & Scorers]/guides/v1/migrations/upgrade-to-v1/evals)
-- Remove deprecated CLI flags - [CLI]/guides/v1/migrations/upgrade-to-v1/cli)
-- Update client SDK types from `Get*` to `List*` - [Client SDKs]/guides/v1/migrations/upgrade-to-v1/client)
-- Replace `runCount` with `retryCount` - [Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)
-- Update custom exporter method `exportEvent` to `exportTracingEvent` (if using custom exporters) - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
+- Rename `createRunAsync` to `createRun` - [Workflows](/guides/v1/migrations/upgrade-to-v1/workflows)
+- Update voice package names from `@mastra/speech-*` to `@mastra/voice-*` - [Voice Packages](/guides/v1/migrations/upgrade-to-v1/voice)
+- Update scorer methods: `runExperiment` → `runEvals`, `getScorerByName` → `getScorerById` - [Evals & Scorers](/guides/v1/migrations/upgrade-to-v1/evals)
+- Remove deprecated CLI flags - [CLI](/guides/v1/migrations/upgrade-to-v1/cli)
+- Update client SDK types from `Get*` to `List*` - [Client SDKs](/guides/v1/migrations/upgrade-to-v1/client)
+- Replace `runCount` with `retryCount` - [Workflows](/guides/v1/migrations/upgrade-to-v1/workflows)
+- Update custom exporter method `exportEvent` to `exportTracingEvent` (if using custom exporters) - [Tracing](/guides/v1/migrations/upgrade-to-v1/tracing)

package/.docs/raw/guides/migrations/upgrade-to-v1/storage.mdx

@@ -9,6 +9,26 @@ Storage APIs have been standardized with consistent pagination and naming patter
 
 ## Changed
 
+### Required `id` property for storage instances
+
+Storage instances now require an `id` property. This unique identifier is used for tracking and managing storage instances within Mastra. The `id` should be a descriptive, unique string for each storage instance in your application.
+
+To migrate, add an `id` field to your storage constructor.
+
+```diff
+  const storage = new PostgresStore({
++   id: 'main-postgres-store',
+    connectionString: process.env.POSTGRES_CONNECTION_STRING,
+    schemaName: 'public',
+  });
+
+  const upstashStore = new UpstashStore({
++   id: 'upstash-cache-store',
+    url: process.env.UPSTASH_REDIS_REST_URL,
+    token: process.env.UPSTASH_REDIS_REST_TOKEN,
+  });
+```
+
 ### Pagination from `offset/limit` to `page/perPage`
 
 All pagination APIs now use `page` and `perPage` instead of `offset` and `limit`. This change provides a more intuitive pagination model that aligns with common web pagination patterns.
@@ -50,6 +70,16 @@ To migrate, rename the method and update pagination parameters. You can now use
 + });
 ```
 
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod@beta v1/storage-get-messages-paginated .
+```
+
+:::
+
 ### `getThreadsByResourceId` to `listThreadsByResourceId`
 
 The `getThreadsByResourceId()` method has been renamed to `listThreadsByResourceId()`. This change aligns with the convention that `list*` methods return collections.
@@ -65,6 +95,16 @@ To migrate, rename the method call and update pagination parameters.
   });
 ```
 
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod@beta v1/storage-get-threads-by-resource .
+```
+
+:::
+
 ### `getWorkflowRuns` to `listWorkflowRuns`
 
 The `getWorkflowRuns()` method has been renamed to `listWorkflowRuns()`. This change aligns with the convention that `list*` methods return collections.
@@ -81,6 +121,16 @@ To migrate, rename the method call and update pagination parameters.
   });
 ```
 
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod@beta v1/storage-list-workflow-runs .
+```
+
+:::
+
 ### `getMessagesById` to `listMessagesById`
 
 The `getMessagesById()` method has been renamed to `listMessagesById()`. This change aligns with the convention that `list*` methods return collections.
@@ -94,6 +144,16 @@ To migrate, rename the method call.
   });
 ```
 
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod@beta v1/storage-list-messages-by-id .
+```
+
+:::
+
 ### Storage `getMessages` and `saveMessages` signatures
 
 The `getMessages()` and `saveMessages()` methods have changed signatures and return types. Format overloads have been removed, and the methods now always work with `MastraDBMessage`. This change simplifies the API by removing format variations.
@@ -169,6 +229,16 @@ To migrate, pass the connection string as an object property.
 + });
 ```
 
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod@beta v1/vector-pg-constructor .
+```
+
+:::
+
 ### PGVector `defineIndex` to `buildIndex`
 
 The `defineIndex()` method has been removed in favor of `buildIndex()`. This change provides clearer naming for the index building operation.
@@ -198,6 +268,16 @@ To migrate, rename the parameter.
   });
 ```
 
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod@beta v1/storage-postgres-schema-name .
+```
+
+:::
+
 ### Score storage methods to `listScoresBy*` pattern
 
 Score storage APIs have been renamed to follow the `listScoresBy*` pattern. This change provides consistency with the broader API naming conventions.

package/.docs/raw/guides/migrations/upgrade-to-v1/tools.mdx

@@ -11,11 +11,11 @@ Tool execution signatures have been updated to use separate input and context pa
 
 ### `createTool` execute signature to `(inputData, context)` format
 
-All **`createTool`** execute functions now use a new signature with separate `inputData` and `context` parameters instead of a single destructured object. This change provides clearer separation between tool inputs and execution context.
+All `createTool` execute functions now use a new signature with separate `inputData` and `context` parameters instead of a single destructured object. This change provides clearer separation between tool inputs and execution context.
 
 **Note:** This change only applies to `createTool`. If you're using `createStep` for workflows, the signature remains `async (inputData, context)` and does not need to be changed.
 
-To migrate, update **`createTool`** signatures to use `inputData` as the first parameter (typed from `inputSchema`) and `context` as the second parameter.
+To migrate, update `createTool` signatures to use `inputData` as the first parameter (typed from `inputSchema`) and `context` as the second parameter.
 
 ```diff
   createTool({
@@ -35,7 +35,7 @@ To migrate, update **`createTool`** signatures to use `inputData` as the first p
 
 ### `createTool` context properties organization
 
-Context properties in **`createTool`** are now organized into namespaces. Agent-specific properties are under `context.agent`, workflow-specific properties are under `context.workflow`, and MCP-specific properties are under `context.mcp`. This change provides better organization and clearer API surface.
+Context properties in `createTool` are now organized into namespaces. Agent-specific properties are under `context.agent`, workflow-specific properties are under `context.workflow`, and MCP-specific properties are under `context.mcp`. This change provides better organization and clearer API surface.
 
 For tools that are executed inside an agent, access agent-specific properties through `context.agent`.
 
@@ -83,8 +83,13 @@ For tools that are executed inside a workflow, access workflow-specific properti
   });
 ```
 
+The `suspendPayload` gets validated against the `suspendSchema` when the tool is executed. If the suspendPayload doesn't match the `suspendSchema`, a warning is logged and the error is returned as tool output, but suspension continues.
+Also, when the tool is resumed, the `resumeData` gets validated against the `resumeSchema`. If the resumeData doesn't match the `resumeSchema`, the tool will return a `ValidationError`, preventing the tool resumption.
+
+To skip the `suspendSchema` or `resumeSchema` validation, do not define `suspendSchema` or `resumeSchema` in the tool creation.
+
 :::note
-For MCP-specific tool context changes, see the [MCP migration guide]/guides/v1/migrations/upgrade-to-v1/mcp).
+For MCP-specific tool context changes, see the [MCP migration guide](/guides/v1/migrations/upgrade-to-v1/mcp).
 :::
 
 ### `RuntimeContext` to `RequestContext`
@@ -109,7 +114,67 @@ To migrate, update references from `runtimeContext` to `requestContext` in tool
 You can use Mastra's codemod CLI to update your imports automatically:
 
 ```shell
-npx @mastra/codemod v1/runtime-context .
+npx @mastra/codemod@beta v1/runtime-context .
 ```
 
 :::
+
+This applies to all tool executions, whether called directly or through agents and workflows. The type narrowing ensures you handle validation errors appropriately and prevents runtime errors when accessing output properties.
+
+### Tool output validation with `outputSchema`
+
+Tools with an `outputSchema` now validate their return values at runtime. Previously, `outputSchema` was only used for type inference - the output was never validated.
+
+If your tool returns data that doesn't match its `outputSchema`, it will now return a `ValidationError` instead of the invalid data.
+
+To fix validation errors, ensure the tool's output matches the schema definition:
+
+```diff
+  const getUserTool = createTool({
+    id: "get-user",
+    outputSchema: z.object({
+      id: z.string(),
+      name: z.string(),
+      email: z.string().email(),
+    }),
+    execute: async (inputData) => {
+-     return { id: "123", name: "John" }; // Missing email
++     return { id: "123", name: "John", email: "john@example.com" };
+    },
+  });
+```
+
+When validation fails, the tool returns a `ValidationError`:
+
+```diff
++ // Before v1 - invalid output would silently pass through
+  await getUserTool.execute({});
+- // { id: "123", name: "John" } - missing email
++ // {
++ //   error: true,
++ //   message: "Tool output validation failed for get-user. The tool returned invalid output:\n- email: Required\n\nReturned output: {...}",
++ //   validationErrors: { ... }
++ // }
+```
+
+### `tool.execute` return type includes `ValidationError`
+
+The return type of `tool.execute` now includes `ValidationError` to handle validation failures. You must narrow the result type before accessing output schema properties to satisfy TypeScript's type checking.
+
+When calling `tool.execute`, check if the result contains an error before accessing output properties:
+
+```typescript
+const result = await getUserTool.execute({});
+
+// Type-safe check for validation errors
+if ('error' in result && result.error) {
+  console.error('Validation failed:', result.message);
+  console.error('Details:', result.validationErrors);
+  return;
+}
+
+// TypeScript knows result is valid here
+console.log(result.id, result.name, result.email);
+```
+
+Alternatively, update the `outputSchema` to match your actual output, or remove `outputSchema` entirely if you don't need validation.

package/.docs/raw/guides/migrations/upgrade-to-v1/tracing.mdx

@@ -46,14 +46,14 @@ export const mastra = new Mastra({
 });
 ```
 
-This minimal configuration automatically includes the `DefaultExporter`, `CloudExporter`, and `SensitiveDataFilter` processor. See the [observability tracing documentation]/docs/v1/observability/tracing/overview) for full configuration options.
+This minimal configuration automatically includes the `DefaultExporter`, `CloudExporter`, and `SensitiveDataFilter` processor. See the [observability tracing documentation](/docs/v1/observability/tracing/overview) for full configuration options.
 
 **After (v1 with custom configuration):**
 
 If you need to configure specific exporters (like OTLP), install the exporter package and configure it:
 
 ```bash
-npm install @mastra/otel-exporter @opentelemetry/exporter-trace-otlp-proto
+npm install @mastra/otel-exporter@beta @opentelemetry/exporter-trace-otlp-proto
 ```
 
 ```typescript
@@ -89,7 +89,7 @@ Key changes:
 3. Use `default: { enabled: true }` for quick setup, or `configs:` for custom configuration
 4. Export types change from string literals (`'otlp'`) to exporter class instances (`new OtelExporter()`)
 
-See the [exporters documentation]/docs/v1/observability/tracing/overview#exporters) for all available exporters.
+See the [exporters documentation](/docs/v1/observability/tracing/overview#exporters) for all available exporters.
 
 ### From AI Tracing
 
@@ -134,7 +134,7 @@ The observability functionality has moved to a dedicated `@mastra/observability`
 To migrate, install the package and update your import statements:
 
 ```bash
-npm install @mastra/observability
+npm install @mastra/observability@beta
 ```
 
 ```diff
@@ -204,13 +204,13 @@ To migrate, update method implementations in custom exporters.
 
 The OTEL-based `telemetry` configuration from 0.x has been removed. The old system with `serviceName`, `sampling.type`, and `export.type` properties is no longer supported.
 
-To migrate, follow the "From OTEL-based Telemetry" section above. For detailed configuration options, see the [observability tracing documentation]/docs/v1/observability/tracing/overview).
+To migrate, follow the "From OTEL-based Telemetry" section above. For detailed configuration options, see the [observability tracing documentation](/docs/v1/observability/tracing/overview).
 
 ### Custom instrumentation files
 
 The automatic detection of instrumentation files in `/mastra` (with `.ts`, `.js`, or `.mjs` extensions) has been removed. Custom instrumentation is no longer supported through separate files.
 
-To migrate, use the built-in exporter system or implement custom exporters using the `ObservabilityExporter` interface. See the [exporters documentation]/docs/v1/observability/tracing/overview#exporters) for details.
+To migrate, use the built-in exporter system or implement custom exporters using the `ObservabilityExporter` interface. See the [exporters documentation](/docs/v1/observability/tracing/overview#exporters) for details.
 
 ### `instrumentation.mjs` files
 
@@ -258,11 +258,11 @@ If you were using OTEL-based telemetry with specific providers in 0.x, here's ho
 
 | Provider | Exporter | Guide | Reference |
 |----------|----------|-------|-----------|
-| Arize AX, Arize Phoenix | **Arize** | [Guide]/docs/v1/observability/tracing/exporters/arize) | [Reference]/reference/v1/observability/tracing/exporters/arize) |
-| Braintrust | **Braintrust** | [Guide]/docs/v1/observability/tracing/exporters/braintrust) | [Reference]/reference/v1/observability/tracing/exporters/braintrust) |
-| Langfuse | **Langfuse** | [Guide]/docs/v1/observability/tracing/exporters/langfuse) | [Reference]/reference/v1/observability/tracing/exporters/langfuse) |
-| LangSmith | **LangSmith** | [Guide]/docs/v1/observability/tracing/exporters/langsmith) | [Reference]/reference/v1/observability/tracing/exporters/langsmith) |
-| Dash0, Laminar, New Relic, SigNoz, Traceloop, Custom OTEL | **OpenTelemetry** | [Guide]/docs/v1/observability/tracing/exporters/otel) | [Reference]/reference/v1/observability/tracing/exporters/otel) |
+| Arize AX, Arize Phoenix | **Arize** | [Guide](/docs/v1/observability/tracing/exporters/arize) | [Reference](/reference/v1/observability/tracing/exporters/arize) |
+| Braintrust | **Braintrust** | [Guide](/docs/v1/observability/tracing/exporters/braintrust) | [Reference](/reference/v1/observability/tracing/exporters/braintrust) |
+| Langfuse | **Langfuse** | [Guide](/docs/v1/observability/tracing/exporters/langfuse) | [Reference](/reference/v1/observability/tracing/exporters/langfuse) |
+| LangSmith | **LangSmith** | [Guide](/docs/v1/observability/tracing/exporters/langsmith) | [Reference](/reference/v1/observability/tracing/exporters/langsmith) |
+| Dash0, Laminar, New Relic, SigNoz, Traceloop, Custom OTEL | **OpenTelemetry** | [Guide](/docs/v1/observability/tracing/exporters/otel) | [Reference](/reference/v1/observability/tracing/exporters/otel) |
 | LangWatch | \<coming soon\> | - | - |
 
 ### Installation
@@ -274,7 +274,7 @@ npm install @mastra/[exporter-name]-exporter
 
 **OpenTelemetry exporter** (Dash0, Laminar, New Relic, SigNoz, Traceloop):
 ```bash
-npm install @mastra/otel-exporter
+npm install @mastra/otel-exporter@beta
 ```
 
-Plus the required protocol package for your provider (see [OTEL guide]/docs/v1/observability/tracing/exporters/otel#installation)).
+Plus the required protocol package for your provider (see [OTEL guide](/docs/v1/observability/tracing/exporters/otel#installation)).

package/.docs/raw/guides/migrations/upgrade-to-v1/vectors.mdx

@@ -5,10 +5,34 @@ description: "Learn how to migrate vector-related changes when upgrading to v1."
 
 # Vectors
 
-Vector store methods have been renamed to follow consistent naming conventions.
+Vector store constructors now require an `id` property, and vector store methods have been renamed to follow consistent naming conventions.
 
 ## Changed
 
+### Required `id` property for vector store instances
+
+Vector store instances now require an `id` property. This unique identifier is used for tracking and managing vector store instances within Mastra. The `id` should be a descriptive, unique string for each vector store in your application.
+
+To migrate, add an `id` field to your vector store constructor.
+
+```diff
+  const vectorStore = new PgVector({
++   id: 'main-vector-store',
+    connectionString: process.env.POSTGRES_CONNECTION_STRING,
+  });
+
+  const chromaStore = new ChromaVector({
++   id: 'chroma-embeddings',
+    url: process.env.CHROMA_URL,
+  });
+
+  const pineconeStore = new PineconeVector({
++   id: 'pinecone-production',
+    apiKey: process.env.PINECONE_API_KEY,
+    environment: process.env.PINECONE_ENVIRONMENT,
+  });
+```
+
 ### `getVectors` to `listVectors`
 
 The `getVectors()` method has been renamed to `listVectors()`. This change aligns with the naming convention used across the API where plural getter methods use the `list` prefix.

package/.docs/raw/guides/migrations/upgrade-to-v1/voice.mdx

@@ -33,7 +33,7 @@ To migrate, update configuration property names when configuring agents with voi
 You can use Mastra's codemod CLI to update your code automatically:
 
 ```shell
-npx @mastra/codemod v1/voice-property-names .
+npx @mastra/codemod@beta v1/voice-property-names .
 ```
 
 :::