@mastra/mcp-docs-server 1.1.8 → 1.1.9-alpha.1

package/.docs/docs/server/auth/jwt.md

@@ -1,4 +1,4 @@
-# MastraJwtAuth Class
+# MastraJwtAuth class
 
 The `MastraJwtAuth` class provides a lightweight authentication mechanism for Mastra using JSON Web Tokens (JWTs). It verifies incoming requests based on a shared secret and integrates with the Mastra server using the `auth` option.
 

package/.docs/docs/server/auth/simple-auth.md

@@ -1,8 +1,8 @@
-# SimpleAuth Class
+# SimpleAuth class
 
-The `SimpleAuth` class provides token-based authentication using a simple token-to-user mapping. It's included in `@mastra/core/server` and is useful for development, testing, and simple API key authentication scenarios.
+The `SimpleAuth` class provides token-based authentication using a basic token-to-user mapping. It's included in `@mastra/core/server` and is useful for development, testing, and basic API key authentication scenarios.
 
-## Use Cases
+## Use cases
 
 - Local development and testing
 - Simple API key authentication
@@ -17,7 +17,7 @@ SimpleAuth is included in `@mastra/core`, no additional packages required.
 import { SimpleAuth } from '@mastra/core/server'
 ```
 
-## Usage Example
+## Usage example
 
 ```typescript
 import { Mastra } from '@mastra/core'
@@ -50,7 +50,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## Configuration Options
+## Configuration options
 
 | Option          | Type                         | Required | Description                            |
 | --------------- | ---------------------------- | -------- | -------------------------------------- |
@@ -79,7 +79,7 @@ new SimpleAuth({
 })
 ```
 
-## Making Authenticated Requests
+## Making authenticated requests
 
 Include your token in the `Authorization` header:
 
@@ -99,7 +99,7 @@ curl -X POST http://localhost:4111/api/agents/myAgent/generate \
   -d '{"messages": "Hello"}'
 ```
 
-## Custom Authorization
+## Custom authorization
 
 Add role-based or custom authorization logic:
 
@@ -119,7 +119,7 @@ new SimpleAuth<User>({
 })
 ```
 
-## Environment Variables
+## Environment variables
 
 For production-like setups, load tokens from environment variables:
 
@@ -144,7 +144,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## With MastraClient
+## With `MastraClient`
 
 Configure the client with your token:
 

package/.docs/docs/server/auth/supabase.md

@@ -1,4 +1,4 @@
-# MastraAuthSupabase Class
+# MastraAuthSupabase class
 
 The `MastraAuthSupabase` class provides authentication for Mastra using Supabase Auth. It verifies incoming requests using Supabase's authentication system and integrates with the Mastra server using the `auth` option.
 

package/.docs/docs/server/auth/workos.md

@@ -1,4 +1,4 @@
-# MastraAuthWorkos Class
+# MastraAuthWorkos class
 
 The `MastraAuthWorkos` class provides authentication for Mastra using WorkOS. It verifies incoming requests using WorkOS access tokens and integrates with the Mastra server using the `auth` option.
 

package/.docs/docs/server/auth.md

@@ -1,8 +1,8 @@
-# Auth Overview
+# Auth overview
 
 Mastra lets you choose how you handle authentication, so you can secure access to your application's endpoints using the identity system that fits your stack.
 
-You can start with simple shared secret JWT authentication and switch to providers like Supabase, Firebase Auth, Auth0, Clerk, or WorkOS when you need more advanced identity features.
+You can start with basic shared secret JWT authentication and switch to providers like Supabase, Firebase Auth, Auth0, Clerk, or WorkOS when you need more advanced identity features.
 
 ## Default behavior
 

package/.docs/docs/server/custom-adapters.md

@@ -1,4 +1,4 @@
-# Custom Adapters
+# Custom adapters
 
 Create a custom adapter when you need to run Mastra with a framework other than Hono or Express. This might be necessary if you have specific request/response handling requirements that `@mastra/hono` and `@mastra/express` don't support.
 
@@ -38,7 +38,7 @@ These type parameters ensure type safety throughout your adapter implementation
 
 You must implement these six abstract methods. Each handles a specific part of the request lifecycle, from attaching context to sending responses.
 
-### registerContextMiddleware()
+### `registerContextMiddleware()`
 
 This method runs first and attaches Mastra context to every incoming request. Route handlers need access to the Mastra instance, tools, and other context to function. How you attach this context depends on your framework — Express uses `res.locals`, Hono uses `c.set()`, and other frameworks have their own patterns.
 
@@ -65,7 +65,7 @@ Context to attach:
 | `abortSignal`    | `AbortSignal`          | Request cancellation signal      |
 | `taskStore`      | `InMemoryTaskStore`    | A2A task storage (if configured) |
 
-### registerAuthMiddleware()
+### `registerAuthMiddleware()`
 
 Register authentication and authorization middleware. This method should check if authentication is configured on the Mastra instance and skip registration entirely if not. When auth is configured, you'll typically register two middleware functions: one for authentication (validating tokens and setting the user) and one for authorization (checking if the user can access the requested resource).
 
@@ -101,7 +101,7 @@ registerAuthMiddleware(): void {
 }
 ```
 
