@mastra/mcp-docs-server 1.2.15-alpha.7 → 1.2.15

package/.docs/reference/server/routes.md

@@ -197,18 +197,18 @@ The `/api/workflows/run-counts` endpoint returns counts of `running` and [`suspe
 }
 ```
 
-### Stored workflows
+### Dynamic workflows
 
-Stored workflow definitions (beta) are workflows expressed as JSON, persisted through the `workflowDefinitions` storage domain, and live-registered on the running instance. See [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows).
+Dynamic workflow definitions (beta) are workflows expressed as JSON, persisted through the `workflowDefinitions` storage domain, and live-registered on the running instance. See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows).
 
-| Method   | Path                                      | Description                                                                    |
-| -------- | ----------------------------------------- | ------------------------------------------------------------------------------ |
-| `GET`    | `/api/stored/workflows`                   | List stored workflow definitions, filterable by `status` and `authorId`        |
-| `GET`    | `/api/stored/workflows/:storedWorkflowId` | Get a stored workflow definition by ID                                         |
-| `POST`   | `/api/stored/workflows`                   | Upsert a definition (plus optional helper `dependencies`) and live-register it |
-| `DELETE` | `/api/stored/workflows/:storedWorkflowId` | Delete a stored definition and unregister the live workflow                    |
+| Method   | Path                                       | Description                                                                    |
+| -------- | ------------------------------------------ | ------------------------------------------------------------------------------ |
+| `GET`    | `/api/stored/workflows`                    | List dynamic workflow definitions, filterable by `status` and `authorId`       |
+| `GET`    | `/api/stored/workflows/:dynamicWorkflowId` | Get a dynamic workflow definition by ID                                        |
+| `POST`   | `/api/stored/workflows`                    | Upsert a definition (plus optional helper `dependencies`) and live-register it |
+| `DELETE` | `/api/stored/workflows/:dynamicWorkflowId` | Delete a dynamic workflow definition and unregister the live workflow          |
 
-On authenticated servers, the read routes require the `stored-workflows:read` permission and the write routes require `stored-workflows:write`. Registered stored workflows are executed through the ordinary `/api/workflows/:workflowId` routes above.
+On authenticated servers, the read routes require the `stored-workflows:read` permission and the write routes require `stored-workflows:write`. Registered dynamic workflows are executed through the ordinary `/api/workflows/:workflowId` routes above.
 
 ### Create run request body
 

package/.docs/reference/signals/create-notification-inbox-tool.md

