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

package/.docs/guides/build-your-ui/ai-sdk-ui.md

@@ -44,7 +44,7 @@ You're now ready to follow the integration guides and recipes below!
 
 ## Integration guides
 
-Typically, you'll set up API routes that stream Mastra content in AI SDK-compatible format, and then use those routes in AI SDK UI hooks like `useChat()`. Below you'll find two main approaches to achieve this:
+Typically, you'll set up API routes that stream Mastra content in AI SDK-compatible format, and then use those routes in AI SDK UI hooks like `useChat()`. Choose one of these approaches:
 
 - [Mastra's server](#mastras-server)
 - [Framework-agnostic](#framework-agnostic)
@@ -298,7 +298,7 @@ export default function Page() {
 }
 ```
 
-Below are two approaches to implementing the backend:
+Choose a backend implementation:
 
 **Mastra Server**:
 
@@ -380,7 +380,7 @@ export async function POST(req: Request) {
 
 ## Custom UI
 
-Custom UI (also known as Generative UI) allows you to render custom React components based on data streamed from Mastra. Instead of displaying raw text or JSON, you can create visual components for tool outputs, workflow progress, agent network execution, and custom events.
+Custom UI (also known as Generative UI) allows you to render custom React components based on data streamed from Mastra. Instead of displaying raw text or JSON, you can create visual components for tool outputs and workflow progress, including agent network execution and custom events.
 
 Use Custom UI when you want to:
 
@@ -990,7 +990,7 @@ export function ChatAdditional() {
 }
 ```
 
-Two examples on how to implement the backend portion of it.
+Implement the backend with either of these examples.
 
 **Mastra Server**:
 
@@ -1308,7 +1308,7 @@ import { nestedAgentTool } from '../tools/nested-agent-tool'
 export const forecastAgent = new Agent({
   id: 'forecast-agent',
   instructions: 'Use the nested-agent-stream tool when asked about weather.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: { nestedAgentTool },
 })
 ```
@@ -1545,7 +1545,7 @@ For a complete implementation, see the [workflow-agent-text-stream example](http
 
 ### Multi-stage progress with branching workflows
 
-For workflows with conditional branching (e.g., express vs standard shipping), you can track progress across different branches by including a identifier in your custom events.
+For workflows with conditional branching (e.g., express vs standard delivery), you can track progress across different branches by including an identifier in your custom events.
 
 The UI Dojo example uses a `stage` field in the event data to identify which branch is executing (e.g., `"validation"`, `"standard-processing"`, `"express-processing"`). The frontend groups events by this field to show a pipeline-style progress UI.
 

package/.docs/guides/build-your-ui/copilotkit/generative-ui.md

@@ -2,23 +2,23 @@
 
 # CopilotKit generative UI
 
-Generative UI is the family of UI paradigms enabled by agents and useful for interacting with them. CopilotKit organizes these along a single axis, the **generative UI spectrum**, which runs from author-controlled (you decide every pixel) to agent-invented (the agent owns the rendered surface). Where you sit on the axis is a trade-off between predictability and breadth.
+Generative UI describes interfaces that agents help create and that users can interact with. CopilotKit organizes these interfaces along a single axis, the **generative UI spectrum**, which runs from author-controlled (you decide every pixel) to agent-invented (the agent owns the rendered surface). Your position on the axis is a trade-off between predictability and breadth.
 
 The spectrum has three tiers:
 
 | Tier            | Who controls the surface                                                                   | Primitives                                                           |
 | --------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- |
-| **Controlled**  | You wrote the component; the agent picks which one and what data to pass.                  | Tool call rendering, state rendering, reasoning, components as tools |
-| **Declarative** | The agent emits a structured spec; the frontend composes it from a catalog you registered. | A2UI (fixed schema and dynamic)                                      |
+| **Controlled**  | You wrote the component. The agent picks which one to use and what data to pass.           | Tool call rendering, state rendering, reasoning, components as tools |
+| **Declarative** | The agent emits a structured spec. The frontend composes it from a catalog you registered. | A2UI (fixed-schema and flexible variants)                            |
 | **Open-ended**  | The UI is invented elsewhere (an MCP server) and you sandbox it.                           | MCP Apps                                                             |
 
 Each tier is a Mastra agent exposed through `registerCopilotKit()` (see [CopilotKit overview](https://mastra.ai/guides/build-your-ui/copilotkit/overview)) plus the matching CopilotKit hook on the frontend. For the full concept, see CopilotKit's [generative UI spectrum](https://www.copilotkit.ai/generative-ui-spectrum) and [generative UI overview](https://docs.copilotkit.ai/concepts/generative-ui-overview).
 
-> **Tip:** Mastra's [UI Dojo](https://ui-dojo.mastra.ai/) has working CopilotKit examples; browse the source under `src/pages/copilot-kit`.
+> **Tip:** Mastra's [UI Dojo](https://ui-dojo.mastra.ai/) has working CopilotKit examples. Browse the source under `src/pages/copilot-kit`.
 
 ## Controlled
 
-You ship a fixed set of components and the agent chooses which to render, with what data. This is the workhorse of the spectrum: predictable and brand-safe, the right tool for high-traffic surfaces. The Controlled primitives use CopilotKit's v2 API, imported from `@copilotkit/react-core/v2`.
+You provide a fixed set of components. The agent chooses which component to render and supplies its data. This predictable, brand-safe approach works well for high-traffic surfaces. The Controlled primitives use CopilotKit's v2 API, imported from `@copilotkit/react-core/v2`.
 
 ### Tool call rendering
 
@@ -32,7 +32,7 @@ export const weatherAgent = new Agent({
   id: 'weather-agent',
   name: 'Weather Agent',
   instructions: 'Use the weatherTool to fetch current weather data.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: { weatherTool },
 })
 ```
@@ -125,7 +125,7 @@ Reasoning is zero-config: when your Mastra agent runs a reasoning-capable model,
 
 ## Declarative
 
-Instead of a fixed component per tool, you register a catalog of typed building blocks and the agent assembles them into a UI tree per request. CopilotKit calls this **A2UI** (Agent-to-UI), available in a fixed-schema and a dynamic variant. It suits the long tail of secondary interactions where breadth matters more than pixel-perfection.
+Instead of a fixed component per tool, you register a catalog of typed building blocks and the agent assembles them into a UI tree per request. CopilotKit calls this **A2UI** (Agent-to-UI), which has fixed-schema and flexible variants. It suits the long tail of secondary interactions where breadth matters more than pixel-perfection.
 
 The path of least resistance is to pass your catalog to the `<CopilotKit>` provider. That single prop enables A2UI rendering and injects the A2UI tool into your agent, so no backend change is needed:
 
@@ -146,11 +146,11 @@ export default function Page() {
 }
 ```
 
-The catalog defines the primitives (their schemas) and the renderers (how each primitive displays). In the fixed-schema variant the components are pre-authored and the agent's tool only supplies data; the dynamic variant lets the agent compose the tree more freely. See CopilotKit's [A2UI documentation](https://docs.copilotkit.ai/a2a/generative-ui/a2ui).
+The catalog defines the primitives (their schemas) and the renderers (how each primitive displays). In the fixed-schema variant, the components are pre-authored and the agent's tool only supplies data. The flexible variant lets the agent compose the tree more freely. See CopilotKit's [A2UI documentation](https://docs.copilotkit.ai/a2a/generative-ui/a2ui).
 
 ## Open-ended
 
-At the far end of the spectrum, the agent owns the entire surface: the UI is invented elsewhere and sandboxed in your app. CopilotKit supports this through **MCP Apps**, where an MCP server ships UI that renders inside your application. This tier trades determinism for novelty and is the most experimental point on the spectrum.
+At the far end of the spectrum, the agent owns the entire surface: the UI is invented elsewhere and sandboxed in your app. CopilotKit supports this through **MCP Apps**, where an MCP server provides UI that renders inside your application. This tier trades determinism for novelty and is the most experimental point on the spectrum.
 
 The path of least resistance keeps the frontend untouched: your existing `<CopilotKit>` provider is enough. On the backend, point `registerCopilotKit()` at one or more MCP servers with the `mcpApps` option (it's forwarded to the CopilotKit runtime):
 

package/.docs/guides/build-your-ui/copilotkit/overview.md

@@ -2,7 +2,7 @@
 
 # Using CopilotKit
 
-[CopilotKit](https://www.copilotkit.ai/) provides React components to quickly integrate customizable AI copilots into your application. Combined with Mastra, you can build sophisticated AI apps featuring bidirectional state synchronization and interactive UIs.
+[CopilotKit](https://www.copilotkit.ai/) provides React components to quickly integrate customizable AI copilots into your application. Combined with Mastra, you can build AI apps with bidirectional state synchronization and interactive UIs.
 
 CopilotKit talks to Mastra through the [AG-UI protocol](https://docs.ag-ui.com/). The `@ag-ui/mastra` package exposes your Mastra agents as an AG-UI endpoint, and CopilotKit's React hooks and components consume it. This unlocks a spectrum of experiences on top of ordinary chat: [generative UI, human-in-the-loop, and frontend tools](https://mastra.ai/guides/build-your-ui/copilotkit/generative-ui), plus deploying the same agent to [messaging channels like Slack](https://mastra.ai/guides/build-your-ui/copilotkit/channels).
 
@@ -266,7 +266,7 @@ Your CopilotKit frontend now communicates with a standalone Mastra agent server.
 
 ## Chat UI options
 
-`CopilotChat` renders an inline, full-height chat. CopilotKit ships two other drop-in surfaces that share the same props:
+`CopilotChat` renders an inline, full-height chat. CopilotKit provides two other drop-in surfaces that share the same props:
 
 - `CopilotSidebar`: a collapsible panel docked to the side of your app.
 - `CopilotPopup`: a floating button that opens a chat window.

package/.docs/guides/build-your-ui/openui.md

@@ -131,7 +131,7 @@ Embed Mastra in your Next.js API route and connect an OpenUI `<AgentInterface />
        name: 'OpenUI Agent',
        instructions: `You are a helpful assistant. Use tools when relevant.\n\n${systemPrompt}`,
        model: {
-         id: 'openai/gpt-5.5',
+         id: 'openai/gpt-5.6-sol',
          apiKey: process.env.OPENAI_API_KEY,
        },
        tools: { getWeather },
@@ -253,7 +253,7 @@ OpenUI generates UI from a component library. The library defines which componen
 
 ### Built-in libraries
 
-`@openuidev/react-ui` ships two libraries you can use as-is:
+`@openuidev/react-ui` provides two libraries you can use as-is:
 
 - `openuiChatLibrary`: components for chat interfaces (cards, forms, tables, charts).
 - `openuiDashboardLibrary`: components for dashboards and data-heavy surfaces.

package/.docs/guides/concepts/multi-agent-systems.md

@@ -4,7 +4,7 @@
 
 A multi-agent system distributes a task across multiple agents instead of asking one agent to do everything. In Mastra, this usually means combining agents, workflows, or both so each part of the system has a clear role.
 
-The goal is to assign the right context, tools, and responsibilities to the right component. When that split is clear, a multi-agent system can be easier to reason about than one agent with a long prompt, many tools, and too many responsibilities.
+The goal is to assign the right context, tools, and responsibilities to the right component. When that split is clear, a multi-agent system can be easier to reason about than one agent burdened with a long prompt and too many tools or responsibilities.
 
 ## When to use multi-agent systems
 
@@ -34,9 +34,9 @@ In Mastra, implement this pattern by combining [agents](https://mastra.ai/docs/a
 
 A workflow pattern defines the execution path in code. Instead of asking an agent to decide what happens next, you define the sequence through steps, branches, loops, and parallel blocks.
 
-Use workflows when the task is well understood and the execution path is known in advance. The main advantage is predictability: The system is easier to debug, reason about, and audit because the structure is explicit. The tradeoff is flexibility, since workflows are less adaptive when the task changes as it unfolds.
+Use workflows when the task is well understood and the execution path is known in advance. The main advantage is predictability: The explicit structure makes the system easier to debug and audit. The tradeoff is flexibility, since workflows are less adaptive when the task changes as it unfolds.
 
-In Mastra, [workflows](https://mastra.ai/docs/workflows/overview) can implement several coordination patterns, including handoffs and councils. What makes a workflow distinct isn't which agents it calls, but that the control logic lives in the workflow itself.
+In Mastra, [workflows](https://mastra.ai/docs/workflows/overview) can implement coordination patterns such as handoffs and councils. A workflow is distinct because its control logic lives in the workflow itself, regardless of which agents it calls.
 
 ## Supervisors
 
@@ -54,7 +54,7 @@ A council pattern asks multiple agents to work on the same problem independently
 
 Use this pattern when the question is ambiguous, evaluative, or high-stakes and answer quality matters more than speed. The tradeoff is cost, since councils intentionally duplicate effort and usually take longer and use more tokens than other patterns.
 
-Mastra doesn't provide a dedicated council primitive. In Mastra, implement this pattern with [agents](https://mastra.ai/docs/agents/overview) and [workflows](https://mastra.ai/docs/workflows/overview): Run multiple agents in parallel, collect their outputs, and add a final synthesis or review step. Workflow control flow methods such as `.parallel()` provide the structure for this pattern.
+Mastra doesn't provide a dedicated council primitive. In Mastra, implement this pattern with [agents](https://mastra.ai/docs/agents/overview) and [workflows](https://mastra.ai/docs/workflows/overview): Run multiple agents in parallel and collect their outputs. Then add a final synthesis or review step. Workflow control flow methods such as `.parallel()` provide the structure for this pattern.
 
 ## Choosing a pattern
 
@@ -64,7 +64,7 @@ These patterns differ mainly in how they distribute control:
 | ----------------- | -------------------- | ------------------------------------------------ | -------------------------------------------------------- | -------------------------------------------------------------------- |
 | Handoffs          | Current specialist   | Ownership should move between specialists        | Context transfer becomes more important                  | Agents with workflows and memory                                     |
 | Workflows         | Execution graph      | The path is known in advance                     | Less adaptive when the task changes                      | [Workflows](https://mastra.ai/docs/workflows/overview)               |
-| Supervisor agents | One lead agent       | The task needs dynamic delegation                | Results depend on good coordination and clear boundaries | [Supervisor agents](https://mastra.ai/docs/agents/supervisor-agents) |
+| Supervisor agents | One lead agent       | Delegation must adapt during execution           | Results depend on good coordination and clear boundaries | [Supervisor agents](https://mastra.ai/docs/agents/supervisor-agents) |
 | Council           | Final synthesis step | The task needs multiple independent perspectives | Higher cost and latency                                  | Agents with workflow parallelism                                     |
 
 In practice, these patterns are often combined:

package/.docs/guides/concepts/streaming.md

@@ -46,7 +46,7 @@ Here are some questions to consider:
 
 ### Agent stream properties
 
-An agent stream provides access to various response properties:
+An agent stream provides access to these response properties:
 
 - **`stream.textStream`**: A readable stream that emits text chunks.
 - **`stream.text`**: Promise that resolves to the full text response.
@@ -124,13 +124,13 @@ The event structure includes `runId` and `from` at the top level, making it easi
 
 ### Workflow stream properties
 
-A workflow stream provides access to various response properties:
+A workflow stream provides access to these response properties:
 
 - **`stream.status`**: The status of the workflow run.
 - **`stream.result`**: The result of the workflow run.
 - **`stream.usage`**: The total token usage of the workflow run.
 
-Streaming from agents or workflows provides real-time visibility into either the LLM’s output or the status of a workflow run. This feedback can be passed directly to the user, or used within applications to handle workflow status more effectively, creating a smoother and more responsive experience.
+Streaming from agents or workflows provides real-time visibility into either the LLM’s output or the status of a workflow run. Pass this feedback directly to the user, or use it in an application to display workflow status as it changes.
 
 Events emitted from agents or workflows represent different stages of generation and execution, such as when a run starts, when text is produced, or when a tool is invoked.
 
@@ -193,11 +193,11 @@ Below is an example of events that may be emitted. Each event always includes a
 
 ## Writer API
 
-The `writer` API is shared by tools and workflow steps — see the Tools and Workflows docs for feature-specific examples.
+The `writer` API is shared by tools and workflow steps. See the Tools and Workflows docs for feature-specific examples.
 
 ## Agent using tool
 
-Agent streaming can be combined with tool calls, allowing tool outputs to be written directly into the agent’s streaming response. This makes it possible to surface tool activity as part of the overall interaction.
+Agent streaming can be combined with tool calls, allowing tool outputs to be written directly into the agent’s streaming response. This surfaces tool activity as part of the interaction.
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -207,14 +207,14 @@ export const testAgent = new Agent({
   id: 'test-agent',
   name: 'Test Agent',
   instructions: 'You are a weather agent.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: { testTool },
 })
 ```
 
 ### Using `context.writer`
 
-The `context.writer` object is available in a tool's `execute()` function and can be used to emit custom events, data, or values into the active stream. This enables tools to provide intermediate results or status updates while execution is still in progress.
+The `context.writer` object is available in a tool's `execute()` function and can emit custom events, data, or values into the active stream. Tools use these events to provide intermediate results or status updates during execution.
 
 > **Warning:** You must `await` the call to `writer.write()` or else you will lock the stream and get a `WritableStream is locked` error.
 
@@ -274,7 +274,7 @@ export const testTool = createTool({
 
 ### Transient data chunks
 
-By default, `data-*` chunks emitted with `writer.custom()` are persisted to storage as part of the message history. For chunks that are only needed during live streaming — such as progress updates or verbose log output — set `transient: true` to skip storage persistence. Transient chunks are still streamed to the client in real time but aren't saved to the database.
+By default, `data-*` chunks emitted with `writer.custom()` are persisted to storage as part of the message history. For chunks that are only needed during live streaming, such as progress updates or verbose log output, set `transient: true` to skip storage persistence. Transient chunks are still streamed to the client in real time but aren't saved to the database.
 
 ```typescript
 await context?.writer?.custom({
@@ -284,11 +284,11 @@ await context?.writer?.custom({
 })
 ```
 
-Use transient chunks when the data is large or high-frequency and only relevant during the live session. After a page refresh, transient chunks are no longer available — only the tool's return value and any non-transient chunks are loaded from storage.
+Use transient chunks when the data is large or high-frequency and only relevant during the live session. After a page refresh, transient chunks are no longer available. Only the tool's return value and any non-transient chunks are loaded from storage.
 
 ## Using the `writer` argument
 
-The `writer` argument is passed to a workflow step's `execute` function and can be used to emit custom events, data, or values into the active stream. This enables workflow steps to provide intermediate results or status updates while execution is still in progress.
+The `writer` argument is passed to a workflow step's `execute` function and can emit custom events, data, or values into the active stream. Workflow steps use these events to provide intermediate results or status updates during execution.
 
 > **Warning:** You must `await` the call to `writer.write(...)` or else you will lock the stream and get a `WritableStream is locked` error.
 

package/.docs/guides/deployment/amazon-ec2.md

@@ -2,7 +2,7 @@
 
 # Deploy Mastra to Amazon EC2
 
-Deploy your Mastra server to Amazon EC2. This gives you full control over your server environment and supports long-running agents and workflows.
+Deploy your Mastra server to Amazon EC2. The server runs on infrastructure you manage and can support long-running agents and workflows.
 
 > **Info:** This guide covers deploying the [Mastra server](https://mastra.ai/docs/server/mastra-server). If you're using a [server adapter](https://mastra.ai/docs/server/server-adapters) or [web framework](https://mastra.ai/docs/deployment/web-framework), deploy the way you normally would for that framework.
 

package/.docs/guides/deployment/aws-lambda.md

@@ -12,7 +12,7 @@ You'll need:
 
 - A [Mastra application](https://mastra.ai/guides/getting-started/quickstart)
 - An [AWS account](https://aws.amazon.com/) with permissions for Lambda, ECR, and IAM
-- **[AWS CLI](https://aws.amazon.com/cli/)** installed — run `aws configure` to authenticate
+- **[AWS CLI](https://aws.amazon.com/cli/)** installed: Run `aws configure` to authenticate
 - **[Docker](https://www.docker.com/)** installed and running
 
 > **Warning:** On AWS Lambda, the filesystem is ephemeral, so any local database file will be lost between invocations. If you're using [LibSQLStore](https://mastra.ai/reference/storage/libsql) with a local file, configure it to use a remote LibSQL-compatible database (for example, [Turso](https://turso.tech/)) instead.

package/.docs/guides/deployment/azure-app-services.md

@@ -71,7 +71,7 @@ In these steps, you'll connect your Azure App Service to your GitHub repository
    run: (cd .mastra/output && zip ../../release.zip -r .)
    ```
 
-   This ensures only the build outputs from `.mastra/output` are included in the deployment package.
+   The deployment package then contains only the build outputs from `.mastra/output`.
 
 5. Commit and push your workflow modifications. The build will be automatically triggered in the **Deployment Center** in your Azure dashboard. Monitor the deployment progress until it completes successfully.
 

package/.docs/guides/deployment/cloudflare.md

@@ -56,7 +56,7 @@ export const mastra = new Mastra({
 })
 ```
 
-In order to test your Cloudflare Worker locally, also install the [`wrangler` CLI](https://developers.cloudflare.com/workers/wrangler/install-and-update/):
+To test your Cloudflare Worker locally, also install the [`wrangler` CLI](https://developers.cloudflare.com/workers/wrangler/install-and-update/):
 
 **npm**:
 

package/.docs/guides/deployment/inngest.md

@@ -8,11 +8,11 @@ For a complete example with advanced flow control features, see the [Inngest wor
 
 ## How Inngest works with Mastra
 
-Inngest and Mastra integrate by aligning their workflow models: Inngest organizes logic into functions composed of steps, and Mastra workflows defined using `createWorkflow()` and `createStep()` map directly onto this paradigm. Each Mastra workflow becomes an Inngest function with a unique identifier, and each step within the workflow maps to an Inngest step.
+Inngest and Mastra integrate by aligning their workflow models: Inngest organizes logic into functions composed of steps, and Mastra workflows defined using `createWorkflow()` and `createStep()` map directly onto this structure. Each Mastra workflow becomes an Inngest function with a unique identifier, and each step within the workflow maps to an Inngest step.
 
 The `serve()` function bridges the two systems by registering Mastra workflows as Inngest functions and setting up the necessary event handlers for execution and monitoring.
 
-When an event triggers a workflow, Inngest executes it step by step, memoizing each step's result. This means if a workflow is retried or resumed, completed steps are skipped, ensuring efficient and reliable execution. Control flow primitives in Mastra, such as loops, conditionals, and nested workflows are seamlessly translated into the same Inngest's function/step model, preserving advanced workflow features like composition, branching, and suspension.
+When an event triggers a workflow, Inngest executes it step by step and memoizes each result. On retry or resume, Inngest skips completed steps based on those saved results. Mastra control flow primitives, such as loops, conditionals, and nested workflows, map to the same Inngest function and step model while preserving composition, branching, and suspension.
 
 Real-time monitoring, suspend/resume, and step-level observability are enabled via Inngest's publish-subscribe system and dashboard. As each step executes, its state and output are tracked using Mastra storage and can be resumed as needed.
 
@@ -194,7 +194,7 @@ export const mastra = new Mastra({
 
 3. Open the Inngest Dashboard at <http://localhost:8288> and go to the **Apps** section in the sidebar to verify your Mastra workflow is registered
 
-4. Invoke the workflow by going to **Functions**, selecting your workflow, and selecting **Invoke** with the following input:
+4. In **Functions**, open your workflow. Select **Invoke** and provide the following input:
 
    ```json
    {
@@ -256,7 +256,7 @@ Before you begin, make sure you have:
 
    > **Warning:** Inngest's auto-discover convention assumes `/api/inngest`. Because this guide uses `/inngest/api`, set the **URL** field on the Inngest app to your deployed origin plus `/inngest/api` (for example `https://your-app.vercel.app/inngest/api`). If you leave it on the default, the Inngest dashboard won't find your app's functions.
 
-6. Invoke the workflow by going to **Functions**, selecting `workflow.increment-workflow`, selecting **All actions** > **Invoke**, and providing the following input:
+6. In **Functions**, open `workflow.increment-workflow`. Select **All actions** > **Invoke** and provide the following input:
 
    ```json
    {
@@ -496,7 +496,7 @@ When migrating an existing production app from `serve()` to `connect()`, test th
 - `functions`: Optional array of additional Inngest functions to register alongside Mastra workflows.
 - `instanceId`: Stable identifier for the worker, shown in the Inngest dashboard. Defaults to the machine hostname.
 - `maxWorkerConcurrency`: Maximum number of steps the worker runs at a time. Defaults to unlimited.
-- `registerOptions`: Forwarded to Inngest during app registration (for example `signingKey`). When a field is set both here and at the top level, `registerOptions` wins — this matches the behavior of `serve()`.
+- `registerOptions`: Forwarded to Inngest during app registration (for example `signingKey`). When a field is set both here and at the top level, `registerOptions` wins. This matches the behavior of `serve()`.
 
 `connect()` returns Inngest's `WorkerConnection`. The Inngest SDK handles `SIGINT` and `SIGTERM` by default. Store the returned connection and call `.close()` only when your worker needs custom shutdown control.
 
@@ -663,7 +663,7 @@ All flow control options are optional. If not specified, workflows run with Inng
 
 ## Cron scheduling
 
-Inngest workflows can be automatically triggered on a schedule using cron expressions. This allows you to run workflows at regular intervals, such as daily reports, hourly data syncs, or maintenance tasks.
+Use cron expressions to trigger Inngest workflows on a schedule. Common uses include daily reports and hourly data syncs, as well as maintenance tasks.
 
 ### Basic cron scheduling
 

package/.docs/guides/deployment/kubernetes.md

@@ -99,7 +99,7 @@ const agent = new Agent({
   id: 'assistant',
   name: 'Assistant',
   instructions: 'You are a helpful assistant.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
 })
 
 export const durableAssistant = createDurableAgent({ agent })

package/.docs/guides/deployment/mastra-workers.md

@@ -0,0 +1,232 @@
+> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
+
+# Deploy Mastra workers
+
+Run [Mastra workers](https://mastra.ai/docs/deployment/workers) as separate processes so you can scale orchestration, scheduling, and background tasks independently from the API. This guide walks through a fully split deployment using Docker Compose.
+
+> **Info:** This guide covers splitting workers into their own containers. If you only need workers to run in-process alongside the API, see [Workers](https://mastra.ai/docs/deployment/workers). No extra setup is required.
+
+## Before you begin
+
+You'll need:
+
+- A [Mastra application](https://mastra.ai/guides/getting-started/quickstart)
+- [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/)
+- A distributed PubSub backend: [Redis](https://redis.io/) for [`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams), or a [Google Cloud](https://cloud.google.com/) project for [`GoogleCloudPubSub`](https://mastra.ai/reference/pubsub/google-cloud-pubsub)
+- A shared database reachable from every container. See [supported storage backends](https://mastra.ai/reference/workers/overview) for the full list.
+
+> **Warning:** The default in-memory PubSub can't deliver events across processes. You must configure a distributed PubSub backend before splitting workers into separate containers.
+
+## Configure shared infrastructure
+
+Point the `Mastra` instance at a distributed PubSub backend and a shared database. Use environment variables so the same image runs in every container.
+
+**Redis Streams + PostgreSQL**:
+
+```typescript
+import { Mastra } from '@mastra/core/mastra'
+import { RedisStreamsPubSub } from '@mastra/redis-streams'
+import { PostgresStore } from '@mastra/pg'
+
+export const mastra = new Mastra({
+  storage: new PostgresStore({
+    connectionString: process.env.DATABASE_URL!,
+  }),
+  pubsub: new RedisStreamsPubSub({
+    url: process.env.REDIS_URL!,
+  }),
+})
+```
+
+**Google Cloud Pub/Sub + LibSQL**:
+
+```typescript
+import { Mastra } from '@mastra/core/mastra'
+import { GoogleCloudPubSub } from '@mastra/google-cloud-pubsub'
+import { LibSQLStore } from '@mastra/libsql'
+
+export const mastra = new Mastra({
+  storage: new LibSQLStore({
+    url: process.env.DATABASE_URL!,
+  }),
+  pubsub: new GoogleCloudPubSub({
+    projectId: process.env.GCP_PROJECT_ID!,
+  }),
+})
+```
+
+Any [supported storage backend](https://mastra.ai/reference/workers/overview) works. Swap the storage adapter for your preferred database.
+
+## Deploy
+
+1. Build your Mastra application. The output runs in every container.
+
+   ```bash
+   mastra build
+   ```
+
+   This produces a self-contained `.mastra/output/` directory. See [Deploy a Mastra server](https://mastra.ai/docs/deployment/mastra-server) for details on the build output.
+
+2. Create a Dockerfile that copies the pre-built output and installs production dependencies:
+
+   ```dockerfile
+   FROM node:22-alpine
+
+   WORKDIR /app
+
+   COPY .mastra/output/package.json .mastra/output/.npmrc* ./
+   RUN npm install --omit=dev
+
+   COPY .mastra/output/ .
+
+   EXPOSE 4111
+   CMD ["node", "index.mjs"]
+   ```
+
+3. Create a `docker-compose.yml` that runs the fully split topology. The file defines six services: a database, a PubSub backend, the API server, and three workers. Each worker container runs the same image with a different `MASTRA_WORKERS` value to control which worker starts.
+
+   The API container sets `MASTRA_WORKERS: "false"` to disable all event processing. The orchestration worker sets `MASTRA_STEP_EXECUTION_URL` to point step execution requests at the API's internal URL. See [step execution URL](#step-execution-url) for details.
+
+   ```yaml
+   services:
+     postgres:
+       image: postgres:16-alpine
+       environment:
+         POSTGRES_USER: mastra
+         POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
+         POSTGRES_DB: mastra
+       ports:
+         - '5432:5432'
+       volumes:
+         - pgdata:/var/lib/postgresql/data
+       healthcheck:
+         test: ['CMD-SHELL', 'pg_isready -U mastra']
+         interval: 5s
+         timeout: 3s
+         retries: 5
+
+     redis:
+       image: redis:7-alpine
+       ports:
+         - '6379:6379'
+       healthcheck:
+         test: ['CMD', 'redis-cli', 'ping']
+         interval: 5s
+         timeout: 3s
+         retries: 5
+
+     api:
+       build: ./app
+       ports:
+         - '4111:4111'
+       environment:
+         DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+         REDIS_URL: redis://redis:6379
+         MASTRA_WORKERS: 'false'
+       depends_on:
+         postgres:
+           condition: service_healthy
+         redis:
+           condition: service_healthy
+       healthcheck:
+         test: ['CMD', 'wget', '-qO-', 'http://localhost:4111/api/agents']
+         interval: 5s
+         timeout: 3s
+         retries: 5
+
+     orchestration-worker:
+       build: ./app
+       environment:
+         DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+         REDIS_URL: redis://redis:6379
+         MASTRA_WORKERS: orchestration
+         MASTRA_STEP_EXECUTION_URL: http://api:4111/api
+       depends_on:
+         api:
+           condition: service_healthy
+
+     scheduler-worker:
+       build: ./app
+       environment:
+         DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+         REDIS_URL: redis://redis:6379
+         MASTRA_WORKERS: scheduler
+       depends_on:
+         api:
+           condition: service_healthy
+
+     background-task-worker:
+       build: ./app
+       environment:
+         DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+         REDIS_URL: redis://redis:6379
+         MASTRA_WORKERS: backgroundTasks
+       depends_on:
+         api:
+           condition: service_healthy
+
+   volumes:
+     pgdata:
+   ```
+
+   Create a `.env` file next to your `docker-compose.yml`:
+
+   ```bash
+   POSTGRES_PASSWORD=your-secure-password
+   ```
+
+   > **Note:** Remember to set any other environment variables your application needs (e.g., your [model provider](https://mastra.ai/models/providers) API key).
+
+4. Start the stack and verify the API responds:
+
+   ```bash
+   docker compose up -d
+   docker compose ps
+   curl http://localhost:4111/api/agents
+   ```
+
+## Step execution URL
+
+In a fully split deployment, the orchestration worker runs in a separate container from the API. When it processes a workflow event, it delegates step execution to the API over HTTP.
+
+Set `MASTRA_STEP_EXECUTION_URL` to the API's internal URL, including the `/api` prefix:
+
+```bash
+MASTRA_STEP_EXECUTION_URL=http://api:4111/api
+```
+
+The orchestration worker sends a `POST` request to `${MASTRA_STEP_EXECUTION_URL}/workflows/:workflowId/runs/:runId/steps/execute` for each step. The API resolves the workflow and executes the step locally.
+
+Without this variable, the orchestration worker attempts to execute steps in-process. That works when the worker runs alongside the API, but fails in split deployments where the worker doesn't have access to the full Mastra runtime.
+
+## Scaling
+
+The orchestration and background task workers are safe to scale horizontally. PubSub consumer groups distribute events across instances, so each event is processed once:
+
+```bash
+docker compose up -d --scale orchestration-worker=3
+docker compose up -d --scale background-task-worker=2
+```
+
+The API can also scale horizontally behind a load balancer.
+
+**Don't scale the scheduler worker.** Run exactly one instance. Multiple schedulers polling the same storage fire duplicate events for the same schedule.
+
+## Crash recovery
+
+Workers recover from crashes because the distributed PubSub backend persists unacknowledged events:
+
+- **Orchestration worker**: Pending events stay in the PubSub backend. When the worker restarts, it picks up where it left off.
+- **Scheduler worker**: No events are missed permanently. The scheduler computes the next fire time from the current time on restart, not from where it left off.
+- **API during step execution**: The orchestration worker's HTTP request fails. The event is nacked and redelivered on the next attempt.
+
+> **Warning:** If the API crashes while a step is already executing (e.g., mid-sleep), that step's work is lost. The workflow run may remain stuck in a `running` state. Mastra doesn't yet have automatic timeout-based recovery for this scenario.
+
+## Related
+
+- [Workers](https://mastra.ai/docs/deployment/workers): What workers are and when to use them
+- [Worker authentication](https://mastra.ai/docs/server/auth/workers): Secure worker-to-API communication
+- [Workers reference](https://mastra.ai/reference/workers/overview): Configuration details for all worker types
+- [CLI reference](https://mastra.ai/reference/cli/mastra): `mastra worker build` and `mastra worker start`
+- [PubSub](https://mastra.ai/docs/server/pubsub): Event delivery backends
+- [Deploy a Mastra server](https://mastra.ai/docs/deployment/mastra-server): Build output and server configuration

package/.docs/guides/deployment/temporal.md

@@ -171,7 +171,7 @@ await worker.run()
 
 2. Open the Temporal UI at <http://localhost:8080> to inspect namespaces, workflows, and activities.
 
-3. Start the worker. In a new terminal, run:
+3. In a new terminal, start the worker by running:
 
    ```bash
    npx tsx src/mastra/worker.ts

package/.docs/guides/deployment/vercel.md

@@ -84,7 +84,7 @@ export const mastra = new Mastra({
 })
 ```
 
-After deploying, Studio is available at the root URL (`https://<your-project>.vercel.app/`) and the API remains at `/api/*`. Studio automatically connects to the API on the same origin — no additional environment variables are needed.
+After deploying, Studio is available at the root URL (`https://<your-project>.vercel.app/`) and the API remains at `/api/*`. Studio automatically connects to the API on the same origin, so you don't need additional environment variables.
 
 > **Warning:** Once Studio is connected to your Mastra server, it has full access to your agents, workflows, and tools. Be sure to secure it properly in production (e.g. behind authentication, VPN, etc.) to prevent unauthorized access.