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

package/.docs/docs/workflows/control-flow.md

@@ -2,7 +2,7 @@
 
 # Control flow
 
-Workflows run a sequence of predefined tasks, and you can control how that flow is executed. Tasks are divided into **steps**, which can be executed in different ways depending on your requirements. They can run sequentially, in parallel, or follow different paths based on conditions.
+Workflows run a sequence of predefined tasks, and you can control how that flow is executed. Tasks are divided into **steps**, which can be executed in different ways depending on your requirements. They can run sequentially or in parallel, or alternatively follow different paths based on conditions.
 
 Each step connects to the next in the workflow through defined schemas that keep data controlled and consistent.
 
@@ -53,7 +53,7 @@ export const testWorkflow = createWorkflow({
 
 ## Simultaneous steps with `.parallel()`
 
-Use `.parallel()` to run steps at the same time. All parallel steps must complete before the workflow continues to the next step. Each step's `id` is used when defining a following step's `inputSchema` and becomes the key on the `inputData` object used to access the previous step's values. The outputs of parallel steps can then be referenced or combined by a following step.
+Use `.parallel()` to run steps simultaneously. All parallel steps must complete before the workflow continues to the next step. Each step's `id` is used when defining a following step's `inputSchema` and becomes the key on the `inputData` object used to access the previous step's values. The outputs of parallel steps can then be referenced or combined by a following step.
 
 ![Concurrent steps with .parallel()](/assets/images/workflows-control-flow-parallel-8e7fe60f1c4daa510431b37c973f6f8d.jpg)
 
@@ -103,7 +103,7 @@ export const testWorkflow = createWorkflow({
 
 ### Output structure
 
-When steps run in parallel, the output is an object where each key is the step's `id` and the value is that step's output. This allows you to access each parallel step's result independently.
+When steps run in parallel, the output is an object where each key is the step's `id` and the value is that step's output. You can access each parallel step's result independently.
 
 ```typescript
 const step1 = createStep({
@@ -168,7 +168,7 @@ export const testWorkflow = createWorkflow({
 
 ### Handling step failures
 
-If any parallel step throws an error, the entire parallel block fails. To build resilient parallel workflows where some steps may fail — for example, multiple research agents where one might have an expired auth token — handle errors inside the step itself using try/catch:
+If any parallel step throws an error, the entire parallel block fails. To build resilient parallel workflows where some steps may fail, for example, multiple research agents where one might have an expired auth token, handle errors inside the step itself using try/catch:
 
 ```typescript
 const resilientStep = createStep({
@@ -505,7 +505,7 @@ export const testWorkflow = createWorkflow({
 
 #### Concurrency limits
 
-Use `concurrency` to control the number of array items processed at the same time. The default is `1`, which runs steps sequentially. Increasing the value allows `.foreach()` to process multiple items simultaneously.
+Use `concurrency` to control the number of array items processed. The default is `1`, which runs steps sequentially. Increasing the value allows `.foreach()` to process multiple items simultaneously.
 
 ```typescript
 const step1 = createStep({...})
@@ -633,7 +633,7 @@ export const multiDocWorkflow = createWorkflow({...})
   .commit();
 ```
 
-**Option 2: Use foreach for documents, aggregate chunks, then foreach for embeddings**
+**Option 2: Use foreach for documents and aggregate chunks, plus then foreach for embeddings**
 
 ```typescript
 const downloadStep = createStep({
@@ -776,7 +776,7 @@ const processDocWorkflow = createWorkflow({...})
 workflow.foreach(processDocWorkflow, { concurrency: 3 })
 ```
 
-This is cleaner than chaining `.foreach().foreach()`, which creates nested arrays.
+The single `.foreach()` keeps the result flat. Chaining `.foreach().foreach()` creates nested arrays.
 
 **Inside `.parallel()`** - when a parallel branch needs its own multi-step pipeline:
 
@@ -837,7 +837,9 @@ workflow.foreach(fetchDataStep, { concurrency: 10 })
 
 ## Loop management
 
-Loop conditions can be implemented in different ways depending on how you want the loop to end. Common patterns include checking values returned in `inputData`, setting a maximum number of iterations, or aborting execution when a limit is reached.
+Loop conditions can be implemented in different ways depending on how you want the loop to end.
+
+Common patterns check values returned in `inputData` and set a maximum number of iterations. They can also abort execution when a limit is reached.
 
 ### Aborting loops
 

package/.docs/docs/workflows/error-handling.md

@@ -58,7 +58,7 @@ if (result.status === 'failed') {
 
 ## Lifecycle callbacks
 
-For scenarios where you need to handle workflow completion without awaiting the result—such as background jobs, fire-and-forget workflows, or centralized logging—you can use lifecycle callbacks.
+For scenarios where you need to handle workflow completion without awaiting the result, such as background jobs, fire-and-forget workflows, or centralized logging, you can use lifecycle callbacks.
 
 ### `onFinish`
 
@@ -168,7 +168,7 @@ const pipelineWorkflow = createWorkflow({
 
 ### Error handling in callbacks
 
-Errors thrown inside callbacks are caught and logged—they won't affect the workflow result or cause it to fail. This ensures that callback issues don't break your workflows in production.
+Errors thrown inside callbacks are caught and logged, they won't affect the workflow result or cause it to fail. As a result, callback issues don't break your workflows in production.
 
 ```typescript
 options: {

package/.docs/docs/workflows/overview.md

@@ -2,7 +2,7 @@
 
 # Workflows overview
 
-Workflows let you define complex sequences of tasks using clear, structured steps rather than relying on the reasoning of a single agent. They give you full control over how tasks are broken down, how data moves between them, and what gets executed when. Workflows run using the built-in execution engine by default, or can be deployed to [workflow runners](https://mastra.ai/docs/deployment/workflow-runners) like Inngest for managed infrastructure.
+Workflows let you define complex sequences of tasks using clear, structured steps rather than relying on the reasoning of a single agent. They give you full control over how tasks are broken down and how data moves between them, plus what gets executed when. Workflows run using the built-in execution engine by default, or can be deployed to [workflow runners](https://mastra.ai/docs/deployment/workflow-runners) like Inngest for managed infrastructure.
 
 **For AI agents:** Run `npx mastra api workflow run start test-workflow '{"inputData":{"message":"Hello, world!"}}'` to start this workflow directly instead of writing a temporary script. The command requires a running Mastra server; start the local server with `npx mastra dev`, or pass the reachable server's base URL with `--url`. Run `npx mastra api workflow run start --schema` before constructing different input. Install Mastra's skill with `npx skills add mastra-ai/skills --skill mastra` for complete API CLI discovery, targeting, schema, authentication, and error-handling guidance.
 
@@ -192,7 +192,7 @@ Open [Studio](https://mastra.ai/docs/studio/overview) and select a workflow from
 
 ## Workflow state
 
-Workflow state lets you share values across steps without passing them through every step's inputSchema and outputSchema. Use state for tracking progress, accumulating results, or sharing configuration across the entire workflow.
+Workflow state lets you share values across steps without passing them through every step's inputSchema and outputSchema. Use state for tracking progress or accumulating results, or alternatively sharing configuration across the entire workflow.
 
 ```typescript
 const step1 = createStep({
@@ -292,11 +292,11 @@ const testWorkflow = mastra.getWorkflow('testWorkflow')
 > 1. It provides access to the Mastra instance configuration (logger, telemetry, storage, registered agents, and vector stores)
 > 2. It provides full TypeScript type inference for workflow input and output schemas
 >
-> **Note:** Use `getWorkflow()` with the workflow's **registration key** (the key used when adding it to Mastra). While `getWorkflowById()` is available for retrieving workflows by their `id` property, it doesn't provide the same level of type inference.
+> Use `getWorkflow()` with the workflow's **registration key** (the key used when adding it to Mastra). While `getWorkflowById()` is available for retrieving workflows by their `id` property, it doesn't provide the same level of type inference.
 
 ## Running workflows
 
-Workflows can be run in two modes: start waits for all steps to complete before returning, and stream emits events during execution. Choose the approach that fits your use case: start when you only need the final result, and stream when you want to monitor progress or trigger actions as steps complete.
+Workflows can be run in two modes: start waits for all steps to complete before returning, while stream emits events during execution. Choose the approach that fits your use case: start when you only need the final result and stream when you want to monitor progress or trigger actions as steps complete.
 
 **.start()**:
 
@@ -411,7 +411,7 @@ For generic `writer` API usage, see [Streaming](https://mastra.ai/guides/concept
 
 ### Inspecting workflow stream payloads
 
-Events written to the stream are included in the emitted chunks. These chunks can be inspected to access any custom fields, such as event types, intermediate values, or step-specific data.
+Events written to the stream are included in the emitted chunks. Inspect these chunks to access custom fields such as event types, intermediate values, or step-specific data.
 
 ```typescript
 const testWorkflow = mastra.getWorkflow('testWorkflow')
@@ -478,7 +478,7 @@ export const testStep = createStep({
 
 ## Restarting active workflow runs
 
-When a workflow run loses connection to the server, it can be restarted from the last active step. This is useful for long-running workflows that might still be running when the server loses connection. Restarting a workflow run will resume execution from the last active step, and the workflow will continue from there.
+When a workflow run loses connection to the server and it can be restarted from the last active step. This is useful for long-running workflows that might still be running when the server loses connection. Restarting a workflow run will resume execution from the last active step, plus the workflow will continue from there.
 
 ### Restarting all active workflow runs of a workflow with `restartAllActiveWorkflowRuns()`
 
@@ -545,4 +545,5 @@ For a closer look at workflows, see our [Workflow Guide](https://mastra.ai/guide
 - [Control Flow](https://mastra.ai/docs/workflows/control-flow)
 - [Suspend and Resume](https://mastra.ai/docs/workflows/suspend-and-resume)
 - [Error Handling](https://mastra.ai/docs/workflows/error-handling)
+- [Workers](https://mastra.ai/docs/deployment/workers): Offload workflow orchestration to dedicated processes in production
 - 📹 [Agentic workflows with Mastra workshop](https://www.youtube.com/watch?v=HGt8pVPpX9g)

package/.docs/docs/workflows/scheduled-workflows.md

@@ -2,11 +2,11 @@
 
 # Scheduled workflows
 
-Declare a `schedule` field on a workflow and Mastra will fire it on the cron you specify. The same workflow remains callable directly with `workflow.start()` — scheduled fires and manual runs share a single execution path.
+Declare a `schedule` field on a workflow and Mastra will fire it on the cron you specify. The same workflow remains callable directly with `workflow.start()`, scheduled fires and manual runs share a single execution path.
 
 ## Quickstart
 
-The following workflow runs every day at 9am New York time. Register it on `Mastra` as you would any other workflow — the scheduler picks it up automatically.
+The following workflow runs every day at 9am New York time. Register it on `Mastra` as you would any other workflow, the scheduler picks it up automatically.
 
 ```typescript
 import { createWorkflow, createStep } from '@mastra/core/workflows'
@@ -40,7 +40,7 @@ A separate "register schedule" call won't happen. The scheduler reads `schedule`
 
 ## What `schedule` changes
 
-A workflow that declares `schedule` is auto-promoted to the **evented execution engine**. The public API (`workflow.start()`, `workflow.startAsync()`, `streamLegacy()`, `resume()`) is unchanged — `EventedWorkflow extends Workflow` and overrides each method with matching signatures. From your code, scheduled fires and manual runs are indistinguishable.
+A workflow that declares `schedule` is auto-promoted to the **evented execution engine**. The public API (`workflow.start()`, `workflow.startAsync()`, `streamLegacy()`, `resume()`) is unchanged, `EventedWorkflow extends Workflow` and overrides each method with matching signatures. From your code, scheduled fires and manual runs are indistinguishable.
 
 The promotion has one practical implication: evented runs require a storage adapter that supports concurrent updates, for example `@mastra/libsql`. If your adapter doesn't, `createRun()` throws a clear error pointing at the `schedule` field. Switch adapters or remove the schedule.
 
@@ -84,7 +84,7 @@ const statusCheck = createWorkflow({
 })
 ```
 
-Each entry creates an independent schedule row, fires on its own cron, and shows up separately in the Studio Schedules view.
+Each entry creates an independent schedule row and fires on its own cron, plus shows up separately in the Studio Schedules view.
 
 ## Viewing schedules in Studio
 
@@ -92,11 +92,11 @@ Studio surfaces schedules as a top-level area, not as a tab inside a workflow:
 
 - **All schedules**: open `/workflows/schedules` for a cross-workflow list. Each row shows the workflow id, cron, next fire, and the most recent run's status, so the list answers "is anything broken?" at a glance.
 - **Filtered by workflow**: append `?workflowId=<id>` to scope the list to a single workflow, for example `/workflows/schedules?workflowId=daily-report`.
-- **Schedule detail**: select any row to open `/workflows/schedules/:scheduleId`, which shows the schedule's metadata, **Pause** / **Resume** controls, and the full trigger history.
+- **Schedule detail**: Select any row to open `/workflows/schedules/:scheduleId`. The page shows schedule metadata and **Pause** / **Resume** controls, followed by the full trigger history.
 
 A workflow's header includes a **Schedules** action when the workflow has at least one schedule:
 
-- One schedule: the action links straight to that schedule's detail page.
+- When one schedule matches, the action links straight to its detail page.
 - Multiple schedules: the action links to the workflow-filtered list at `/workflows/schedules?workflowId=<id>`.
 - No schedules: the action is hidden.
 
@@ -135,9 +135,9 @@ A few rules worth knowing:
 
 - Pause is durable. The status is written to the schedules table and survives process restarts and redeploys. The declarative-config upsert never overwrites a user-set status, even when you change `cron`, `timezone`, or other fields.
 - Resume recomputes `nextFireAt` from now. A schedule paused for a week doesn't fire seven backlogged runs the moment you resume it. It fires on the next regular cron tick.
-- The only way to unpause is `resumeSchedule` (or the **Resume** button in Studio). Editing the workflow's `schedule` config doesn't unpause a paused row.
+- Unpause with `resumeSchedule` or the **Resume** button in Studio. Editing the workflow's `schedule` config doesn't unpause a paused row.
 - Pause and resume are idempotent. Calling pause on an already-paused schedule is a no-op.
-- This is an operational override, not a way to author schedules. Declarative schedules are created, deleted, and edited in code via the `schedule` field on `createWorkflow`. To create schedules imperatively at runtime instead, use the unified [`mastra.schedules`](https://mastra.ai/docs/long-running-agents/schedules) service with a `workflowId`.
+- This operational override controls existing schedules. Author declarative schedules in code. Declarative schedules are created, deleted, and edited in code via the `schedule` field on `createWorkflow`. To create schedules imperatively at runtime instead, use the unified [`mastra.schedules`](https://mastra.ai/docs/long-running-agents/schedules) service with a `workflowId`.
 
 The underlying HTTP routes are `POST /api/schedules/:scheduleId/pause` and `POST /api/schedules/:scheduleId/resume`. Both require the `schedules:write` permission.
 
@@ -153,15 +153,15 @@ Removing a schedule entry from a workflow's `schedule` array deletes its row on
 
 ## Deployment topology
 
-The built-in scheduler is a `setInterval` tick loop that polls the schedules table, claims due rows, and dispatches workflow runs through the in-process pubsub. It assumes a long-lived host process.
+The built-in scheduler uses a `setInterval` tick loop to poll the schedules table and claim due rows. It dispatches workflow runs through the in-process pubsub. It assumes a long-lived host process.
 
 ### Long-lived host (recommended)
 
-Deploy targets such as Fly Machines, Railway, Render, AWS ECS, GKE, or your own server keep the Mastra process alive between cron ticks. Schedules work without extra setup.
+Deploy targets such as Fly Machines, Railway, Render, AWS ECS, GKE, or your own server keep the Mastra process alive between cron ticks. Schedules work without extra setup. For production deployments, you can run the scheduler as a [dedicated worker process](https://mastra.ai/docs/deployment/workers) to isolate it from the API layer.
 
 ### Serverless platforms
 
-Functions-as-a-service platforms such as Vercel, Netlify, AWS Lambda, and Cloudflare Workers shut the process down after each request. The tick loop never gets a second tick. Schedules declared in code don't fire on these platforms with the built-in scheduler today.
+Functions-as-a-service platforms such as Vercel, Netlify, AWS Lambda, and Cloudflare Workers shut the process down after each request. Because the tick loop doesn't get a second tick, schedules declared in code don't fire on these platforms with the built-in scheduler today.
 
 On these platforms, use [`@mastra/inngest`](#inngest-workflows) instead. Inngest is serverless-native and holds the cron state for you.
 
@@ -181,4 +181,4 @@ Manage Inngest schedules from the [Inngest dashboard](https://www.inngest.com/do
 
 - [Workflow overview](https://mastra.ai/docs/workflows/overview)
 - [Suspend and resume](https://mastra.ai/docs/workflows/suspend-and-resume)
-- [Agent schedules](https://mastra.ai/docs/long-running-agents/schedules): run an agent, rather than a workflow, on a cron schedule, and manage both kinds at runtime through `mastra.schedules`.
+- [Agent schedules](https://mastra.ai/docs/long-running-agents/schedules): Run an agent rather than a workflow on a cron schedule, and manage both schedule types at runtime through `mastra.schedules`.

package/.docs/docs/workflows/snapshots.md

@@ -24,11 +24,11 @@ Snapshots are the key mechanism enabling Mastra's suspend and resume capabilitie
 5. Later, when `resume()` is called on the suspended step, the snapshot is retrieved
 6. The workflow execution resumes from exactly where it left off
 
-This mechanism provides a powerful way to implement human-in-the-loop workflows, handle rate limiting, wait for external resources, and implement complex branching workflows that may need to pause for extended periods.
+The mechanism provides a powerful way to implement human-in-the-loop workflows, handle rate limiting, wait for external resources, and implement complex branching workflows that may need to pause for extended periods.
 
 ## Snapshot anatomy
 
-Each snapshot includes the `runId`, input, step status (`success`, `suspended`, etc.), any suspend and resume payloads, and the final output. This ensures full context is available when resuming execution.
+Each snapshot includes the `runId`, input, step status (`success`, `suspended`, etc.), any suspend and resume payloads, and the final output. As a result, full context is available when resuming execution.
 
 ```json
 {
@@ -152,7 +152,7 @@ export const mastra = new Mastra({
 1. **Ensure Serializability**: Any data that needs to be included in the snapshot must be serializable (convertible to JSON).
 2. **Minimize Snapshot Size**: Avoid storing large data objects directly in the workflow context. Instead, store references to them (like IDs) and retrieve the data when needed.
 3. **Handle Resume Context Carefully**: When resuming a workflow, carefully consider what context to provide. This will be merged with the existing snapshot data.
-4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows, especially long-running ones, to ensure they're properly resumed.
+4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows and especially long-running ones, plus to ensure they're properly resumed.
 5. **Consider Storage Scaling**: For applications with many suspended workflows, ensure your storage solution is appropriately scaled.
 
 ## Custom snapshot metadata

package/.docs/docs/workflows/suspend-and-resume.md

@@ -157,7 +157,7 @@ const approvalStep = createStep({
 })
 ```
 
-The `suspendData` parameter is automatically populated when a step is resumed and contains the exact data that was passed to the `suspend()` function during the original suspension. This allows you to maintain context about why the workflow was suspended and use that information during the resume process.
+The `suspendData` parameter is automatically populated when a step is resumed and contains the exact data that was passed to the `suspend()` function during the original suspension. You can maintain context about why the workflow was suspended and use that information during the resume process.
 
 ## Identifying suspended executions
 

package/.docs/docs/workflows/time-travel.md

@@ -2,7 +2,9 @@
 
 # Time travel
 
-Time travel allows you to re-execute a workflow starting from any specific step, using either stored snapshot data or custom context you provide. This is useful for debugging failed workflows, testing individual steps with different inputs, or recovering from errors without re-running the entire workflow. You can also use time travel to execute a workflow that hasn't been run yet, starting from any specific step.
+Time travel allows you to re-execute a workflow starting from any specific step, using either stored snapshot data or custom context you provide.
+
+This is useful for debugging failed workflows or testing individual steps with different inputs, or alternatively recovering from errors without re-running the entire workflow. You can also use time travel to execute a workflow that hasn't been run yet, starting from any specific step.
 
 ## How time travel works
 

package/.docs/docs/workflows/workflow-state.md

@@ -2,7 +2,7 @@
 
 # Workflow state
 
-Workflow state lets you share values across steps without passing them through every step's inputSchema and outputSchema. This is useful for tracking progress, accumulating results, or sharing configuration across the entire workflow.
+Workflow state lets you share values across steps without passing them through every step's inputSchema and outputSchema. This is useful for tracking progress or accumulating results, or alternatively sharing configuration across the entire workflow.
 
 ## State vs step input/output
 

package/.docs/docs/workspace/filesystem.md

@@ -26,7 +26,7 @@ Available providers:
 - [`PlatformFilesystem`](https://mastra.ai/reference/workspace/platform-filesystem): Stores files in a Mastra Platform workspace bucket
 - [`GoogleDriveFilesystem`](https://mastra.ai/reference/workspace/google-drive-filesystem): Stores files inside a Google Drive folder
 - [`AzureBlobFilesystem`](https://mastra.ai/reference/workspace/azure-blob-filesystem): Stores files in Azure Blob Storage
-- [`FilesSDKFilesystem`](https://mastra.ai/reference/workspace/files-sdk-filesystem): Stores files in any [FilesSDK](https://files-sdk.dev) adapter (S3, R2, GCS, Azure Blob, Vercel Blob, local filesystem, and more) — useful when you want one provider that can target multiple backends
+- [`FilesSDKFilesystem`](https://mastra.ai/reference/workspace/files-sdk-filesystem): Stores files in any [FilesSDK](https://files-sdk.dev) adapter (S3, R2, GCS, Azure Blob, Vercel Blob, local filesystem, and more): useful when you want one provider that can target multiple backends
 - [`AgentFSFilesystem`](https://mastra.ai/reference/workspace/agentfs-filesystem): Stores files in a Turso/SQLite database via AgentFS
 - [`MesaFilesystem`](https://mastra.ai/reference/workspace/mesa-filesystem): Stores files in versioned Mesa repos
 - [`ArchilFilesystem`](https://mastra.ai/reference/workspace/archil-filesystem): Stores files on Archil elastic, serverless disks
@@ -49,7 +49,7 @@ const workspace = new Workspace({
 
 const agent = new Agent({
   id: 'file-agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: 'You are a helpful file management assistant.',
   workspace,
 })
@@ -60,12 +60,12 @@ const response = await agent.generate('List all files in the workspace')
 
 ## Containment
 
-By default, `LocalFilesystem` runs in **contained mode** — all file operations are restricted to stay within `basePath`. This prevents path traversal attacks and symlink escapes.
+By default, `LocalFilesystem` runs in **contained mode**, all file operations are restricted to stay within `basePath`. This prevents path traversal attacks and symlink escapes.
 
 In contained mode:
 
 - **Relative paths** (e.g. `src/index.ts`) resolve against `basePath`
-- **Absolute paths** (e.g. `/home/user/.config/file.txt`) are treated as real filesystem paths — if they fall outside `basePath` and any `allowedPaths`, a `PermissionError` is thrown
+- **Absolute paths** (e.g. `/home/user/.config/file.txt`) are treated as real filesystem paths: if they fall outside `basePath` and any `allowedPaths`, a `PermissionError` is thrown
 - **Tilde paths** (e.g. `~/Documents`) expand to the home directory and follow the same containment rules
 
 If your agent needs to access specific paths outside `basePath`, use `allowedPaths` to grant access without disabling containment entirely. Relative paths are resolved against `basePath`, and absolute paths are used as-is:
@@ -86,7 +86,7 @@ Allowed paths can be updated at runtime using the `setAllowedPaths()` method:
 workspace.filesystem.setAllowedPaths(prev => [...prev, '/home/user/documents'])
 ```
 
-This is the recommended approach for least-privilege access — the agent can only reach the specific directories you allow.
+This is the recommended approach for least-privilege access, the agent can only reach the specific directories you allow.
 
 If your agent needs unrestricted access to the entire filesystem, disable containment:
 
@@ -121,7 +121,7 @@ const workspace = new Workspace({
 
 const agent = new Agent({
   id: 'multi-role-agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   workspace,
 })
 ```
@@ -170,7 +170,7 @@ const workspace = new Workspace({
 
 With a static filesystem, write tools (`write_file`, `edit_file`, `delete`, `mkdir`) are excluded from the agent's toolset entirely. The agent can still read and list files.
 
-When using a [dynamic filesystem](#dynamic-filesystem), write tools are always included because `readOnly` isn't known until the resolver runs. Instead, write operations are blocked at runtime — the tool returns an error if the resolved filesystem is read-only.
+When using a [dynamic filesystem](#dynamic-filesystem), write tools are always included because `readOnly` isn't known until the resolver runs. Instead, write operations are blocked at runtime, the tool returns an error if the resolved filesystem is read-only.
 
 ## Mounts and `CompositeFilesystem`
 
@@ -207,9 +207,9 @@ With this configuration:
 
 ### Path routing
 
-All file paths must start with a mount prefix. Operations on paths that don't match any mount will fail. Listing the root directory (`/`) returns virtual directory entries for each mount point.
+All file paths must start with a mount prefix because operations fail when their paths don't match a mount. Listing the root directory (`/`) returns virtual directory entries for each mount point.
 
-Mount paths can't be nested — for example, you can't mount at both `/data` and `/data/sub`.
+Mount paths can't be nested, for example, you can't mount at both `/data` and `/data/sub`.
 
 ### `filesystem` vs `mounts`
 
@@ -218,7 +218,7 @@ Mount paths can't be nested — for example, you can't mount at both `/data` and
 - Use **`filesystem`** when you have a single storage provider and don't need to mount it into a sandbox. The agent gets file tools that operate directly against the provider.
 - Use **`mounts`** when you need cloud storage accessible inside a sandbox, or when you want to combine multiple providers. The workspace creates a CompositeFilesystem for file tools and FUSE-mounts the storage into the sandbox.
 
-For local development, you typically don't need `mounts` — a `LocalFilesystem` and `LocalSandbox` pointed at the same directory gives you both file tools and command execution on the same files. See [configuration patterns](https://mastra.ai/docs/workspace/overview) for more detail.
+For local development, you typically don't need `mounts`, a `LocalFilesystem` and `LocalSandbox` pointed at the same directory gives you both file tools and command execution on the same files. See [configuration patterns](https://mastra.ai/docs/workspace/overview) for more detail.
 
 ## Agent tools
 

package/.docs/docs/workspace/lsp.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/core@1.1.0`
 
-LSP inspection gives workspace-backed agents semantic code intelligence. When you enable LSP on a workspace, agents can inspect symbols in supported files to retrieve hover information, jump to definitions, and find implementations.
+LSP inspection gives workspace-backed agents semantic code intelligence. When you enable LSP on a workspace, agents can inspect symbols in supported files to retrieve hover information and jump to definitions. They can also find implementations.
 
 ## When to use LSP inspection
 

package/.docs/docs/workspace/overview.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/core@1.1.0`
 
-A Mastra workspace gives agents a persistent environment for storing files and executing commands. Agents use workspace tools to read and write files, run shell commands, and search indexed content.
+A Mastra workspace gives agents a persistent environment for storing files and executing commands. Agents use workspace tools to read and write files and run shell commands, plus search indexed content.
 
 A workspace supports the following features:
 
@@ -77,7 +77,7 @@ const workspace = new Workspace({
 
 export const myAgent = new Agent({
   id: 'my-agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   workspace,
 })
 ```
@@ -88,11 +88,11 @@ Mastra registers global and agent workspaces so they can be listed and retrieved
 
 For manual cleanup, use [`mastra.removeWorkspace()`](https://mastra.ai/reference/core/removeWorkspace). Pass `{ destroy: true }` when the workspace should be destroyed before it's removed from the registry.
 
-Static providers are owned by the workspace. Resolver-backed providers are owned by your application because the workspace creates them at request time. See [dynamic sandbox lifecycle ownership](https://mastra.ai/docs/workspace/sandbox) for the resolver cleanup model.
+Static providers are owned by the workspace. Resolver-backed providers are owned by your application because the workspace creates them at request time. See [runtime sandbox lifecycle ownership](https://mastra.ai/docs/workspace/sandbox) for the resolver cleanup model.
 
 ## Configuration patterns
 
-Workspaces support several configuration patterns depending on what capabilities your agent needs. The two main building blocks are `filesystem` (file tools) and `sandbox` (command execution), with `mounts` as the way to bridge cloud storage into sandboxes.
+Workspaces support several configuration patterns depending on what capabilities your agent needs. The main building blocks are `filesystem` (file tools) and `sandbox` (command execution), with `mounts` as the way to bridge cloud storage into sandboxes.
 
 ### Filesystem + sandbox (local)
 
@@ -132,7 +132,7 @@ Under the hood, `mounts` creates a [CompositeFilesystem](https://mastra.ai/docs/
 
 You can mount multiple providers at different paths. Each mount path must be unique and non-overlapping.
 
-> **Note:** `filesystem` and `mounts` are mutually exclusive — you can't use both in the same workspace. Use `filesystem` for a single provider without a sandbox, or `mounts` when you need to combine cloud storage with a sandbox.
+> **Note:** `filesystem` and `mounts` are mutually exclusive, you can't use both in the same workspace. Use `filesystem` for a single provider without a sandbox, or `mounts` when you need to combine cloud storage with a sandbox.
 
 ### Filesystem only
 
@@ -252,7 +252,7 @@ const workspace = new Workspace({
 
 ### Dynamic tool configuration
 
-Tool options that accept functions receive a context object and return a boolean. This enables context-aware tool behavior.
+Tool options that accept functions receive a context object and return a boolean. It enables context-aware tool behavior.
 
 ```typescript
 const workspace = new Workspace({
@@ -280,7 +280,7 @@ Functions for `enabled` receive `{ requestContext, workspace }`. Functions for `
 
 ### Tool name remapping
 
-Rename workspace tools to match the conventions your agent expects. The config key remains the original `WORKSPACE_TOOLS` constant — only the exposed name changes.
+Rename workspace tools to match the conventions your agent expects. The config key remains the original `WORKSPACE_TOOLS` constant, only the exposed name changes.
 
 ```typescript
 import { Workspace, LocalFilesystem, LocalSandbox, WORKSPACE_TOOLS } from '@mastra/core/workspace'
@@ -299,7 +299,7 @@ const workspace = new Workspace({
 })
 ```
 
-The agent sees `view`, `search_content`, `find_files`, `execute_command`, and `lsp_inspect` instead of the default `mastra_workspace_*` names. Tool names must be unique — duplicate names or conflicts with other default names throw an error.
+The agent sees `view`, `search_content`, `find_files`, `execute_command`, and `lsp_inspect` instead of the default `mastra_workspace_*` names. Tool names must be unique, duplicate names or conflicts with other default names throw an error.
 
 ### Tool hooks
 
@@ -325,17 +325,17 @@ const workspace = new Workspace({
 
 Return `{ proceed: false, output }` from `beforeToolCall` to skip the tool call and use `output` as its result.
 
-If the owning agent also defines [tool hooks](https://mastra.ai/docs/agents/using-tools), workspace hooks run inside the agent hook wrapper: agent `beforeToolCall` first, then workspace `beforeToolCall`, then the tool, then workspace `afterToolCall`, then agent `afterToolCall`.
+If the owning agent also defines [tool hooks](https://mastra.ai/docs/agents/using-tools), workspace hooks run inside the agent hook wrapper. The order is agent `beforeToolCall`, workspace `beforeToolCall`, the tool, workspace `afterToolCall`, and agent `afterToolCall`.
 
 ## LSP inspection
 
-Enable `lsp` on a workspace to add semantic code inspection through language servers. This adds the `mastra_workspace_lsp_inspect` tool by default, which can return hover information, definition locations, and implementations for a symbol at a specific cursor position.
+Enable `lsp` on a workspace to add semantic code inspection through language servers. This adds the `mastra_workspace_lsp_inspect` tool by default, which can return hover information and definition locations, plus implementations for a symbol at a specific cursor position.
 
 See [LSP inspection](https://mastra.ai/docs/workspace/lsp) for configuration, examples, and tool name remapping.
 
 ### Output truncation
 
-Workspace tools automatically truncate large outputs to avoid exceeding LLM context limits. Two layers of truncation apply:
+Workspace tools automatically truncate large outputs to avoid exceeding LLM context limits. These layers of truncation apply:
 
 1. **Line-based tail**: Command output is limited to the last 200 lines by default (configurable per-command via the `tail` parameter)
 2. **Token-based limit**: Tool output is capped at 2000 tokens by default
@@ -380,7 +380,7 @@ await filesystem.writeFile('/docs/file.md', newContent, {
 
 ## Initialization
 
-Calling `init()` is optional in most cases—some providers initialize on first operation. Call `init()` manually when using a workspace outside of Mastra (standalone scripts, tests) or when you need to pre-provision resources before the first agent interaction.
+Calling `init()` is optional in most cases, some providers initialize on first operation. Call `init()` manually when using a workspace outside of Mastra (standalone scripts, tests) or when you need to pre-provision resources before the first agent interaction.
 
 ```typescript
 import { Workspace, LocalFilesystem, LocalSandbox } from '@mastra/core/workspace'

package/.docs/docs/workspace/sandbox.md

@@ -51,7 +51,7 @@ const workspace = new Workspace({
 
 const agent = new Agent({
   id: 'dev-agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: 'You are a helpful development assistant.',
   workspace,
 })
@@ -100,9 +100,9 @@ const bobCtx = new RequestContext([['user-id', 'bob']])
 await agent.generate('List files in cwd', { requestContext: bobCtx })
 ```
 
-By default, workspace instructions describe the dynamic sandbox with stable placeholder text. See [Workspace instructions](#workspace-instructions) to include concrete per-request details.
+By default, workspace instructions describe the runtime sandbox with stable placeholder text. See [Workspace instructions](#workspace-instructions) to include concrete per-request details.
 
-The resolver can also be asynchronous — for example to look up tenant configuration from a database:
+The resolver can also be asynchronous, for example to look up tenant configuration from a database:
 
 ```typescript
 const workspace = new Workspace({
@@ -115,9 +115,11 @@ const workspace = new Workspace({
 
 ### Lifecycle ownership
 
-When the sandbox is a static instance, `workspace.init()` calls its `start()` method and `workspace.destroy()` calls its `destroy()` method. With a resolver, the workspace has no instance to manage at construction time — the caller owns the returned sandbox's lifecycle.
+When the sandbox is a static instance, `workspace.init()` calls its `start()` method and `workspace.destroy()` calls its `destroy()` method. With a resolver, the workspace has no instance to manage at construction time, the caller owns the returned sandbox's lifecycle.
 
-The resolver must return a sandbox that's ready to use, either already started or able to handle calls without explicit startup. The caller also owns cleanup timing for returned sandboxes. Cleanup might happen per request, per tenant, per user, or as part of a long-lived sandbox pool; `workspace.destroy()` doesn't destroy resolver-returned sandboxes.
+The resolver must return a sandbox that's ready to use, either already started or able to handle calls without explicit startup. The caller also owns cleanup timing for returned sandboxes.
+
+Cleanup can happen per request, tenant, or user. It can also be part of a long-lived sandbox pool. `workspace.destroy()` doesn't destroy resolver-returned sandboxes.
 
 > **Note:** `sandbox` resolvers are incompatible with `mounts` and `lsp: true`. Both require a concrete sandbox instance at construction time, so combining them with a resolver throws an `INVALID_CONFIG` error (for `mounts`) or disables LSP with a warning (for `lsp: true`).
 
@@ -208,7 +210,7 @@ By default, background processes inherit the agent's abort signal and are killed
 
 - **`undefined`** (default): Uses the agent's abort signal
 - **`AbortSignal`**: Uses a custom signal
-- **`null` or `false`**: Disables abort — processes persist after agent shutdown
+- **`null` or `false`**: Disables abort: processes persist after agent shutdown
 
 ```typescript
 import { Workspace, LocalSandbox, WORKSPACE_TOOLS } from '@mastra/core/workspace'
@@ -227,7 +229,7 @@ const workspace = new Workspace({
 
 Use `null` or `false` for cloud sandboxes (for example, E2B, Daytona, or Modal) where processes should outlive the agent.
 
-> **Note:** For the full `SandboxProcessManager` API (spawning processes programmatically, reading output, sending stdin), see the [`SandboxProcessManager` reference](https://mastra.ai/reference/workspace/process-manager).
+> **Note:** For the full `SandboxProcessManager` API (spawning processes programmatically and reading output, plus sending stdin), see the [`SandboxProcessManager` reference](https://mastra.ai/reference/workspace/process-manager).
 
 ## Related
 

package/.docs/docs/workspace/search.md

@@ -32,7 +32,7 @@ When you search:
 2. Documents are scored based on relevance to the query
 3. Results are ranked by score and returned with the matching content
 
-Workspaces support three search modes: BM25 keyword search, vector semantic search, and hybrid search that combines both.
+Workspaces support three search modes: BM25 keyword search and vector semantic search, plus hybrid search that combines both.
 
 ## BM25 keyword search
 
@@ -91,7 +91,7 @@ The embedder above takes one text at a time. Indexing a workspace with hundreds
 
 When the provider supports batching (for example, OpenAI's `embedMany`), pass an embedder that takes an array of texts and accepts many embeddings back in one call. To opt in, set a `batch: true` property on the function. Mastra checks for that property at runtime and switches to the batched path.
 
-The following example replaces the single-text embedder with a batched one. The embedder function takes an array, returns an array of embeddings in the same order, and carries two extra properties:
+The following example replaces the single-text embedder with a batched one. The embedder function takes an array and returns an array of embeddings in the same order, plus carries two extra properties:
 
 - `batch: true`: marks the function as batch-capable. Without this property, Mastra calls it one text at a time.
 - `maxBatchSize`: the largest array the provider accepts in one call. Mastra splits larger requests into chunks of this size and sends them in parallel. Set this to your provider's documented limit (for example, 2048 for OpenAI, 96 for Cohere, 128 for Voyage). Omit it to send every pending text in one request.
@@ -149,7 +149,7 @@ const workspace = new Workspace({
 })
 ```
 
-The index name must be a valid SQL identifier: start with a letter or underscore, contain only letters, numbers, or underscores, and be at most 63 characters long.
+The index name must be a valid SQL identifier: start with a letter or underscore, contain only letters, numbers, or shows, and be at most 63 characters long.
 
 ## Indexing content
 

package/.docs/docs/workspace/skills.md

@@ -102,7 +102,7 @@ const workspace = new Workspace({
 
 ## Dynamic skills
 
-For dynamic skill paths based on context, pass a function:
+For runtime skill paths based on context, pass a function:
 
 ```typescript
 const workspace = new Workspace({
@@ -123,11 +123,11 @@ When a workspace has skills configured, agents automatically get access to skill
 
 The agent has three skill tools:
 
-- **`skill`** — Loads a skill's full instructions and returns them in the tool result. The agent calls this whenever it needs a skill's guidance.
-- **`skill_read`** — Reads a file from a skill's `references/`, `scripts/`, or `assets/` directory.
-- **`skill_search`** — Searches across all skill content. Uses BM25 or vector search when configured, otherwise falls back to basic text matching.
+- **`skill`**: Loads a skill's full instructions and returns them in the tool result. The agent calls this whenever it needs a skill's guidance.
+- **`skill_read`**: Reads a file from a skill's `references/`, `scripts/`, or `assets/` directory.
+- **`skill_search`**: Searches across all skill content. Uses BM25 or vector search when configured, otherwise falls back to basic text matching.
 
-This design is stateless — there is no activation state to track. If the skill instructions leave the conversation context (due to context window limits or compaction), the agent can call `skill` again to reload them.
+This design is stateless, there is no activation state to track. If the skill instructions leave the conversation context (due to context window limits or compaction), the agent can call `skill` again to reload them.
 
 ## Same-named skills
 
@@ -136,7 +136,7 @@ When multiple skill directories contain a skill with the same name, all of them
 When the agent activates a skill by name, tie-breaking determines which one is returned:
 
 1. **Source-type priority**: local skills take precedence over managed (`.mastra/`) skills, which take precedence over external (`node_modules/`) skills.
-2. **Unresolvable conflicts throw**: if two skills share the same name _and_ the same source type (for example, two local skills both named `brand-guidelines`), `get()` throws an error. Rename one or move it to a different source type to resolve the conflict.
+2. **Unresolvable conflicts throw**: if two skills share the same name and the same source type (for example, two local skills both named `brand-guidelines`), `get()` throws an error. Rename one or move it to a different source type to resolve the conflict.
 3. **Path escape hatch**: the agent can pass a skill's full path instead of its name to activate a specific skill, bypassing tie-breaking entirely.
 
 ```typescript
@@ -191,7 +191,7 @@ When `skillSource` is provided, it's used instead of the workspace filesystem fo
 
 ## Agent-level skills
 
-You can also attach skills directly to an agent without a workspace using `createSkill()` and the agent's `skills` config. When both agent-level and workspace-level skills exist, they merge — agent-level skills take precedence on name conflicts.
+You can also attach skills directly to an agent without a workspace using `createSkill()` and the agent's `skills` config. When both agent-level and workspace-level skills exist, they merge, agent-level skills take precedence on name conflicts.
 
 See [Agent skills](https://mastra.ai/docs/agents/skills) for details.