-### registerRoute()
+### `registerRoute()`
 
 Register a single route with your framework. This method is called once for each Mastra route during initialization. It receives a `ServerRoute` object containing the path, HTTP method, handler function, and Zod schemas for validation. Your implementation should wire this up to your framework's routing system.
 
@@ -148,7 +148,7 @@ async registerRoute(
 }
 ```
 
-### getParams()
+### `getParams()`
 
 Extract URL parameters, query parameters, and request body from the incoming request. Different frameworks expose these values in different ways—Express uses `req.params`, `req.query`, and `req.body`, while other frameworks may use different property names or require method calls. This method normalizes the extraction for your framework.
 
@@ -172,7 +172,7 @@ async getParams(
 }
 ```
 
-### sendResponse()
+### `sendResponse()`
 
 Send the response back to the client based on the route's response type. Mastra routes can return different response types: JSON for most API responses, streams for agent generation, and special types for MCP transports. Your implementation should handle each type appropriately for your framework.
 
@@ -207,7 +207,7 @@ async sendResponse(
 }
 ```
 
-### stream()
+### `stream()`
 
 Handle streaming responses for agent generation. When an agent generates a response, it produces a stream of chunks that should be sent to the client as they become available. This method reads from the stream, optionally applies redaction to hide sensitive data, and writes chunks to the response in the appropriate format (SSE or newline-delimited JSON).
 

package/.docs/docs/server/custom-api-routes.md

@@ -1,4 +1,4 @@
-# Custom API Routes
+# Custom API routes
 
 By default, Mastra automatically exposes registered agents and workflows via its server. For additional behavior you can define your own HTTP routes.
 
@@ -61,7 +61,7 @@ export const mastra = new Mastra({
 })
 ```
 
-## OpenAPI Documentation
+## OpenAPI documentation
 
 Custom routes can include OpenAPI metadata to appear in the Swagger UI alongside Mastra server routes. Pass an `openapi` option with standard OpenAPI operation fields.
 

package/.docs/docs/server/mastra-client.md

@@ -1,6 +1,6 @@
-# Mastra Client SDK
+# Mastra client SDK
 
