@mastra/mcp-docs-server 1.2.11 → 1.2.12-alpha.3

package/.docs/reference/storage/dynamodb.md

@@ -2,7 +2,7 @@
 
 # DynamoDB storage
 
-The DynamoDB storage implementation provides a scalable and performant NoSQL database solution for Mastra, leveraging a single-table design pattern with [ElectroDB](https://electrodb.dev/).
+The DynamoDB storage implementation provides a high-capacity and performant NoSQL database solution for Mastra, using a single-table design pattern with [ElectroDB](https://electrodb.dev/).
 
 > **Observability Not Supported:** DynamoDB storage **doesn't support the observability domain**. Traces from the `MastraStorageExporter` can't be persisted to DynamoDB, and [Studio's](https://mastra.ai/docs/studio/overview) observability features won't work with DynamoDB as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse.
 
@@ -124,7 +124,7 @@ For local development, you can use [DynamoDB Local](https://docs.aws.amazon.com/
 
 ## TTL (time to live) configuration
 
-DynamoDB TTL allows you to automatically delete items after a specified time period. This is useful for:
+DynamoDB TTL allows you to automatically delete items after a specified duration for these use cases:
 
 - **Cost optimization**: Automatically remove old data to reduce storage costs
 - **Data lifecycle management**: Implement retention policies for compliance
@@ -259,19 +259,19 @@ Before diving into the architectural details, keep these key points in mind when
 
 ## Architectural approach
 
-This storage adapter utilizes a **single-table design pattern** leveraging [ElectroDB](https://electrodb.dev/), a common and recommended approach for DynamoDB. This differs architecturally from relational database adapters (like `@mastra/pg` or `@mastra/libsql`) that typically use multiple tables, each dedicated to a specific entity (threads, messages, etc.).
+This storage adapter utilizes a **single-table design pattern** with [ElectroDB](https://electrodb.dev/), a common and recommended approach for DynamoDB. This differs architecturally from relational database adapters (like `@mastra/pg` or `@mastra/libsql`) that typically use multiple tables, each dedicated to a specific entity (threads, messages, etc.).
 
 Key aspects of this approach:
 
-- **DynamoDB Native:** The single-table design is optimized for DynamoDB's key-value and query capabilities, often leading to better performance and scalability compared to mimicking relational models.
+- **DynamoDB Native:** The single-table design is optimized for DynamoDB's key-value and query capabilities, often leading to better performance and capacity compared to mimicking relational models.
 - **External Table Management:** Unlike some adapters that might offer helper functions to create tables via code, this adapter **expects the DynamoDB table and its associated Global Secondary Indexes (GSIs) to be provisioned externally** before use. Please refer to [TABLE\_SETUP.md](https://github.com/mastra-ai/mastra/blob/main/stores/dynamodb/TABLE_SETUP.md) for detailed instructions using tools like AWS CloudFormation or CDK. The adapter focuses solely on interacting with the pre-existing table structure.
 - **Consistency via Interface:** While the underlying storage model differs, this adapter adheres to the same `MastraStorage` interface as other adapters, ensuring it can be used interchangeably within the Mastra `Memory` component.
 
 ### Mastra Data in the Single Table
 
-Within the single DynamoDB table, different Mastra data entities (such as Threads, Messages, Traces, Evals, and Workflows) are managed and distinguished using ElectroDB. ElectroDB defines specific models for each entity type, which include unique key structures and attributes. This allows the adapter to store and retrieve diverse data types efficiently within the same table.
+Within the single DynamoDB table, different Mastra data entities (such as Threads, Messages, Traces, Evals, and Workflows) are managed and distinguished using ElectroDB. ElectroDB defines specific models for each entity type, which include unique key structures and attributes. It allows the adapter to store and retrieve diverse data types efficiently within the same table.
 
-For example, a `Thread` item might have a primary key like `THREAD#<threadId>`, while a `Message` item belonging to that thread might use `THREAD#<threadId>` as a partition key and `MESSAGE#<messageId>` as a sort key. The Global Secondary Indexes (GSIs), detailed in `TABLE_SETUP.md`, are strategically designed to support common access patterns across these different entities, such as fetching all messages for a thread or querying traces associated with a particular workflow.
+For example, a `Thread` item might have a primary key like `THREAD#<threadId>`, while a `Message` item belonging to that thread might use `THREAD#<threadId>` as a partition key and `MESSAGE#<messageId>` as a sort key. The Global Secondary Indexes (GSIs), detailed in `TABLE_SETUP.md`, are strategically designed to support common access patterns across these different entities, such as fetching all messages for a thread or querying traces associated with a workflow.
 
 ### Advantages of Single-Table Design
 
@@ -279,6 +279,6 @@ This implementation uses a single-table design pattern with ElectroDB, which off
 
 1. **Lower cost (potentially):** Fewer tables can simplify Read/Write Capacity Unit (RCU/WCU) provisioning and management, especially with on-demand capacity.
 2. **Better performance:** Related data can be co-located or accessed efficiently through GSIs, enabling fast lookups for common access patterns.
-3. **Simplified administration:** Fewer distinct tables to monitor, back up, and manage.
+3. **Simplified administration:** Fewer distinct tables to monitor and back up, with less to manage.
 4. **Reduced complexity in access patterns:** ElectroDB helps manage the complexity of item types and access patterns on a single table.
 5. **Transaction support:** DynamoDB transactions can be used across different "entity" types stored within the same table if needed.

package/.docs/reference/storage/lance.md

@@ -117,7 +117,7 @@ LanceDB storage can be configured for different deployment scenarios:
   ```text
   db://host:port
   ```
-- **S3 Storage**: Use Amazon S3 for scalable cloud storage
+- **S3 Storage**: Use Amazon S3 for high-capacity cloud storage
   ```text
   s3://bucket/db
   ```

package/.docs/reference/storage/mongodb.md

@@ -2,7 +2,7 @@
 
 # MongoDB storage
 
-The MongoDB storage implementation provides a scalable storage solution using MongoDB databases with support for both document storage and vector operations.
+The MongoDB storage implementation provides a high-capacity storage solution using MongoDB databases with support for both document storage and vector operations.
 
 ## Installation
 
@@ -210,7 +210,7 @@ export const mongodbAgent = new Agent({
   name: 'mongodb-agent',
   instructions:
     'You are an AI agent with the ability to automatically recall memories from previous interactions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new MongoDBStore({
       id: 'mongodb-storage',

package/.docs/reference/storage/mssql.md

@@ -150,7 +150,7 @@ const thread = await memoryStore?.getThreadById({ threadId: '...' })
 store.pool // mssql connection pool instance
 ```
 
-This enables direct queries and custom transaction management. When using these fields:
+It supports direct queries and custom transaction management. When using these fields:
 
 - You are responsible for proper connection and transaction handling.
 - Closing the store (`store.close()`) will destroy the associated connection pool.

package/.docs/reference/storage/postgresql.md

@@ -317,7 +317,7 @@ export const mastra = new Mastra({
 })
 ```
 
-This pattern ensures only one `PostgresStore` instance is created regardless of how many times the module is reloaded during development. The same pattern can be applied to other storage providers like `LibSQLStore`.
+The pattern ensures only one `PostgresStore` instance is created regardless of how many times the module is reloaded during development. The same pattern can be applied to other storage providers like `LibSQLStore`.
 
 > **Tip:** This singleton pattern is only necessary during local development with HMR. In production builds, modules are only loaded once.
 
@@ -337,7 +337,7 @@ export const pgAgent = new Agent({
   name: 'PG Agent',
   instructions:
     'You are an AI agent with the ability to automatically recall memories from previous interactions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new PostgresStore({
       id: 'pg-agent-storage',

package/.docs/reference/storage/redis.md

@@ -183,7 +183,7 @@ export const redisAgent = new Agent({
   name: 'Redis Agent',
   instructions:
     'You are an AI agent with the ability to automatically recall memories from previous interactions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new RedisStore({
       id: 'redis-agent-storage',

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

@@ -4,9 +4,9 @@
 
 Storage grows without bound by default. Retention is an opt-in, age-based cleanup system: you declare per-table `maxAge` policies in the `retention` config, then call `storage.prune()` to delete rows older than their configured age. Anything you don't configure is kept forever, so there is no behavior change until you opt in.
 
-`prune()` deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable). It never reclaims disk — on SQLite/libSQL the freed pages are reused by future writes so the file stops growing, but handing disk back to the OS (for example a `VACUUM`) is left to the underlying database and the operator to manage.
+`prune()` deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable). It never reclaims disk: on SQLite/libSQL the freed pages are reused by future writes so the file stops growing, but handing disk back to the OS (for example a `VACUUM`) is left to the underlying database and the operator to manage.
 
-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.
+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.
 
@@ -31,7 +31,7 @@ const storage = new LibSQLStore({
   },
 })
 
-// Wire this to your own cron/scheduler — Mastra never runs it for you.
+// Wire this to your own cron/scheduler: Mastra never runs it for you.
 const results = await storage.prune()
 ```
 
@@ -65,35 +65,35 @@ Set the `retention` field on the store config.
 
 ### Retention-eligible tables
 
-Each domain declares which of its tables can be age-pruned and which timestamp column anchors the comparison. The anchor is chosen so `maxAge` means what you'd expect for that data: creation time for append-only logs, last activity for live state, and completion time for jobs and runs (so in-flight work is never pruned).
-
-| Domain            | Table key          | Anchor column    | `maxAge` measures                                                 |
-| ----------------- | ------------------ | ---------------- | ----------------------------------------------------------------- |
-| `memory`          | `threads`          | `createdAt`      | Thread age                                                        |
-| `memory`          | `messages`         | `createdAt`      | Message age                                                       |
-| `memory`          | `resources`        | `createdAt`      | Resource age                                                      |
-| `threadState`     | `threadState`      | `updatedAt`      | Inactivity — state for still-active threads survives              |
-| `observability`   | `spans`            | `startedAt`      | Span age                                                          |
-| `observability`   | `metrics`          | `timestamp`      | Metric event age (v-next only)                                    |
-| `observability`   | `logs`             | `timestamp`      | Log event age (v-next only)                                       |
-| `observability`   | `scores`           | `timestamp`      | Score event age (v-next only)                                     |
-| `observability`   | `feedback`         | `timestamp`      | Feedback event age (v-next only)                                  |
-| `scores`          | `scorers`          | `createdAt`      | Score record age                                                  |
-| `workflows`       | `workflowSnapshot` | `updatedAt`      | Inactivity — suspended or long-running workflows survive          |
-| `backgroundTasks` | `backgroundTasks`  | `completedAt`    | Time since completion — in-flight tasks (`NULL`) are never pruned |
-| `experiments`     | `experiments`      | `completedAt`    | Time since completion — running experiments are never pruned      |
-| `notifications`   | `notifications`    | `createdAt`      | Notification age                                                  |
-| `harness`         | `sessions`         | `createdAt`      | Session record age                                                |
-| `schedules`       | `triggers`         | `actual_fire_at` | Fire-history age (epoch-ms column)                                |
+Each domain declares which of its tables can be age-pruned and which timestamp column anchors the comparison. The anchor is chosen so `maxAge` means what you'd expect for that data. Append-only logs use creation time, and live state uses last activity. Jobs and runs use completion time, so in-flight work is never pruned.
+
+| Domain            | Table key          | Anchor column    | `maxAge` measures                                                |
+| ----------------- | ------------------ | ---------------- | ---------------------------------------------------------------- |
+| `memory`          | `threads`          | `createdAt`      | Thread age                                                       |
+| `memory`          | `messages`         | `createdAt`      | Message age                                                      |
+| `memory`          | `resources`        | `createdAt`      | Resource age                                                     |
+| `threadState`     | `threadState`      | `updatedAt`      | Inactivity: state for still-active threads survives              |
+| `observability`   | `spans`            | `startedAt`      | Span age                                                         |
+| `observability`   | `metrics`          | `timestamp`      | Metric event age (v-next only)                                   |
+| `observability`   | `logs`             | `timestamp`      | Log event age (v-next only)                                      |
+| `observability`   | `scores`           | `timestamp`      | Score event age (v-next only)                                    |
+| `observability`   | `feedback`         | `timestamp`      | Feedback event age (v-next only)                                 |
+| `scores`          | `scorers`          | `createdAt`      | Score record age                                                 |
+| `workflows`       | `workflowSnapshot` | `updatedAt`      | Inactivity, suspended or long-running workflows survive          |
+| `backgroundTasks` | `backgroundTasks`  | `completedAt`    | Time since completion, in-flight tasks (`NULL`) are never pruned |
+| `experiments`     | `experiments`      | `completedAt`    | Time since completion, running experiments are never pruned      |
+| `notifications`   | `notifications`    | `createdAt`      | Notification age                                                 |
+| `harness`         | `sessions`         | `createdAt`      | Session record age                                               |
+| `schedules`       | `triggers`         | `actual_fire_at` | Fire-history age (epoch-ms column)                               |
 
 > **Note:**
 >
 > - The memory `observational_memory` table has no timestamp anchor, so it can't be age-pruned and isn't a valid retention key.
 > - 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.
+> - 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.
-> - 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 granularity 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.
+> - 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
 
@@ -103,11 +103,11 @@ Each domain declares which of its tables can be age-pruned and which timestamp c
 
 Deletes rows older than their configured `maxAge` across every domain that has a policy in `retention`. Returns one `PruneResult` per table touched. With no `retention` configured it's a no-op returning `[]`.
 
-`prune()` is designed to be safe on tables with millions of rows. It deletes in bounded, batched chunks — each batch is its own transaction — so it never takes a long lock or bloats the transaction log. It never runs a `VACUUM`.
+`prune()` is designed to be safe on tables with millions of rows. It deletes in bounded, batched chunks (each batch is its own transaction) so it never takes a long lock or bloats the transaction log. It never runs a `VACUUM`.
 
-Pass `options.retention` to replace the configured policies for that call only — for example to skip a domain (keep chat history) or prune more aggressively than the standing config. The store's configured `retention` is unchanged.
+Pass `options.retention` to replace the configured policies for that call only: for example to skip a domain (keep chat history) or prune more aggressively than the standing config. The store's configured `retention` is unchanged.
 
-Anchor-column indexes are created lazily on the first `prune()` call for each table with a policy — never at `init()` — so deployments that don't configure retention pay no extra index write or disk overhead. The first prune of an existing large table pays a one-time index build; subsequent prunes reuse the index.
+Anchor-column indexes are created lazily on the first `prune()` call for each table with a policy (never at `init()`) so deployments that don't configure retention pay no extra index write or disk overhead. The first prune of an existing large table pays a one-time index build. Subsequent prunes reuse the index.
 
 ```typescript
 const results = await storage.prune({
@@ -156,7 +156,7 @@ interface PruneResult {
 
 ## Running prune on a schedule
 
-`prune()` has no built-in scheduler — you decide when it runs. Because it's bounded, a single call may not delete everything. When any result has `done: false`, eligible rows remain and you call again on the next tick. This keeps each invocation short and lets a large backlog drain over several runs.
+`prune()` has no built-in scheduler: you decide when it runs. Because it's bounded, a single call may not delete everything. When any result has `done: false`, eligible rows remain and you call again on the next tick. This keeps each invocation short and lets a large backlog drain over several runs.
 
 ```typescript
 // Runs on your own cron (node-cron, a workflow schedule, an external job, etc.).
@@ -173,7 +173,7 @@ async function retentionTick() {
 }
 ```
 
-You can also cancel a long-running prune with an `AbortSignal` — the loop stops between batches and returns partial results with `done: false`, so the next run resumes cleanly.
+You can also cancel a long-running prune with an `AbortSignal`: the loop stops between batches and returns partial results with `done: false`, so the next run resumes cleanly.
 
 ## MongoDB TTL indexes (alternative to prune)
 
@@ -192,7 +192,7 @@ MongoDB offers native [TTL (Time-To-Live) indexes](https://www.mongodb.com/docs/
 > - You need resumable, cancellable cleanup operations
 > - You're using composite storage with multiple databases
 >
-> Both approaches are valid. TTL is simpler; `prune()` gives more control.
+> Both approaches are valid. TTL is simpler. `prune()` gives more control.
 
 ### Setting up TTL indexes on MongoDB
 
@@ -232,9 +232,9 @@ const storage = new MongoDBStore({
 
 ## Reclaiming disk
 
-`prune()` deletes rows but doesn't shrink the database file. On SQLite/libSQL the freed pages go on a freelist and are reused by future writes, so the file stops growing — for most users this alone solves the unbounded-growth problem.
+`prune()` deletes rows but doesn't shrink the database file. On SQLite/libSQL the freed pages go on a freelist and are reused by future writes, so the file stops growing: for most users this alone solves the unbounded-growth problem.
 
-Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself, in a maintenance window — a full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically; a manual `VACUUM FULL` is only needed if you must return disk to the OS.
+Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself in a maintenance window. A full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically; a manual `VACUUM FULL` is only needed if you must return disk to the OS.
 
 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.
 

package/.docs/reference/storage/spanner.md

@@ -2,7 +2,7 @@
 
 # Google Cloud Spanner storage
 
-The Google Cloud Spanner storage implementation provides a horizontally scalable, strongly consistent storage backend for Mastra. It targets the GoogleSQL dialect of Cloud Spanner.
+The Google Cloud Spanner storage implementation provides a horizontally high-capacity, strongly consistent storage backend for Mastra. It targets the GoogleSQL dialect of Cloud Spanner.
 
 ## Installation
 
@@ -133,14 +133,14 @@ The storage adapter creates the following tables, all using the GoogleSQL dialec
 
 Tables are created with `STRING(MAX)` for text and JSON payloads, `INT64`, `FLOAT64`, `BOOL`, and `TIMESTAMP`.
 
-Two tables also carry Spanner-specific `STORED` generated columns that the adapter populates from JSON payloads so common filters can use a regular secondary index instead of a `JSON_VALUE` scan:
+The following tables carry Spanner-specific `STORED` generated columns that the adapter populates from JSON payloads so common filters can use a regular secondary index instead of a `JSON_VALUE` scan:
 
-- `mastra_workflow_snapshot.snapshotStatus` — extracts `$.status` from `snapshot`; backs `listWorkflowRuns({ status })`.
-- `mastra_schedules.target_workflow_id` — extracts `$.workflowId` from `target`; backs `listSchedules({ workflowId })`.
+- `mastra_workflow_snapshot.snapshotStatus`: Extracts `$.status` from `snapshot`. Backs `listWorkflowRuns({ status })`.
+- `mastra_schedules.target_workflow_id`: Extracts `$.workflowId` from `target`. Backs `listSchedules({ workflowId })`.
 
 Both are added via `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` during `init()` and skipped under `initMode: 'validate'` (where the schema is owned externally). When the column is absent, the adapter falls back to a `JSON_VALUE` filter at runtime.
 
-The adapter doesn't create or use named schemas; use a dedicated database for isolation.
+The adapter doesn't create or use schemas. Use a dedicated database for isolation.
 
 ### Initialization
 
@@ -184,11 +184,11 @@ const thread = await memory?.getThreadById({ threadId: '...' })
 A few behaviors differ from other relational adapters:
 
 - Upserts use `INSERT OR UPDATE`. Spanner doesn't provide a `RETURNING` clause for upserts, so callers needing the post-write state must read it back.
-- No `TRUNCATE` exists; `dangerouslyClearAll()` issues `DELETE WHERE TRUE`.
+- No `TRUNCATE` exists. `dangerouslyClearAll()` issues `DELETE WHERE TRUE`.
 - Identifiers are quoted with backticks.
 - DDL is applied through `database.updateSchema(...)`, which is asynchronous (long-running operation).
 - `NULLS FIRST/LAST` isn't supported. Ordering with NULL handling is emulated through an `IS NULL` ordering key.
-- JSON containment isn't supported natively. `listTraces` `metadata` and `scope` filters compile to per-key `JSON_VALUE(...) = @v` equality checks, and `tags` filters compile to `EXISTS` over `JSON_QUERY_ARRAY(...)`. This differs from Postgres' `@>` containment operator (which can match nested structure in a single index scan) — most one-shot lookups still work but deeply nested structural matches aren't expressible.
+- JSON containment isn't supported natively. `listTraces` `metadata` and `scope` filters compile to per-key `JSON_VALUE(...) = @v` equality checks, and `tags` filters compile to `EXISTS` over `JSON_QUERY_ARRAY(...)`. This differs from Postgres' `@>` containment operator (which can match nested structure in a single index scan): most one-shot lookups still work but deeply nested structural matches aren't expressible.
 
 ### Direct database access
 
@@ -217,4 +217,4 @@ gcloud spanner instances create test-instance --config=emulator-config --nodes=1
 gcloud spanner databases create test-db --instance=test-instance
 ```
 
-Then connect with the same env var set in your Node.js process; the `@google-cloud/spanner` client detects the emulator automatically.
+Then connect with the same env var set in your Node.js process. The `@google-cloud/spanner` client detects the emulator automatically.

package/.docs/reference/storage/upstash.md

@@ -105,7 +105,7 @@ export const upstashAgent = new Agent({
   name: 'Upstash Agent',
   instructions:
     'You are an AI agent with the ability to automatically recall memories from previous interactions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new UpstashStore({
       id: 'upstash-agent-storage',

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

@@ -522,9 +522,9 @@ Emitted when the task throws or times out. Triggers a continuation turn when con
 
 ### background-task-suspended
 
-Emitted when a tool calls `suspend()` from inside its background execution. Pauses the task's workflow run with its snapshot persisted; resume with `mastra.backgroundTaskManager.resume(taskId, resumeData)`.
+Emitted when a tool calls `suspend()` from inside its background execution. Pauses the task's workflow run with its snapshot persisted. Resume with `mastra.backgroundTaskManager.resume(taskId, resumeData)`.
 
-When consumed by [`Agent.streamUntilIdle()`](https://mastra.ai/reference/streaming/agents/streamUntilIdle), this chunk drops the task from the loop's wait set without queuing a continuation — the agent's response ends, and the resumed task's eventual completion injects into the message list for the next user turn.
+When consumed by [`Agent.streamUntilIdle()`](https://mastra.ai/reference/streaming/agents/streamUntilIdle), this chunk drops the task from the loop's wait set without queuing a continuation. The agent's response ends, and the resumed task's eventual completion injects into the message list for the next user turn.
 
 **type** (`"background-task-suspended"`): Chunk type identifier
 

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

@@ -2,7 +2,7 @@
 
 # MastraModelOutput
 
-The `MastraModelOutput` class is returned by [.stream()](https://mastra.ai/reference/streaming/agents/stream) and provides both streaming and promise-based access to model outputs. It supports structured output generation, tool calls, reasoning, and comprehensive usage tracking.
+The `MastraModelOutput` class is returned by [.stream()](https://mastra.ai/reference/streaming/agents/stream) and provides both streaming and promise-based access to model outputs. It supports structured output generation, tool calls, reasoning, and detailed usage tracking.
 
 ```typescript
 // MastraModelOutput is returned by agent.stream()

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

@@ -2,7 +2,7 @@
 
 # Agent.stream()
 
-The `.stream()` method enables real-time streaming of responses from an agent with enhanced capabilities and format flexibility. This method accepts messages and optional streaming options, providing a next-generation streaming experience with support for both Mastra's native format and AI SDK v5+ compatibility.
+The `.stream()` method enables real-time streaming of responses from an agent with enhanced capabilities and format flexibility. This method accepts messages and optional streaming options, providing a current streaming experience with support for both Mastra's native format and AI SDK v5+ compatibility.
 
 ## Usage example
 
@@ -334,7 +334,7 @@ await agent.stream('message for agent', {
       sentiment: z.enum(['positive', 'negative', 'neutral']),
       confidence: z.number(),
     }),
-    model: 'openai/gpt-5.5',
+    model: 'openai/gpt-5.6-sol',
     errorStrategy: 'warn',
   },
   // Output processors for streaming response validation

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 falls through to a plain `agent.stream()` call.
+> **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.
 
 ## Parameters
 
@@ -54,7 +54,7 @@ For every other option (`maxSteps`, `modelSettings`, `toolChoice`, `outputProces
 
 ### Aggregate properties caveat
 
-`streamUntilIdle()` returns a proxy over the first turn's `MastraModelOutput`. Only `fullStream` is replaced with a combined stream that spans every continuation. Every other property — `text`, `toolCalls`, `toolResults`, `finishReason`, `messageList`, `getFullOutput()` — resolves against the **first turn's** internal buffer.
+`streamUntilIdle()` returns a proxy over the first turn's `MastraModelOutput`. Only `fullStream` is replaced with a combined stream that spans every continuation. Every other property (`text`, `toolCalls`, `toolResults`, `finishReason`, `messageList`, and `getFullOutput()`) resolves against the **first turn's** internal buffer.
 
 If you need an aggregate view across all continuations, consume `fullStream` yourself and accumulate.
 

package/.docs/reference/streaming/workflows/observeStream.md

@@ -28,7 +28,7 @@ for await (const chunk of stream) {
 
 ## Stream events
 
-The stream emits various event types during workflow execution. Each event has a `type` field and a `payload` containing relevant data:
+The stream emits event types during workflow execution. Each event has a `type` field and a `payload` containing relevant data:
 
 - **`workflow-start`**: Workflow execution begins
 - **`workflow-step-start`**: A step begins execution

package/.docs/reference/streaming/workflows/resumeStream.md

@@ -60,7 +60,7 @@ if (result!.status === 'suspended') {
 
 ## Stream events
 
-The stream emits various event types during workflow execution. Each event has a `type` field and a `payload` containing relevant data:
+The stream emits event types during workflow execution. Each event has a `type` field and a `payload` containing relevant data:
 
 - **`workflow-start`**: Workflow execution begins
 - **`workflow-step-start`**: A step begins execution

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

@@ -86,7 +86,7 @@ console.log('Status:', stream.status)
 
 ## Stream events
 
-The stream emits various event types during workflow execution. Each event has a `type` field and a `payload` containing relevant data:
+The stream emits event types during workflow execution. Each event has a `type` field and a `payload` containing relevant data:
 
 - **`workflow-start`**: Workflow execution begins
 - **`workflow-step-start`**: A step begins execution

package/.docs/reference/streaming/workflows/timeTravelStream.md

@@ -2,7 +2,7 @@
 
 # Run.timeTravelStream()
 
-The `.timeTravelStream()` method re-executes a workflow starting from any specific step with streaming events. This allows you to receive real-time updates during time travel execution while maintaining full visibility into each step's progress.
+The `.timeTravelStream()` method re-executes a workflow starting from any specific step with streaming events. You can receive real-time updates during time travel execution while maintaining full visibility into each step's progress.
 
 ## Usage example
 
@@ -39,7 +39,7 @@ All parameters are the same as [`Run.timeTravel()`](https://mastra.ai/reference/
 
 ## Stream events
 
-The stream emits various workflow events during execution:
+The stream emits workflow events during execution:
 
 - `workflow-step-start`: Emitted when a step begins execution
 - `workflow-step-finish`: Emitted when a step completes successfully

package/.docs/reference/templates/overview.md

@@ -2,7 +2,7 @@
 
 # Overview
 
-This reference provides comprehensive information about Mastra templates, including how to use existing templates, create your own, and contribute to the community ecosystem.
+This reference explains how to use existing Mastra templates and create your own. It also covers contributing templates to the community ecosystem.
 
 Mastra templates are pre-built project structures that demonstrate specific use cases and patterns. They provide:
 

package/.docs/reference/tools/brightdata.md

@@ -2,7 +2,7 @@
 
 # Bright Data tools
 
-The `@mastra/brightdata` package wraps the [Bright Data SDK](https://github.com/brightdata/bright-data-sdk-node) as Mastra-compatible tools. It exposes factory functions for web search and web fetch — each returning a tool created with [`createTool()`](https://mastra.ai/reference/tools/create-tool) that includes full Zod input/output schemas.
+The `@mastra/brightdata` package wraps the [Bright Data SDK](https://github.com/brightdata/bright-data-sdk-node) as Mastra-compatible tools. It exposes factory functions for web search and web fetch. Each function returns a tool created with [`createTool()`](https://mastra.ai/reference/tools/create-tool) that includes full Zod input/output schemas.
 
 The search tool is backed by Bright Data's [SERP API](https://brightdata.com/products/serp-api) and the fetch tool by [Web Unlocker](https://brightdata.com/products/web-unlocker). Both bypass bot detection and CAPTCHAs.
 

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

@@ -45,7 +45,7 @@ export const shopAgent = new Agent({
   id: 'shop-assistant',
   name: 'shop-assistant',
   instructions: ['You are a helpful shopping assistant.', instructions],
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: { execute_typescript: tool },
 })
 ```
@@ -56,13 +56,13 @@ export const shopAgent = new Agent({
 
 **config.tools** (`ToolsInput`): Tools exposed to the generated code as external\_\<id> functions. Only these tools can be called.
 
-**config.sandbox** (`WorkspaceSandbox`): Sandbox used to execute the generated code. Required unless the agent runs in a workspace that provides a sandbox. Pass new LocalSandbox() to run on the host explicitly.
+**config.sandbox** (`WorkspaceSandbox`): Sandbox used to execute the generated code. Required unless the agent runs in a workspace that provides a sandbox, or the transport provides its own execution boundary (such as IsolatedVmCodeModeTransport). Pass new LocalSandbox() to run on the host explicitly.
 
 **config.timeout** (`number`): Execution timeout in milliseconds.
 
 **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.
+**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.
 
 ## Returns
 

package/.docs/reference/tools/create-tool.md

@@ -2,7 +2,7 @@
 
 # createTool()
 
-The `createTool()` function is used to define custom tools that your Mastra agents can execute. Tools extend an agent's capabilities by allowing it to interact with external systems, perform calculations, or access specific data.
+The `createTool()` function is used to define custom tools that your Mastra agents can execute. Tools extend an agent's capabilities by allowing it to interact with external systems or perform calculations. They can also access specific data.
 
 ## Usage example
 

package/.docs/reference/tools/graph-rag-tool.md

@@ -51,7 +51,7 @@ const graphTool = createGraphRAGTool({
 
 **graphOptions.restartProb** (`number`): Probability of restarting random walk from query node. (Can be set at creation or overridden at runtime.)
 
-**providerOptions** (`Record<string, Record<string, any>>`): Provider-specific options for the embedding model (e.g., outputDimensionality). \*\*Important\*\*: Only works with AI SDK EmbeddingModelV2 models. For V1 models, configure options when creating the model itself.
+**providerOptions** (`Record<string, Record<string, any>>`): Provider-specific options for the embedding model (e.g., outputDimensionality). Only works with AI SDK EmbeddingModelV2 models. For V1 models, configure options when creating the model itself.
 
 **vectorStore** (`MastraVector | VectorStoreResolver`): Direct vector store instance or a resolver function for dynamic selection. Use a function for multi-tenant applications where the vector store is selected based on request context. When provided, vectorStoreName becomes optional.
 

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

@@ -0,0 +1,74 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# IsolatedVmCodeModeTransport
+
+> **Beta:** This feature is in 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.
+
+Compared to the default `StdioCodeModeTransport`, this transport spawns no processes and writes no temp files, which makes it a good fit for serverless and multi-tenant hosts where OS-level sandboxing isn't available.
+
+## Installation
+
+**npm**:
+
+```bash
+npm install @mastra/isolated-vm
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/isolated-vm
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/isolated-vm
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/isolated-vm
+```
+
+`isolated-vm` is a native addon. It ships prebuilt binaries for common platforms, so installation usually needs no extra setup. A C++ toolchain is only needed on platforms without a matching prebuild, where it falls back to compiling from source.
+
+On Node.js 20 and later, the host process must be started with the `--no-node-snapshot` flag, otherwise creating an isolate crashes the process. The constructor throws an error when the flag is missing. Pass the flag when starting your server, or set it through `NODE_OPTIONS`:
+
+```bash
+NODE_OPTIONS=--no-node-snapshot npm run dev
+```
+
+## Usage
+
+Pass the transport as the second argument to `createCodeMode()`. No `sandbox` is needed:
+
+```typescript
+import { createCodeMode } from '@mastra/core/tools'
+import { IsolatedVmCodeModeTransport } from '@mastra/isolated-vm'
+
+const { tool, instructions } = createCodeMode(
+  { tools: { getTopProducts, getProductRatings } },
+  new IsolatedVmCodeModeTransport({ memoryLimitMb: 128 }),
+)
+```
+
+## Constructor parameters
+
+**options** (`IsolatedVmCodeModeTransportOptions`): Configuration for the isolate.
+
+**options.memoryLimitMb** (`number`): V8 isolate heap limit in MiB. A program that exceeds the limit is terminated and the tool returns an error result.
+
+## How it works
+
+Each run creates a fresh isolate with its own heap. TypeScript is stripped on the host with esbuild, then the program is evaluated inside the isolate. Every `external_*` call crosses the isolate boundary as JSON strings in both directions, so no host object references leak into model-authored code. The allow-list, tool validation, request context, and tracing all run on the host, the same as with other transports.
+
+The `timeout` configured on `createCodeMode()` applies to both asynchronous hangs and synchronous infinite loops, and the isolate 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)