@@ -4,6 +4,8 @@
 
 **Added in:** `@mastra/core@1.39.0`
 
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
 `createNotificationInboxTool()` creates a Mastra tool that lets an agent inspect and manage notification inbox records for the current thread.
 
 Use this tool with durable notification signals. For sending notification records, see [`Agent.sendNotificationSignal()`](https://mastra.ai/reference/agents/agent).

package/.docs/reference/signals/signal-provider.md

@@ -4,6 +4,8 @@
 
 **Added in:** `@mastra/core@1.39.0`
 
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
 Abstract base class for building signal providers. A signal provider monitors external sources (APIs, webhooks, event streams) and pushes notification signals into agent threads through a built-in subscription registry.
 
 Signal providers aren't processors by default. Providers that need to intercept agent execution return processors from `getInputProcessors()` or `getOutputProcessors()`. Providers that expose agent-callable tools return them from `getTools()`.

package/.docs/reference/signals/task-signal-provider.md

@@ -2,6 +2,8 @@
 
 # TaskSignalProvider
 
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
 Bundles the built-in task tools (`task_write`, `task_update`, `task_complete`, `task_check`) and the `TaskStateProcessor` behind a single agent registration. Use it to add a structured, durable task list to an agent without wiring the tools and processor separately.
 
 Extends [`SignalProvider`](https://mastra.ai/reference/signals/signal-provider). The task list is stored in the thread-scoped `tasks` storage domain (the source of truth) and projected onto the agent state-signal lane by the processor, so it survives observational-memory truncation without invalidating the prompt cache.

package/.docs/reference/signals/webhook-signal-provider.md

@@ -4,6 +4,8 @@
 
 **Added in:** `@mastra/core@1.39.0`
 
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
 Concrete signal provider for push-based event delivery. Routes incoming webhook payloads to subscribed agent threads by matching the payload against a configurable resource ID extractor.
 
 Extends [`SignalProvider`](https://mastra.ai/reference/signals/signal-provider) with public subscription management and a built-in `handleWebhook()` implementation.

package/.docs/reference/storage/composite.md

@@ -338,7 +338,7 @@ const storage = new MastraCompositeStore({
 
 Observability data can quickly overwhelm general-purpose databases in production. A single agent interaction can generate hundreds of spans, and high-traffic applications can produce thousands of traces per day.
 
-**[ClickHouse](https://mastra.ai/reference/storage/clickhouse)** is recommended for production observability because it's optimized for high-volume, write-heavy analytics workloads. Use composite storage to route observability to ClickHouse while keeping other data in your primary database:
+**[ClickHouse](https://mastra.ai/integrations/databases/clickhouse)** is recommended for production observability because it's optimized for high-volume, write-heavy analytics workloads. Use composite storage to route observability to ClickHouse while keeping other data in your primary database:
 
 ```typescript
 import { MastraCompositeStore } from '@mastra/core/storage'
@@ -360,7 +360,7 @@ const storage = new MastraCompositeStore({
 })
 ```
 
-> **Note:** `ObservabilityStorageClickhouseVNext` is the current observability domain implementation. The legacy `ObservabilityStorageClickhouse` class is also exported and remains supported for projects that haven't migrated. See the [ClickHouse storage reference](https://mastra.ai/reference/storage/clickhouse) for details.
+> **Note:** `ObservabilityStorageClickhouseVNext` is the current observability domain implementation. The legacy `ObservabilityStorageClickhouse` class is also exported and remains supported for projects that haven't migrated. See the [ClickHouse storage reference](https://mastra.ai/integrations/databases/clickhouse) for details.
 
 ### Replicated ClickHouse for multi-replica clusters
 
@@ -392,6 +392,6 @@ const storage = new MastraCompositeStore({
 })
 ```
 
-Don't set `replication` on ClickHouse Cloud. Cloud rewrites `MergeTree` to `SharedMergeTree` server-side. See the [ClickHouse storage reference](https://mastra.ai/reference/storage/clickhouse) for the full config shape and operator notes.
+Don't set `replication` on ClickHouse Cloud. Cloud rewrites `MergeTree` to `SharedMergeTree` server-side. See the [ClickHouse storage reference](https://mastra.ai/integrations/databases/clickhouse) for the full config shape and operator notes.
 
-> **Info:** This approach is also required when using storage providers that don't support observability (like Convex, DynamoDB, or Cloudflare). See the [MastraStorageExporter documentation](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage) for the full list of supported providers.
+> **Note:** This approach is also required when using storage providers that don't support observability (like Convex, DynamoDB, or Cloudflare). See the [MastraStorageExporter documentation](https://mastra.ai/docs/observability/integrations/exporters/mastra-storage) for the full list of supported providers.

package/.docs/reference/storage/overview.md

@@ -10,15 +10,15 @@ Mastra storage is organized into domains. Each domain owns a set of tables or co
 
 Not every storage adapter implements every domain. Composite storage lets you mix adapters per domain when the adapter packages export the corresponding domain classes.
 
-| Domain                | Description                                                                                                                            |
-| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `memory`              | Conversation persistence: messages, threads, and resources (including working memory).                                                 |
-| `workflows`           | Workflow run snapshots used for suspend and resume.                                                                                    |
-| `workflowDefinitions` | Persisted [stored workflow](https://mastra.ai/docs/workflows/stored-workflows) definitions (beta). Loaded and live-registered on boot. |
-| `scores`              | Evaluation score records from eval runs.                                                                                               |
-| `observability`       | Traces and spans used by observability exporters and Studio.                                                                           |
-| `datasets`            | Dataset records, versioned items, and dataset versions used by experiments.                                                            |
-| `experiments`         | Experiment runs and per-item experiment results.                                                                                       |
+| Domain                | Description                                                                                                                              |
+| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| `memory`              | Conversation persistence: messages, threads, and resources (including working memory).                                                   |
+| `workflows`           | Workflow run snapshots used for suspend and resume.                                                                                      |
+| `workflowDefinitions` | Persisted [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows) definitions (beta). Loaded and live-registered on boot. |
+| `scores`              | Evaluation score records from eval runs.                                                                                                 |
+| `observability`       | Traces and spans used by observability exporters and Studio.                                                                             |
+| `datasets`            | Dataset records, versioned items, and dataset versions used by experiments.                                                              |
+| `experiments`         | Experiment runs and per-item experiment results.                                                                                         |
 
 The schema definitions below cover the built-in database-backed tables documented for `memory`, `workflows`, `scores`, and `observability`. Other domains, and non-database adapters, use implementation-specific storage structures.
 

package/.docs/reference/storage/retention.md

@@ -8,7 +8,7 @@ Storage grows without bound by default. Retention is an opt-in, age-based cleanu
 
 Retention covers **growth tables** only: tables that accumulate rows unbounded as a side effect of normal operation (conversation history, telemetry, job and run records, schedule fire history, event feeds). User-authored artifacts and config (agents, skills, workspaces, prompt blocks, datasets, schedule definitions, channel installations, and so on) grow with user intent and are edited or deleted explicitly, so they're not valid retention keys.
 
-The reference implementations are [libSQL](https://mastra.ai/reference/storage/libsql), [PostgreSQL](https://mastra.ai/reference/storage/postgresql), and [MongoDB](https://mastra.ai/reference/storage/mongodb). Other adapters keep rows forever until they implement retention.
+The reference implementations are [libSQL](https://mastra.ai/integrations/databases/libsql), [PostgreSQL](https://mastra.ai/integrations/databases/postgresql), and [MongoDB](https://mastra.ai/integrations/databases/mongodb). Other adapters keep rows forever until they implement retention.
 
 ## Usage example
 
@@ -92,7 +92,7 @@ Each domain declares which of its tables can be age-pruned and which timestamp c
 > - Experiments prune as whole units: an aged experiment's result rows are deleted together with it (results cascade with their parent), so a run is never left partially deleted. Retention doesn't have a separate `results` key.
 > - For `schedules`, the growth table is the fire history (`schedule_triggers`, one row per fire): schedule definitions are config and aren't pruned.
 > - On PostgreSQL, timestamp anchors use the timezone-aware mirror columns (for example `createdAtZ`, `completedAtZ`).
-> - LibSQL supports all domains above; PostgreSQL and MongoDB support all except `threadState` and `harness`, which they don't implement.
+> - LibSQL and PostgreSQL support all domains above except `harness`, which PostgreSQL doesn't implement. MongoDB supports all except `threadState` and `harness`.
 > - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
 
 ## Methods
@@ -238,11 +238,11 @@ Handing that free space back to the OS is a separate concern that Mastra doesn't
 
 For MongoDB, deleted documents are reused by future insertions. To reclaim disk space, run [`db.runCommand({ compact: "collection_name" })`](https://www.mongodb.com/docs/manual/reference/command/compact/) during a maintenance window.
 
-> **LibSQL and Turso:** [Turso Cloud](https://mastra.ai/reference/storage/libsql) manages storage compaction for you, so there's nothing to reclaim manually. This applies only to self-hosted libSQL files.
+> **LibSQL and Turso:** [Turso Cloud](https://mastra.ai/integrations/databases/libsql) manages storage compaction for you, so there's nothing to reclaim manually. This applies only to self-hosted libSQL files.
 
 ## Related
 
-- [libSQL storage](https://mastra.ai/reference/storage/libsql)
-- [PostgreSQL storage](https://mastra.ai/reference/storage/postgresql)
+- [libSQL storage](https://mastra.ai/integrations/databases/libsql)
+- [PostgreSQL storage](https://mastra.ai/integrations/databases/postgresql)
 - [Composite storage](https://mastra.ai/reference/storage/composite)
 - [Storage overview](https://mastra.ai/reference/storage/overview)

package/.docs/reference/streaming/ChunkType.md

@@ -310,7 +310,7 @@ Signals the completion of a processing step.
 
 **payload.messageId** (`string`): Optional message identifier
 
-**payload.stepResult** (`object`): Step execution result with reason, warnings, and continuation info
+**payload.stepResult** (`object`): Step execution result with reason, warnings, and continuation info. rawReason holds the provider's own finish reason when it reports one.
 
 **payload.output** (`object`): Output information including usage statistics
 
@@ -334,13 +334,13 @@ Contains raw data from the provider.
 
 ### finish
 
-Stream has completed successfully.
+Stream has completed.
 
 **type** (`"finish"`): Chunk type identifier
 
 **payload** (`FinishPayload`): Completion information
 
-**payload.stepResult** (`object`): Step execution result
+**payload.stepResult** (`object`): Step execution result. reason holds the normalized finish reason, and rawReason holds the provider's own finish reason when it reports one. A reason of "error" means the run failed.
 
 **payload.output** (`object`): Output information including usage
 

package/.docs/reference/streaming/agents/stream.md

@@ -10,7 +10,7 @@ The `.stream()` method enables real-time streaming of responses from an agent wi
 const stream = await agent.stream('message for agent')
 ```
 
-> **Info:** **Model Compatibility**: This method is designed for V2 models. V1 models should use the [`.streamLegacy()`](https://mastra.ai/reference/streaming/agents/streamLegacy) method. The framework automatically detects your model version and will throw an error if there's a mismatch.
+> **Note:** **Model Compatibility**: This method is designed for V2 models. V1 models should use the [`.streamLegacy()`](https://mastra.ai/reference/streaming/agents/streamLegacy) method. The framework automatically detects your model version and will throw an error if there's a mismatch.
 
 ## Parameters
 

package/.docs/reference/streaming/agents/streamLegacy.md

@@ -2,7 +2,7 @@
 
 # Agent.streamLegacy() (Legacy)
 
-> **Warning:** **Deprecated**: This method is deprecated and only works with V1 models. For V2 models, use the new [`.stream()`](https://mastra.ai/reference/streaming/agents/stream) method instead. See the [migration guide](https://mastra.ai/guides/migrations/vnext-to-standard-apis) for details on upgrading.
+> **Warning:** **Deprecated**: This method is deprecated and only works with V1 models. For V2 models, use the new [`.stream()`](https://mastra.ai/reference/streaming/agents/stream) method instead. See the [migration guide](https://mastra.ai/reference/migrations/vnext-to-standard-apis) for details on upgrading.
 
 The `.streamLegacy()` method is the legacy version of the agent streaming API, used for real-time streaming of responses from V1 model agents. This method accepts messages and optional streaming options.
 
@@ -152,7 +152,7 @@ await agent.streamLegacy('message for agent', {
 
 ## Migration to new API
 
-> **Info:** The new `.stream()` method offers enhanced capabilities including AI SDK v5+ compatibility, better structured output handling, and improved callback system. See the [migration guide](https://mastra.ai/guides/migrations/vnext-to-standard-apis) for detailed migration instructions.
+> **Note:** The new `.stream()` method offers enhanced capabilities including AI SDK v5+ compatibility, better structured-output handling, and improved callback system. See the [migration guide](https://mastra.ai/reference/migrations/vnext-to-standard-apis) for detailed migration instructions.
 
 ### Quick Migration Example
 
@@ -180,7 +180,7 @@ const result = await agent.stream('message', {
 
 ## Related
 
-- [Migration Guide](https://mastra.ai/guides/migrations/vnext-to-standard-apis)
+- [Migration Guide](https://mastra.ai/reference/migrations/vnext-to-standard-apis)
 - [New .stream() method](https://mastra.ai/reference/streaming/agents/stream)
 - [Generating responses](https://mastra.ai/docs/agents/overview)
 - [Streaming responses](https://mastra.ai/docs/agents/overview)

package/.docs/reference/streaming/agents/streamUntilIdle.md

@@ -32,7 +32,7 @@ for await (const chunk of stream.fullStream) {
 }
 ```
 
-> **Info:** `streamUntilIdle()` requires both a [`BackgroundTaskManager`](https://mastra.ai/reference/configuration) and a [memory](https://mastra.ai/docs/memory/overview) backend. Without either, it uses a plain `agent.stream()` call.
+> **Note:** `streamUntilIdle()` requires both a [`BackgroundTaskManager`](https://mastra.ai/reference/configuration) and a [memory](https://mastra.ai/docs/memory/overview) backend. Without either, it uses a plain `agent.stream()` call.
 
 ## Parameters
 

package/.docs/reference/tools/create-code-mode.md

@@ -4,6 +4,8 @@
 
 **Added in:** `@mastra/core@1.38.0`
 
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
 The `createCodeMode()` function returns a tool and generated instructions that let an agent run multi-tool computations as one TypeScript function. The generated code runs in a workspace sandbox, and each `external_*` call runs the real tool on the host with validation, request context, and tracing.
 
 For a conceptual overview, see [Code mode](https://mastra.ai/docs/agents/code-mode).
@@ -62,7 +64,7 @@ export const shopAgent = new Agent({
 
 **config.id** (`string`): The generated tool id.
 
-**transport** (`CodeModeTransport`): Optional transport implementation used to run the generated code in the sandbox. The default transport uses stdio JSON-RPC over the workspace sandbox process API. Transports that declare requiresSandbox: false (such as IsolatedVmCodeModeTransport) run without a sandbox.
+**transport** (`CodeModeTransport`): Optional transport implementation used to run the generated code in the sandbox. The default transport uses stdio JSON-RPC over the workspace sandbox process API. Transports that declare requiresSandbox: false (such as IsolatedVmCodeModeTransport and QuickJsCodeModeTransport) run without a sandbox.
 
 ## Returns
 

package/.docs/reference/tools/isolated-vm-transport.md

@@ -2,7 +2,7 @@
 
 # IsolatedVmCodeModeTransport
 
-> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 The `IsolatedVmCodeModeTransport` class runs [Code mode](https://mastra.ai/docs/agents/code-mode) programs in an in-process V8 isolate, backed by [isolated-vm](https://github.com/laverdet/isolated-vm). The isolate is the execution boundary, so no workspace sandbox is required: the program has no filesystem, network, process, or module access. Its only capabilities are the `external_*` functions, which call back into the real tools on the host.
 

package/.docs/reference/tools/mcp-client.md

@@ -244,6 +244,57 @@ const res = await agent.stream(prompt, {
 })
 ```
 
+### `listToolDefinitions()`
+
+Returns every server's tools as plain, serializable definitions, grouped by server name and keyed by the server's own tool name (without the `serverName_toolName` namespacing that `listTools()` applies).
+
+Unlike `listTools()`, the result contains no functions or references to a live client, so it can be passed through `JSON.stringify` and cached in Redis, a database, or a build artifact. Each definition holds the data from the MCP `tools/list` response (name, description, input schema, output schema, annotations, and `_meta`), plus the server name, version, and instructions captured at discovery time.
+
+```typescript
+const definitions = await mcp.listToolDefinitions()
+
+await cache.set('mcp-tools', JSON.stringify(definitions))
+```
+
+### `listToolDefinitionsWithErrors()`
+
+Like `listToolDefinitions()`, but also returns per-server errors for servers that failed to connect. Use this when caching a catalog, so you don't persist a partial manifest that omits a server that was down at discovery time.
+
+```typescript
+const { definitions, errors } = await mcp.listToolDefinitionsWithErrors()
+
+if (Object.keys(errors).length === 0) {
+  await cache.set('mcp-tools', JSON.stringify(definitions))
+}
+```
+
+### `toolFromDefinition()`
+
+Rebuilds a single executable tool from a cached definition. No connection is opened here. The client connects lazily, the first time the tool is executed.
+
+The returned tool behaves exactly like one from `listTools()`, with the same strict-mode metadata, approval policy, structured content handling, tool error handling, and reconnect behavior.
+
+```typescript
+const definitions = JSON.parse(await cache.get('mcp-tools'))
+
+const tool = await mcp.toolFromDefinition({
+  serverName: 'weather',
+  definition: definitions.weather.getForecast,
+})
+```
+
+### `toolsFromDefinitions()`
+
+Rebuilds an entire cached catalog into a namespaced tool map, without connecting. This is the cached counterpart to `listTools()`. It produces the same `serverName_toolName` keys, so you can reconstruct an agent's tool map on a cold start, and connections only open for the servers whose tools are actually called.
+
+Servers present in the catalog but no longer configured on the client are skipped, so a stale cached manifest degrades gracefully.
+
+```typescript
+const definitions = JSON.parse(await cache.get('mcp-tools'))
+
+new Agent({ id: 'agent', tools: await mcp.toolsFromDefinitions({ definitions }) })
+```
+
 ### `getServerInstructions()`
 
 Returns the instructions currently known for each configured MCP server. Servers that haven't connected yet, or don't advertise instructions, return `undefined`.

package/.docs/reference/tools/mcp-server.md

@@ -929,7 +929,7 @@ Notification methods (`resources.notifyListChanged()`, `prompts.notifyListChange
 
 ## Examples
 
-For practical examples of setting up and deploying an MCPServer, see the [Publishing an MCP Server guide](https://mastra.ai/guides/guide/publishing-mcp-server).
+For a practical example of packaging a stdio server, see [Publish a stdio server package](https://mastra.ai/docs/mcp/overview).
 
 The example at the beginning of this page also demonstrates how to instantiate `MCPServer` with both tools and agents.
 

package/.docs/reference/tools/quickjs-transport.md

@@ -0,0 +1,92 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# QuickJsCodeModeTransport
+
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
+The `QuickJsCodeModeTransport` class runs [Code mode](https://mastra.ai/docs/agents/code-mode) programs in an in-process [QuickJS](https://bellard.org/quickjs/) runtime compiled to WebAssembly. The runtime is the execution boundary, so no workspace sandbox is required: the program has no filesystem, network, process, or module access. Its only capabilities are the `external_*` functions, which call back into the real tools on the host.
+
+Unlike [`IsolatedVmCodeModeTransport`](https://mastra.ai/reference/tools/isolated-vm-transport), this transport installs no native binaries and needs no Node.js flags, so it runs on serverless platforms that disallow both. The tradeoff is speed: see [Choosing a transport](#choosing-a-transport).
+
+## Installation
+
+**npm**:
+
+```bash
+npm install @mastra/quickjs
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/quickjs
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/quickjs
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/quickjs
+```
+
+The package contains the WebAssembly module, so installing it copies files and runs nothing else.
+
+## Usage
+
+Pass the transport as the second argument to `createCodeMode()`. No `sandbox` is needed:
+
+```typescript
+import { createCodeMode } from '@mastra/core/tools'
+import { QuickJsCodeModeTransport } from '@mastra/quickjs'
+
+const { tool, instructions } = createCodeMode(
+  { tools: { getTopProducts, getProductRatings } },
+  new QuickJsCodeModeTransport({ memoryLimitMb: 128 }),
+)
+```
+
+## Constructor parameters
+
+**options** (`QuickJsCodeModeTransportOptions`): Configuration for the QuickJS runtime.
+
+**options.memoryLimitMb** (`number`): Runtime heap limit in MiB. A program that exceeds the limit is terminated and the tool returns an error result.
+
+**options.maxStackSizeBytes** (`number`): Runtime stack limit in bytes. A program that exceeds the limit, usually through runaway recursion, is terminated and the tool returns an error result.
+
+**options.module** (`QuickJSWASMModule`): A preloaded QuickJS WebAssembly module. Supply one to control when the module is loaded, or to share a single module across transports. Loaded on first run when omitted.
+
+## Choosing a transport
+
+All three transports enforce the same allow-list, tool validation, and tracing on the host. They differ in what the program itself can reach and what the host has to provide.
+
+|                     | `StdioCodeModeTransport`       | `IsolatedVmCodeModeTransport`                | `QuickJsCodeModeTransport`  |
+| ------------------- | ------------------------------ | -------------------------------------------- | --------------------------- |
+| Isolation boundary  | Workspace sandbox              | V8 isolate                                   | QuickJS WebAssembly runtime |
+| Requires a sandbox  | Yes                            | No                                           | No                          |
+| Native binary       | Node.js runtime in the sandbox | Yes                                          | No                          |
+| Node.js flags       | None                           | `--no-node-snapshot` on Node.js 20 and later | None                        |
+| Runs in the browser | No                             | No                                           | Yes                         |
+| Execution speed     | Fastest                        | Fast                                         | Slowest                     |
+
+Choose `QuickJsCodeModeTransport` when the host can't install native addons or set Node.js flags, which is common on serverless platforms. Choose `IsolatedVmCodeModeTransport` when the host allows both and programs do heavy computation.
+
+The speed difference is in the program body, not the tool calls. QuickJS interprets rather than JIT-compiles, so a compute-heavy loop can run tens of times slower than in a V8 isolate, while a program that mostly awaits `external_*` calls performs about the same because the time goes to the tools. Code Mode programs are usually the second kind.
+
+## How it works
+
+Each run creates a fresh QuickJS runtime with its own heap. TypeScript is stripped on the host with [ts-blank-space](https://github.com/bloomberg/ts-blank-space), which erases type annotations without a native compiler, then the program is evaluated inside the runtime. Every `external_*` call crosses the boundary as JSON strings in both directions, so no host object references leak into model-authored code.
+
+An `external_*` call returns a pending promise to the program and hands control straight back to the host, so many calls can be in flight at once and `Promise.all` behaves as expected.
+
+The `timeout` configured on `createCodeMode()` applies to both asynchronous hangs and synchronous infinite loops, and the runtime is disposed after every run.
+
+## Related
+
+- [Code mode](https://mastra.ai/docs/agents/code-mode)
+- [createCodeMode() reference](https://mastra.ai/reference/tools/create-code-mode)
+- [IsolatedVmCodeModeTransport reference](https://mastra.ai/reference/tools/isolated-vm-transport)

package/.docs/reference/vectors/chroma.md

@@ -4,7 +4,7 @@
 
 The ChromaVector class provides vector search using [Chroma](https://docs.trychroma.com/docs/overview/getting-started), an open-source embedding database. It offers efficient vector search with metadata filtering and hybrid search capabilities.
 
-> **Info:**
+> **Note:**
 >
 > **Chroma Cloud**
 >

package/.docs/reference/vectors/convex.md

@@ -36,7 +36,7 @@ bun add @mastra/convex@latest
 
 ## Convex setup
 
-Before using `ConvexVector`, you need to set up the Convex schema and storage handler. See [Convex Storage Setup](https://mastra.ai/reference/storage/convex) for setup instructions.
+Before using `ConvexVector`, you need to set up the Convex schema and storage handler. See [Convex Storage Setup](https://mastra.ai/integrations/databases/convex) for setup instructions.
 
 ## Constructor options
 
@@ -419,6 +419,6 @@ Use an external vector database when you need runtime-defined index creation at
 
 ## Related
 
-- [Convex Storage](https://mastra.ai/reference/storage/convex)
+- [Convex Storage](https://mastra.ai/integrations/databases/convex)
 - [Metadata Filters](https://mastra.ai/reference/rag/metadata-filters)
 - [Convex Documentation](https://docs.convex.dev/)