-The Mastra Client SDK provides a simple and type-safe interface for interacting with your [Mastra Server](https://mastra.ai/docs/server/mastra-server) from your client environment.
+The Mastra Client SDK provides a concise and type-safe interface for interacting with your [Mastra Server](https://mastra.ai/docs/server/mastra-server) from your client environment.
 
 ## Prerequisites
 

package/.docs/docs/server/mastra-server.md

@@ -1,4 +1,4 @@
-# Server Overview
+# Server overview
 
 Mastra runs as an HTTP server that exposes your agents, workflows, and other functionality as API endpoints. The server handles request routing, middleware execution, authentication, and streaming responses.
 
@@ -51,7 +51,7 @@ This behavior is only configurable by using [server adapters](https://mastra.ai/
 
 ## TypeScript configuration
 
-Mastra requires `module` and `moduleResolution` settings compatible with modern Node.js. Legacy options like `CommonJS` or `node` are not supported.
+Mastra requires `module` and `moduleResolution` settings compatible with modern Node.js. Legacy options like `CommonJS` or `node` aren't supported.
 
 ```json
 {

package/.docs/docs/server/request-context.md

@@ -1,4 +1,4 @@
-# Request Context
+# Request context
 
 Agents, tools, and workflows can all accept `RequestContext` as a parameter, making request-specific values available to the underlying primitives.
 
@@ -6,7 +6,7 @@ Agents, tools, and workflows can all accept `RequestContext` as a parameter, mak
 
 Use `RequestContext` when a primitive's behavior should change based on runtime conditions. For example, you might switch models or storage backends based on user attributes, or adjust instructions and tool selection based on language.
 
-> **Note:** **Note:** `RequestContext` is primarily used for passing data into specific requests. It's distinct from agent memory, which handles conversation history and state persistence across multiple calls.
+> **Note:** `RequestContext` is primarily used for passing data into specific requests. It's distinct from agent memory, which handles conversation history and state persistence across multiple calls.
 
 ## Setting values
 

package/.docs/docs/server/server-adapters.md

@@ -1,4 +1,4 @@
-# Server Adapters
+# Server adapters
 
 Server adapters let you run Mastra with your own HTTP server instead of the Hono server generated by `mastra build`. They provide more control over the server setup, including custom middleware ordering, authentication, logging, and deployment configuration. You can still integrate Mastra into any Node.js application without changing how agents or workflows execute.
 
@@ -389,7 +389,7 @@ const server = new MastraServer({
 })
 ```
 
-With this prefix, Mastra routes become `/api/v2/agents`, `/api/v2/workflows`, etc. Custom routes you add directly to the app are not affected by this prefix.
+With this prefix, Mastra routes become `/api/v2/agents`, `/api/v2/workflows`, etc. Custom routes you add directly to the app aren't affected by this prefix.
 
 ## OpenAPI spec
 
@@ -487,7 +487,7 @@ The adapter reads these settings from `mastra.getServer()`:
 
 ### Adapter constructor only
 
-These options are passed directly to the adapter constructor and are not read from the Mastra config:
+These options are passed directly to the adapter constructor and aren't read from the Mastra config:
 
 | Option                  | Description                                                                 |
 | ----------------------- | --------------------------------------------------------------------------- |

package/.docs/docs/streaming/events.md

@@ -1,4 +1,4 @@
-# Streaming Events
+# Streaming events
 
 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.
 
@@ -143,7 +143,7 @@ Each progress event includes:
 - **`id`**: The step ID of the foreach step
 - **`completedCount`**: Number of iterations completed so far
 - **`totalCount`**: Total number of iterations
-- **`currentIndex`**: Index of the iteration that just completed
+- **`currentIndex`**: Index of the iteration that completed
 - **`iterationStatus`**: Status of the iteration (`success`, `failed`, or `suspended`)
 - **`iterationOutput`**: Output of the iteration (when successful)
 

package/.docs/docs/streaming/overview.md

@@ -1,4 +1,4 @@
-# Streaming Overview
+# Streaming overview
 
 Mastra supports real-time, incremental responses from agents and workflows, allowing users to see output as it’s generated instead of waiting for completion. This is useful for chat, long-form content, multi-step workflows, or any scenario where immediate feedback matters.
 
@@ -11,7 +11,7 @@ Mastra's streaming API adapts based on your model version:
 
 ## Streaming with agents
 
-You can pass a single string for simple prompts, an array of strings when providing multiple pieces of context, or an array of message objects with `role` and `content` for precise control over roles and conversational flows.
+You can pass a single string for basic prompts, an array of strings when providing multiple pieces of context, or an array of message objects with `role` and `content` for precise control over roles and conversational flows.
 
 ### Using `Agent.stream()`
 

package/.docs/docs/streaming/tool-streaming.md

@@ -5,7 +5,7 @@ Tool streaming in Mastra enables tools to send incremental results while they ru
 Streams can be written to in two main ways:
 
 - **From within a tool**: every tool receives a `context.writer` object, which is a writable stream you can use to push updates as execution progresses.
-- **From an agent stream**: you can also pipe an agent's `stream` output directly into a tool's writer, making it easy to chain agent responses into tool results without extra glue code.
+- **From an agent stream**: you can also pipe an agent's `stream` output directly into a tool's writer, making it convenient to chain agent responses into tool results without extra glue code.
 
 By combining writable tool streams with agent streaming, you gain fine grained control over how intermediate results flow through your system and into the user experience.
 
@@ -33,59 +33,73 @@ The `context.writer` object is available in a tool's `execute()` function and ca
 > **Warning:** You must `await` the call to `writer.write()` or else you will lock the stream and get a `WritableStream is locked` error.
 
 ```typescript
-import { createTool } from "@mastra/core/tools";
+import { createTool } from '@mastra/core/tools'
 
 export const testTool = createTool({
   execute: async (inputData, context) => {
-    const { value } = inputData;
+    const { value } = inputData
 
     await context?.writer?.write({
-      type: "custom-event",
-      status: "pending"
-    });
+      type: 'custom-event',
+      status: 'pending',
+    })
 
-    const response = await fetch(...);
+    const response = await fetch()
 
     await context?.writer?.write({
-      type: "custom-event",
-      status: "success"
-    });
+      type: 'custom-event',
+      status: 'success',
+    })
 
     return {
-      value: ""
-    };
-  }
-});
+      value: '',
+    }
+  },
+})
 ```
 
-You can also use `writer.custom()` if you want to emit top level stream chunks, This useful and relevant when integrating with UI Frameworks
+You can also use `writer.custom()` to emit top-level stream chunks. This is useful when integrating with UI frameworks.
 
 ```typescript
-import { createTool } from "@mastra/core/tools";
+import { createTool } from '@mastra/core/tools'
 
 export const testTool = createTool({
   execute: async (inputData, context) => {
-    const { value } = inputData;
+    const { value } = inputData
 
-   await context?.writer?.custom({
-      type: "data-tool-progress",
-      status: "pending"
-    });
+    await context?.writer?.custom({
+      type: 'data-tool-progress',
+      status: 'pending',
+    })
 
-    const response = await fetch(...);
+    const response = await fetch()
 
-   await context?.writer?.custom({
-      type: "data-tool-progress",
-      status: "success"
-    });
+    await context?.writer?.custom({
+      type: 'data-tool-progress',
+      status: 'success',
+    })
 
     return {
-      value: ""
-    };
-  }
-});
+      value: '',
+    }
+  },
+})
+```
+
+### 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.
+
+```typescript
+await context?.writer?.custom({
+  type: 'data-build-log',
+  data: { line: 'Compiling module 3 of 12...' },
+  transient: true,
+})
 ```
 
+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.
+
 ### Inspecting 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 tool-specific data.
@@ -100,11 +114,11 @@ for await (const chunk of stream) {
 }
 ```
 
-## Tool Lifecycle Hooks
+## Tool lifecycle hooks
 
 Tools support lifecycle hooks that allow you to monitor different stages of tool execution during streaming. These hooks are particularly useful for logging or analytics.
 
-### Example: Using onInputAvailable and onOutput
+### Example: Using `onInputAvailable` and `onOutput`
 
 ```typescript
 import { createTool } from '@mastra/core/tools'

package/.docs/docs/streaming/workflow-streaming.md

@@ -5,7 +5,7 @@ Workflow streaming in Mastra enables workflows to send incremental results while
 Streams can be written to in two main ways:
 
 - **From within a workflow step**: every workflow step receives a `writer` argument, which is a writable stream you can use to push updates as execution progresses.
-- **From an agent stream**: you can also pipe an agent's `stream` output directly into a workflow step's writer, making it easy to chain agent responses into workflow results without extra glue code.
+- **From an agent stream**: you can also pipe an agent's `stream` output directly into a workflow step's writer, making it convenient to chain agent responses into workflow results without extra glue code.
 
 By combining writable workflow streams with agent streaming, you gain fine-grained control over how intermediate results flow through your system and into the user experience.
 

package/.docs/docs/voice/overview.md

@@ -2,7 +2,7 @@
 
 Mastra's Voice system provides a unified interface for voice interactions, enabling text-to-speech (TTS), speech-to-text (STT), and real-time speech-to-speech (STS) capabilities in your applications.
 
-## Adding Voice to Agents
+## Adding voice to agents
 
 To learn how to integrate voice capabilities into your agents, check out the [Adding Voice to Agents](https://mastra.ai/docs/agents/adding-voice) documentation. This section covers how to use both single and multiple voice providers, as well as real-time interactions.
 
@@ -588,7 +588,7 @@ await voiceAgent.voice.send(micStream)
 
 Visit the [Google Gemini Live Reference](https://mastra.ai/reference/voice/google-gemini-live) for more information on the Google Gemini Live voice provider.
 
-## Voice Configuration
+## Voice configuration
 
 Each voice provider can be configured with different models and options. Below are the detailed configuration options for all supported providers:
 
@@ -945,7 +945,7 @@ const voice = new CompositeVoice({
 
 For more information on the CompositeVoice, refer to the [CompositeVoice Reference](https://mastra.ai/reference/voice/composite-voice).
 
-## More Resources
+## More resources
 
 - [CompositeVoice](https://mastra.ai/reference/voice/composite-voice)
 - [MastraVoice](https://mastra.ai/reference/voice/mastra-voice)

package/.docs/docs/voice/speech-to-speech.md

@@ -1,4 +1,4 @@
-# Speech-to-Speech Capabilities in Mastra
+# Speech-to-Speech capabilities in Mastra
 
 ## Introduction
 

package/.docs/docs/voice/speech-to-text.md

@@ -24,7 +24,7 @@ const voice = new OpenAIVoice({
 const voice = new OpenAIVoice()
 ```
 
-## Available Providers
+## Available providers
 
 Mastra supports several Speech-to-Text providers, each with their own capabilities and strengths:
 
@@ -42,7 +42,7 @@ Each provider is implemented as a separate package that you can install as neede
 pnpm add @mastra/voice-openai@latest  # Example for OpenAI
 ```
 
-## Using the Listen Method
+## Using the listen method
 
 The primary method for STT is the `listen()` method, which converts spoken audio into text. Here's how to use it:
 

package/.docs/docs/voice/text-to-speech.md

@@ -29,7 +29,7 @@ const voice = new OpenAIVoice({
 const voice = new OpenAIVoice()
 ```
 
-## Available Providers
+## Available providers
 
 Mastra supports a wide range of Text-to-Speech providers, each with their own unique capabilities and voice options. You can choose the provider that best suits your application's needs:
 
@@ -50,7 +50,7 @@ Each provider is implemented as a separate package that you can install as neede
 pnpm add @mastra/voice-openai@latest  # Example for OpenAI
 ```
 
-## Using the Speak Method
+## Using the speak method
 
 The primary method for TTS is the `speak()` method, which converts text to speech. This method can accept options that allows you to specify the speaker and other provider-specific options. Here's how to use it:
 

package/.docs/docs/workflows/agents-and-tools.md

@@ -1,4 +1,4 @@
-# Agents and Tools
+# Agents and tools
 
 Workflow steps can call agents to leverage LLM reasoning or call tools for type-safe logic. You can either invoke them from within a step's `execute` function or compose them directly as steps using `createStep()`.
 

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

@@ -1,4 +1,4 @@
-# Control Flow
+# 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.
 
@@ -166,6 +166,48 @@ export const testWorkflow = createWorkflow({
 - The next step receives an object containing all parallel step outputs
 - You must define the `inputSchema` of the following step to match this structure
 
+### 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:
+
+```typescript
+const resilientStep = createStep({
+  id: 'researcher',
+  inputSchema: z.object({ query: z.string() }),
+  outputSchema: z.object({
+    brief: z.string().nullable(),
+    failed: z.boolean(),
+  }),
+  execute: async ({ inputData }) => {
+    try {
+      const result = await fetchExternalData(inputData.query)
+      return { brief: result, failed: false }
+    } catch {
+      return { brief: null, failed: true }
+    }
+  },
+})
+```
+
+This way the step always succeeds with a typed result, and the downstream step can filter out failed results:
+
+```typescript
+const writerStep = createStep({
+  id: 'writer',
+  inputSchema: z.object({
+    'researcher-a': z.object({ brief: z.string().nullable(), failed: z.boolean() }),
+    'researcher-b': z.object({ brief: z.string().nullable(), failed: z.boolean() }),
+  }),
+  outputSchema: z.object({ synthesis: z.string() }),
+  execute: async ({ inputData }) => {
+    const briefs = Object.values(inputData)
+      .filter(v => !v.failed && v.brief)
+      .map(v => v.brief)
+    return { synthesis: briefs.join('; ') }
+  },
+})
+```
+
 > **Info:** Visit [Choosing the right pattern](#choosing-the-right-pattern) to understand when to use `.parallel()` vs `.foreach()`.
 
 ## Conditional logic with `.branch()`
@@ -292,7 +334,7 @@ export const testWorkflow = createWorkflow({
 
 ## Input data mapping
 
-When using `.then()`, `.parallel()`, or `.branch()`, it is sometimes necessary to transform the output of a previous step to match the input of the next. In these cases you can use `.map()` to access the `inputData` and transform it to create a suitable data shape for the next step.
+When using `.then()`, `.parallel()`, or `.branch()`, it's sometimes necessary to transform the output of a previous step to match the input of the next. In these cases you can use `.map()` to access the `inputData` and transform it to create a suitable data shape for the next step.
 
 ![Mapping with .map()](/assets/images/workflows-data-mapping-map-87fd84a06b4bbf4b93868a5db99ca179.jpg)
 
@@ -777,7 +819,7 @@ This means:
 
 - `.parallel()` collects all branch outputs into an object, then passes it to the next step
 - `.foreach()` collects all iteration outputs into an array, then passes it to the next step
-- There is no way to "stream" results to the next step as they complete
+- Results can't be "streamed" to the next step as they complete
 
 ### Concurrency behavior
 

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

@@ -1,4 +1,4 @@
-# Error Handling
+# Error handling
 
 Mastra workflows support error handling through result status checks after execution, retry policies for transient failures, and lifecycle callbacks for centralized error logging or alerting.
 
@@ -58,7 +58,7 @@ if (result.status === 'failed') {
 
 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
+### `onFinish`
 
 Called when a workflow completes with any status (success, failed, suspended, or tripwire):
 
@@ -100,7 +100,7 @@ The `onFinish` callback receives:
 - `logger` - The workflow's logger instance
 - `state` - The workflow's current state object
 
-### onError
+### `onError`
 
 Called only when a workflow fails (status is `'failed'` or `'tripwire'`):
 
@@ -166,7 +166,7 @@ const pipelineWorkflow = createWorkflow({
 
 ### Error handling in callbacks
 
-Errors thrown inside callbacks are caught and logged—they will not 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. This ensures that callback issues don't break your workflows in production.
 
 ```typescript
 options: {

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

@@ -140,7 +140,7 @@ export const testWorkflow = createWorkflow({
 
 ### Cloning a workflow
 
-Clone a workflow using `cloneWorkflow()` when you want to reuse its logic but track it separately under a new ID. Each clone runs independently and appears as a distinct workflow in logs and observability tools.
+Clone a workflow using `cloneWorkflow()` when you want to reuse its logic but track it separately under a new ID. Each clone runs independently and shows up as a distinct workflow in logs and observability tools.
 
 ```typescript
 import { cloneWorkflow } from "@mastra/core/workflows";
@@ -182,7 +182,7 @@ 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 does not provide the same level of type inference.
+> **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.
 
 ## Running workflows
 
@@ -358,7 +358,7 @@ const step1 = createStep({
 
 ## Testing with Studio
 
-Use [Studio](https://mastra.ai/docs/getting-started/studio) to easily run workflows with different inputs, visualize the execution lifecycle, see the inputs and outputs for each step, and inspect each part of the workflow in more detail.
+Use [Studio](https://mastra.ai/docs/getting-started/studio) to run workflows with different inputs, visualize the execution lifecycle, see the inputs and outputs for each step, and inspect each part of the workflow in more detail.
 
 ## Related
 

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

@@ -150,7 +150,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 are properly resumed.
+4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows, especially long-running ones, 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

@@ -1,4 +1,4 @@
-# Suspend & Resume
+# Suspend and resume
 
 Workflows can be paused at any step to collect additional data, wait for API callbacks, throttle costly operations, or request [human-in-the-loop](https://mastra.ai/docs/workflows/human-in-the-loop) input. When a workflow is suspended, its current execution state is saved as a snapshot. You can later resume the workflow from a [specific step ID](https://mastra.ai/docs/workflows/snapshots), restoring the exact state captured in that snapshot. [Snapshots](https://mastra.ai/docs/workflows/snapshots) are stored in your configured storage provider and persist across deployments and application restarts.