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

package/.docs/reference/agents/inngest-agent.md

@@ -2,6 +2,8 @@
 
 # `createInngestAgent()`
 
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
+
 `createInngestAgent()` wraps an existing [`Agent`](https://mastra.ai/reference/agents/agent) with [Inngest](https://www.inngest.com/docs)-powered durable execution. Like [`createDurableAgent()`](https://mastra.ai/reference/agents/durable-agent), it streams events over [PubSub](https://mastra.ai/docs/server/pubsub) and supports resumable streams, but runs the agentic loop on Inngest's execution engine instead of in-process. Use it when a run must survive process restarts or run in a distributed environment.
 
 For in-process durable execution, use [`createDurableAgent()`](https://mastra.ai/reference/agents/durable-agent). For fire-and-forget execution on the built-in workflow engine, use [`createEventedAgent()`](https://mastra.ai/reference/agents/durable-agent).
@@ -366,5 +368,5 @@ export const { GET, POST, PUT } = serveNext({ mastra, inngest })
 
 - [DurableAgent reference](https://mastra.ai/reference/agents/durable-agent)
 - [Agent class](https://mastra.ai/reference/agents/agent)
-- [Inngest deployment guide](https://mastra.ai/guides/deployment/inngest)
+- [Inngest deployment guide](https://mastra.ai/integrations/deploy/inngest)
 - [PubSub](https://mastra.ai/docs/server/pubsub)

package/.docs/reference/agents/network.md

@@ -4,7 +4,7 @@
 
 The `.network()` method enables multi-agent collaboration and routing. This method accepts messages and optional execution options.
 
-> **Deprecated:** The `.network()` primitive has been deprecated and will be removed in a future major release. Use [supervisor agents](https://mastra.ai/docs/capabilities/subagents) with `agent.stream()` or `agent.generate()` instead. See the [migration guide](https://mastra.ai/guides/migrations/network-to-supervisor) to upgrade.
+> **Deprecated:** The `.network()` primitive has been deprecated and will be removed in a future major release. Use [supervisor agents](https://mastra.ai/docs/capabilities/subagents) with `agent.stream()` or `agent.generate()` instead. See the [migration guide](https://mastra.ai/reference/migrations/network-to-supervisor) to upgrade.
 
 ## Usage example
 

package/.docs/reference/ai-sdk/handle-network-stream.md

@@ -2,7 +2,7 @@
 
 # handleNetworkStream()
 
-> **Deprecated:** Agent networks are deprecated and will be removed in a future release. Use [supervisor agents](https://mastra.ai/docs/capabilities/subagents) with `agent.stream()` or `agent.generate()` instead. See the [migration guide](https://mastra.ai/guides/migrations/network-to-supervisor) to upgrade.
+> **Deprecated:** Agent networks are deprecated and will be removed in a future release. Use [supervisor agents](https://mastra.ai/docs/capabilities/subagents) with `agent.stream()` or `agent.generate()` instead. See the [migration guide](https://mastra.ai/reference/migrations/network-to-supervisor) to upgrade.
 
 Framework-agnostic handler for streaming network execution in AI SDK-compatible format. Use this function directly when you need to handle network streaming outside Hono or Mastra's own [apiRoutes](https://mastra.ai/docs/server/custom-api-routes) feature.
 

package/.docs/reference/ai-sdk/network-route.md

@@ -2,7 +2,7 @@
 
 # networkRoute()
 
-> **Deprecated:** Agent networks are deprecated and will be removed in a future release. Use [supervisor agents](https://mastra.ai/docs/capabilities/subagents) with `agent.stream()` or `agent.generate()` instead. See the [migration guide](https://mastra.ai/guides/migrations/network-to-supervisor) to upgrade.
+> **Deprecated:** Agent networks are deprecated and will be removed in a future release. Use [supervisor agents](https://mastra.ai/docs/capabilities/subagents) with `agent.stream()` or `agent.generate()` instead. See the [migration guide](https://mastra.ai/reference/migrations/network-to-supervisor) to upgrade.
 
 Creates a network route handler for streaming network execution using the AI SDK format. This function registers an HTTP `POST` endpoint that accepts messages, executes an agent network, and streams the response back to the client in AI SDK-compatible format. Agent networks allow a routing agent to delegate tasks to other agents. You have to use it inside a [custom API route](https://mastra.ai/docs/server/custom-api-routes).
 

package/.docs/reference/auth/auth0.md

@@ -72,4 +72,4 @@ The exact properties available depend on your Auth0 configuration, scopes reques
 
 ## Related
 
-[MastraAuthAuth0 Class](https://mastra.ai/docs/server/auth/auth0)
+[MastraAuthAuth0 Class](https://mastra.ai/integrations/auth/auth0)

package/.docs/reference/auth/better-auth.md

@@ -70,4 +70,4 @@ The `Session` and `User` types are exported by the Better Auth package.
 
 ## Related
 
-[MastraAuthBetterAuth Class](https://mastra.ai/docs/server/auth/better-auth)
+[MastraAuthBetterAuth Class](https://mastra.ai/integrations/auth/better-auth)

package/.docs/reference/auth/clerk.md

@@ -35,4 +35,4 @@ export const mastra = new Mastra({
 
 ## Related
 
-[MastraAuthClerk Class](https://mastra.ai/docs/server/auth/clerk)
+[MastraAuthClerk Class](https://mastra.ai/integrations/auth/clerk)

package/.docs/reference/auth/firebase.md

@@ -79,4 +79,4 @@ The `FirebaseUser` type used in the `authorizeUser` function corresponds to Fire
 
 ## Related
 
-[MastraAuthFirebase Class](https://mastra.ai/docs/server/auth/firebase)
+[MastraAuthFirebase Class](https://mastra.ai/integrations/auth/firebase)

package/.docs/reference/auth/google.md

@@ -354,4 +354,4 @@ If `user.groups` is already an array, `MastraRBACGoogle` uses that value and doe
 
 ## Related
 
-[Google auth docs](https://mastra.ai/docs/server/auth/google)
+[Google auth docs](https://mastra.ai/integrations/auth/google)

package/.docs/reference/auth/okta.md

@@ -38,6 +38,8 @@ export const mastra = new Mastra({
 
 **redirectUri** (`string`): The OAuth redirect URI for the SSO callback. Must match the redirect URI configured in your Okta application. (Default: `process.env.OKTA_REDIRECT_URI`)
 
+**audience** (`string | string[]`): Expected aud claim for Bearer tokens. Defaults to the client ID, which matches Okta ID tokens. Set it to the authorization server's audience to accept access tokens, or pass an array to accept several. Does not affect the ID token verified during the SSO login flow, which always uses the client ID. (Default: `process.env.OKTA_AUDIENCE ?? clientId`)
+
 **scopes** (`string[]`): OAuth scopes to request during the login flow. (Default: `['openid', 'profile', 'email', 'groups']`)
 
 **apiToken** (`string`): Okta API token for user lookups via the Users API. Required for getUser() to return user data by ID. (Default: `process.env.OKTA_API_TOKEN`)
@@ -66,6 +68,8 @@ The following environment variables are automatically used when constructor opti
 
 **OKTA\_ISSUER** (`string`): Token issuer URL. Defaults to https\://{domain}/oauth2/default if not set.
 
+**OKTA\_AUDIENCE** (`string`): Expected aud claim for Bearer tokens. Defaults to the client ID if not set.
+
 **OKTA\_REDIRECT\_URI** (`string`): OAuth redirect URI for the SSO callback.
 
 **OKTA\_COOKIE\_PASSWORD** (`string`): Password for encrypting session cookies. Must be at least 32 characters.
@@ -77,7 +81,7 @@ The following environment variables are automatically used when constructor opti
 `MastraAuthOkta` authenticates requests in the following order:
 
 1. **Session cookie**: Reads the encrypted session cookie and decrypts it. If the session is valid and not expired, the user is authenticated.
-2. **JWT fallback**: If no session cookie is present, verifies the `Authorization` header token against Okta's JWKS endpoint.
+2. **JWT fallback**: If no session cookie is present, verifies the `Authorization` header token against Okta's JWKS endpoint. The token's `iss` claim is checked against `issuer` and its `aud` claim against `audience`.
 
 After authentication, `authorizeUser` checks that the user has a valid `oktaId`. Provide a custom `authorizeUser` function to implement additional logic.
 

package/.docs/reference/auth/supabase.md

@@ -32,4 +32,4 @@ export const mastra = new Mastra({
 
 ## Related
 
-[MastraAuthSupabase](https://mastra.ai/docs/server/auth/supabase)
+[MastraAuthSupabase](https://mastra.ai/integrations/auth/supabase)

package/.docs/reference/auth/workos.md

@@ -128,4 +128,4 @@ The properties with `urn:myapp:` prefixes are custom claims configured in your W
 
 ## Related
 
-[MastraAuthWorkos Class](https://mastra.ai/docs/server/auth/workos)
+[MastraAuthWorkos Class](https://mastra.ai/integrations/auth/workos)

package/.docs/reference/browser/agent-browser.md

@@ -32,7 +32,7 @@ then interact with elements using their refs (e.g., @e5).`,
 
 **headless** (`boolean`): Whether to run the browser in headless mode (no visible UI). (Default: `true`)
 
-**viewport** (`{ width: number; height: number }`): Browser viewport dimensions. (Default: `{ width: 1280, height: 720 }`)
+**viewport** (`{ width: number; height: number } | 'window'`): Browser viewport dimensions, or 'window' to match the real browser window instead of a fixed size. (Default: `{ width: 1280, height: 720 }`)
 
 **timeout** (`number`): Default timeout in milliseconds for browser operations. (Default: `30000`)
 
@@ -404,4 +404,4 @@ The `browser_snapshot` tool returns an accessibility tree with element refs like
 - [MastraBrowser](https://mastra.ai/reference/browser/mastra-browser): Base class reference
 - [StagehandBrowser](https://mastra.ai/reference/browser/stagehand-browser): AI-powered alternative
 - [Browser overview](https://mastra.ai/docs/browser/overview): Conceptual guide
-- [agent-browser guide](https://mastra.ai/docs/browser/agent-browser): Usage guide
+- [agent-browser guide](https://mastra.ai/integrations/browsers/agent-browser): Usage guide

package/.docs/reference/browser/browser-viewer.md

@@ -227,6 +227,6 @@ browse skills install
 
 ## Related
 
-- [BrowserViewer guide](https://mastra.ai/docs/browser/browser-viewer): Setup and usage walkthrough
+- [BrowserViewer guide](https://mastra.ai/integrations/browsers/browser-viewer): Setup and usage walkthrough
 - [MastraBrowser](https://mastra.ai/reference/browser/mastra-browser): Base class API reference
 - [Workspace overview](https://mastra.ai/docs/workspace/overview): Workspace configuration

package/.docs/reference/browser/firecrawl-browser.md

@@ -66,6 +66,6 @@ In both cases, `FirecrawlBrowser` deletes the remote Firecrawl session when the
 
 ## Related
 
-- [Firecrawl docs](https://mastra.ai/docs/browser/firecrawl)
+- [Firecrawl docs](https://mastra.ai/integrations/browsers/firecrawl)
 - [`AgentBrowser` reference](https://mastra.ai/reference/browser/agent-browser)
 - [Browser overview](https://mastra.ai/docs/browser/overview)

package/.docs/reference/browser/mastra-browser.md

@@ -35,7 +35,7 @@ export const browserAgent = new Agent({
 
 **headless** (`boolean`): Whether to run the browser in headless mode (no visible UI). (Default: `true`)
 
-**viewport** (`{ width: number; height: number }`): Browser viewport dimensions. Controls the size of the browser window. (Default: `{ width: 1280, height: 720 }`)
+**viewport** (`{ width: number; height: number } | 'window'`): Browser viewport dimensions. Controls the size of the browser window. Set to 'window' to match the real browser window instead of a fixed size, supported by the agent-browser provider and by Stagehand when connecting over CDP. (Default: `{ width: 1280, height: 720 }`)
 
 **timeout** (`number`): Default timeout in milliseconds. Each provider defines its own semantics and default. See the provider reference for details.
 

package/.docs/reference/browser/stagehand-browser.md

@@ -33,7 +33,7 @@ Use stagehand_extract to get data from pages.`,
 
 **headless** (`boolean`): Whether to run the browser in headless mode. (Default: `true`)
 
-**viewport** (`{ width: number; height: number }`): Browser viewport dimensions. (Default: `{ width: 1280, height: 720 }`)
+**viewport** (`{ width: number; height: number } | 'window'`): Browser viewport dimensions. 'window' matches the real browser window and only applies when connecting over CDP; a locally launched browser falls back to the default size. (Default: `{ width: 1280, height: 720 }`)
 
 **env** (`'LOCAL' | 'BROWSERBASE'`): Environment to run the browser in. Use 'BROWSERBASE' for cloud execution. (Default: `'LOCAL'`)
 
@@ -317,4 +317,4 @@ Choose `AgentBrowser` for precise, reproducible automation. Choose `StagehandBro
 - [MastraBrowser](https://mastra.ai/reference/browser/mastra-browser): Base class reference
 - [AgentBrowser](https://mastra.ai/reference/browser/agent-browser): Deterministic alternative
 - [Browser overview](https://mastra.ai/docs/browser/overview): Conceptual guide
-- [Stagehand guide](https://mastra.ai/docs/browser/stagehand): Usage guide
+- [Stagehand guide](https://mastra.ai/integrations/browsers/stagehand): Usage guide

package/.docs/reference/channels/channel-provider.md

@@ -64,4 +64,4 @@ const all = mastra.getChannelProviders()
 ## Related
 
 - [SlackProvider](https://mastra.ai/reference/channels/slack-provider)
-- [Channels](https://mastra.ai/docs/capabilities/channels/overview)
+- [Channels](https://mastra.ai/docs/capabilities/channels)

package/.docs/reference/channels/slack-provider.md

@@ -2,7 +2,7 @@
 
 # SlackProvider
 
-`SlackProvider` is the managed path for connecting agents to Slack. Register it on `Mastra.channels` and it provisions Slack apps via the Manifest API, runs the OAuth install flow, rotates configuration tokens, and routes Slack events to your agents. Use it when you want Mastra to own app creation and installation. For the lower-level path where you create the Slack app and configure scopes and webhooks yourself, use [`createSlackAdapter`](https://mastra.ai/docs/capabilities/channels/slack) on the agent's `channels.adapters` instead.
+`SlackProvider` is the managed path for connecting agents to Slack. Register it on `Mastra.channels` and it provisions Slack apps via the Manifest API, runs the OAuth install flow, rotates configuration tokens, and routes Slack events to your agents. Use it when you want Mastra to own app creation and installation. For the lower-level path where you create the Slack app and configure scopes and webhooks yourself, use [`createSlackAdapter`](https://mastra.ai/integrations/channels/slack) on the agent's `channels.adapters` instead.
 
 ## Usage example
 
@@ -226,5 +226,5 @@ const result = await slack.connect('support-agent')
 ## Related
 
 - [ChannelProvider](https://mastra.ai/reference/channels/channel-provider): the interface `SlackProvider` implements
-- [Channels](https://mastra.ai/docs/capabilities/channels/overview): concepts, platform setup, and the `createSlackAdapter` path
+- [Channels](https://mastra.ai/docs/capabilities/channels): concepts, platform setup, and the `createSlackAdapter` path
 - [Channels reference](https://mastra.ai/reference/agents/channels): the `channels` config on the `Agent` constructor

package/.docs/reference/cli/mastra.md

@@ -153,7 +153,7 @@ MASTRA_CONCURRENCY=2 mastra build
 
 ## `mastra start`
 
-> **Info:** You need to run `mastra build` before using `mastra start`.
+> **Note:** You need to run `mastra build` before using `mastra start`.
 
 Starts a local server to serve your built Mastra application in production mode. By default, [OTEL Tracing](https://mastra.ai/docs/observability/tracing/overview) is enabled.
 
@@ -266,7 +266,7 @@ Enable debug logging during the build.
 
 ## `mastra worker start`
 
-> **Info:** You need to run `mastra worker build` or `mastra build` before using `mastra worker start`.
+> **Note:** You need to run `mastra worker build` or `mastra build` before using `mastra worker start`.
 
 Starts a worker process from a previously built bundle. The optional `name` argument sets `MASTRA_WORKERS` in the spawned process, controlling which worker starts.
 
@@ -609,7 +609,7 @@ Emit machine-readable JSON.
 
 ## `mastra studio deploy`
 
-> **Info:** `mastra studio deploy` continues to work but is superseded by [`mastra deploy`](#mastra-deploy), which supports environments (`--env staging`, `--env production`) on a single project. New setups should use `mastra deploy`.
+> **Note:** `mastra studio deploy` continues to work but is superseded by [`mastra deploy`](#mastra-deploy), which supports environments (`--env staging`, `--env production`) on a single project. New setups should use `mastra deploy`.
 
 Builds and deploys your project to Mastra platform. Requires authentication via [`mastra auth login`](#mastra-auth-login) or a `MASTRA_API_TOKEN` environment variable.
 
@@ -727,7 +727,7 @@ Creates a new project through an interactive prompt. This command doesn't accept
 
 ## `mastra server deploy`
 
-> **Info:** `mastra server deploy` continues to work but is superseded by [`mastra deploy`](#mastra-deploy), which deploys a single project to multiple environments instead of separate Studio and Server commands. New setups should use `mastra deploy`.
+> **Note:** `mastra server deploy` continues to work but is superseded by [`mastra deploy`](#mastra-deploy), which deploys a single project to multiple environments instead of separate Studio and Server commands. New setups should use `mastra deploy`.
 
 Builds and deploys your project to Server on Mastra platform. Works the same as [`mastra studio deploy`](#mastra-studio-deploy) with the same flags, arguments, and resolution logic.
 
@@ -1043,13 +1043,13 @@ Runs database migrations to update your storage schema. This command is useful w
 The command bundles your project and connects to your configured storage backend. It then executes any pending migrations. Currently supports:
 
 - **Duplicate spans migration**: Removes duplicate `(traceId, spanId)` entries and adds a unique constraint to ensure data integrity.
-- **ClickHouse legacy-to-vNext span migration**: Copies historical spans from the legacy `mastra_ai_spans` table to the vNext `mastra_span_events` schema. Runs in batches to stay within memory limits. See the [ClickHouse storage reference](https://mastra.ai/reference/storage/clickhouse) for details.
+- **ClickHouse legacy-to-vNext span migration**: Copies historical spans from the legacy `mastra_ai_spans` table to the vNext `mastra_span_events` schema. Runs in batches to stay within memory limits. See the [ClickHouse storage reference](https://mastra.ai/integrations/databases/clickhouse) for details.
 
 ```bash
 mastra migrate
 ```
 
-See the [Storage migration guide](https://mastra.ai/guides/migrations/upgrade-to-v1/storage) for details on when migrations are needed.
+See the [Storage migration guide](https://mastra.ai/reference/migrations/upgrade-to-v1/storage) for details on when migrations are needed.
 
 It accepts [common flags](#common-flags).
 

package/.docs/reference/client-js/agents.md

@@ -421,12 +421,13 @@ Returns `{ accepted: true, runId: string, toolCallId?: string }`.
 
 ### `declineToolCall()`
 
-Decline a pending tool call and return a continuation stream. Use this when you are rendering the resumed chunks from the decline response.
+Decline a pending tool call and return a continuation stream. Use this when you are rendering the resumed chunks from the decline response. Pass an optional `reason` to tell the model why the call was rejected. The default is `Tool call was not approved by the user`.
 
 ```typescript
 const response = await agent.declineToolCall({
   runId: 'run-123',
   toolCallId: 'tool-call-456',
+  reason: 'This file is outside the allowed directory', // optional
 })
 
 response.processDataStream({

package/.docs/reference/client-js/workflows.md

@@ -14,7 +14,7 @@ const workflows = await mastraClient.listWorkflows()
 
 ## Getting workflow run counts
 
-Retrieve per-workflow counts of `running` and [`suspended`](https://mastra.ai/docs/workflows/suspend-and-resume) runs in a single request. The counts are computed on the server and keyed by the workflow's registry key — the key used when registering the workflow in the Mastra config, which can differ from the workflow's own `id`:
+Retrieve per-workflow counts of `running` and [`suspended`](https://mastra.ai/docs/workflows/suspend-and-resume) runs in a single request. The counts are computed on the server and keyed by the workflow's registry key, the key used when registering the workflow in the Mastra config, which can differ from the workflow's own `id`:
 
 ```typescript
 const runCounts = await mastraClient.listWorkflowRunCounts()
@@ -23,7 +23,7 @@ const runCounts = await mastraClient.listWorkflowRunCounts()
 
 Returns: `Record<string, { running: number; suspended: number }>`
 
-The server may cache the counts for a few seconds between requests. Servers that predate this endpoint respond with `404 Not Found` — handle the error when the client can talk to older deployments.
+The server may cache the counts for a few seconds between requests. Servers that predate this endpoint respond with `404 Not Found`. Handle the error when the client can talk to older deployments.
 
 ## Working with a specific workflow
 
@@ -225,28 +225,28 @@ A workflow run result yields the following:
 
 **payload** (`object`): Contains currentStep (id, status, output, payload) and workflowState (status, steps record)
 
-## Stored workflows
+## Dynamic workflows
 
-> **Beta:** Stored workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
-Stored workflows are workflow definitions expressed as JSON. The server persists each definition and registers it as a runnable workflow. See [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows) for the definition format.
+Dynamic workflows are workflow definitions expressed as JSON. The server persists each definition and registers it as a runnable workflow. See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) for the definition format.
 
-### `listStoredWorkflows()`
+### `listDynamicWorkflows()`
 
-List stored workflow definitions, optionally filtered by `status` (`'active' | 'archived'`) and `authorId`:
+List dynamic workflow definitions, optionally filtered by `status` (`'active' | 'archived'`) and `authorId`:
 
 ```typescript
-const { definitions, total } = await mastraClient.listStoredWorkflows({
+const { definitions, total } = await mastraClient.listDynamicWorkflows({
   status: 'active',
 })
 ```
 
-### `upsertStoredWorkflow()`
+### `upsertDynamicWorkflow()`
 
-Create or replace a stored workflow definition. The server validates the definition, persists it, and live-registers it for execution:
+Create or replace a dynamic workflow definition. The server validates the definition, persists it, and live-registers it for execution:
 
 ```typescript
-const stored = await mastraClient.upsertStoredWorkflow({
+const stored = await mastraClient.upsertDynamicWorkflow({
   id: 'greeting-workflow',
   description: 'Returns a greeting for the supplied name',
   inputSchema: {
@@ -274,7 +274,7 @@ const stored = await mastraClient.upsertStoredWorkflow({
 When the root definition nests helper workflows that don't exist yet, pass them in the same request through `dependencies`. The server validates and registers the bundle as a unit and echoes the helper ids back as `dependencyIds`:
 
 ```typescript
-const stored = await mastraClient.upsertStoredWorkflow({
+const stored = await mastraClient.upsertDynamicWorkflow({
   id: 'root-workflow',
   // ...schemas and graph referencing 'helper-workflow'...
   dependencies: [helperDefinition],
@@ -283,33 +283,33 @@ const stored = await mastraClient.upsertStoredWorkflow({
 console.log(stored.dependencyIds) // ['helper-workflow']
 ```
 
-### `getStoredWorkflow()`
+### `getDynamicWorkflow()`
 
-Get a stored workflow instance for definition management. To execute a stored workflow, use `getWorkflow(id).createRun()` like any other workflow:
+Get a dynamic workflow instance for definition management. To execute a dynamic workflow, use `getWorkflow(id).createRun()` like any other workflow:
 
 ```typescript
-const storedWorkflow = mastraClient.getStoredWorkflow('greeting-workflow')
+const dynamicWorkflow = mastraClient.getDynamicWorkflow('greeting-workflow')
 ```
 
-### `storedWorkflow.details()`
+### `dynamicWorkflow.details()`
 
 Retrieve the persisted definition, including schemas, graph, status, and timestamps:
 
 ```typescript
-const definition = await storedWorkflow.details()
+const definition = await dynamicWorkflow.details()
 ```
 
-### `storedWorkflow.delete()`
+### `dynamicWorkflow.delete()`
 
 Delete the stored definition and unregister the live workflow:
 
 ```typescript
-await storedWorkflow.delete()
+await dynamicWorkflow.delete()
 ```
 
-### Executing a stored workflow
+### Executing a dynamic workflow
 
-Once registered, a stored workflow runs through the ordinary workflow API:
+Once registered, a dynamic workflow runs through the ordinary workflow API:
 
 ```typescript
 const workflow = mastraClient.getWorkflow('greeting-workflow')

package/.docs/reference/code-sdk/mount-agent-controller.md

@@ -2,7 +2,7 @@
 
 # mountAgentControllerOnMastra()
 
-> **Beta:** The `@mastra/code-sdk` package is experimental and subject to breaking changes in minor versions.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 The `mountAgentControllerOnMastra()` function builds the Mastra Code agent controller (the coding agent behind the [`mastracode`](https://www.npmjs.com/package/mastracode) CLI, with its modes, tools, memory, and thread management) and registers it on a server-owned [Mastra](https://mastra.ai/reference/core/mastra-class) instance. Use it to serve the Mastra Code agent to your own UI (web app, editor, bot): each client creates or resumes its own isolated session through the returned [`AgentController`](https://mastra.ai/reference/agent-controller/agent-controller-class).
 

package/.docs/reference/configuration.md

@@ -438,9 +438,9 @@ export const mastra = new Mastra({
 
 **Type:** `Record<string, MastraVector>`
 
-Vector stores for semantic search and embeddings. Used in RAG pipelines, similarity search, and other embedding-based features. Mastra supports multiple vector databases including Pinecone, PostgreSQL with pgvector, MongoDB, and more.
+Vector stores for semantic search and embeddings. Used in RAG pipelines, similarity search, and other embedding-based features. Mastra supports multiple vector databases including Pinecone, PostgreSQL with pgvector, OracleDB, MongoDB, and more.
 
-Visit the [RAG documentation](https://mastra.ai/guides/rag/overview) to learn more.
+Visit the [RAG documentation](https://mastra.ai/reference/rag/overview) to learn more.
 
 > **Note:** Most users create vector stores directly when building RAG pipelines. This top-level configuration is for defining reusable vector store instances that can be shared across your application.
 
@@ -500,31 +500,6 @@ const mastra = new Mastra({
 
 ## Bundler options
 
-### bundler.entries
-
-**Type:** `Record<string, string>`\
-**Default:** `{}`
-
-Additional process entries to emit alongside the server bundle, as a map of output name to source path relative to your Mastra directory. Each entry becomes its own `<name>.mjs` in `.mastra/output`.
-
-Use this for long-running processes that run beside your Mastra server rather than inside it, such as a [LiveKit voice worker](https://mastra.ai/guides/voice/realtime-voice). The entry shares the output directory, `package.json`, and installed dependencies with the server, so one `mastra build` produces one deployable artifact you can start with different commands.
-
-```typescript
-import { Mastra } from '@mastra/core'
-
-export const mastra = new Mastra({
-  bundler: {
-    entries: { 'voice-worker': './voice-worker.ts' },
-  },
-})
-```
-
-This emits `.mastra/output/voice-worker.mjs` next to `.mastra/output/index.mjs`. Dependencies imported only by the extra entry are analyzed too, so they're installed into the output.
-
-Entry names can contain `/` to nest the output. They can't be `index`, which is the server bundle, `tools`, which is the tool aggregator, or start with `tools/`, which is reserved for tool bundles.
-
-> **Note:** `mastra build` applies the [`bundler.externals`](#bundlerexternals) default of `true` only when you set no bundler options at all. Once you set `entries`, set `externals` explicitly as well if your extra entry depends on packages that can't be bundled, such as native modules.
-
 ### bundler.externals
 
 **Type:** `boolean | string[]`\
@@ -567,6 +542,25 @@ export const mastra = new Mastra({
 })
 ```
 
+### bundler.minify
+
+**Type:** `boolean`\
+**Default:** `false`
+
+Minifies the bundled output, stripping comments and whitespace and shortening local identifiers. Exported names are preserved.
+
+Off by default so build output stays readable and stack traces stay usable. Enable it when bundle size matters, such as packaging a container image for an on-prem deployment. `mastra dev` is never minified.
+
+```typescript
+import { Mastra } from '@mastra/core'
+
+export const mastra = new Mastra({
+  bundler: {
+    minify: true,
+  },
+})
+```
+
 ### bundler.transpilePackages
 
 **Type:** `string[]`\

package/.docs/reference/core/{addStoredWorkflow.md → addDynamicWorkflow.md}

@@ -1,17 +1,17 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Mastra.addStoredWorkflow()
+# Mastra.addDynamicWorkflow()
 
-> **Beta:** Stored workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
-The `.addStoredWorkflow()` method validates a stored workflow definition and registers it as a live workflow on the instance, persisting it through the `workflowDefinitions` storage domain. Once registered, the workflow runs like any other workflow via [`getWorkflow()`](https://mastra.ai/reference/core/getWorkflow).
+The `.addDynamicWorkflow()` method validates a dynamic workflow definition and registers it as a live workflow on the instance, persisting it through the `workflowDefinitions` storage domain. Once registered, the workflow runs like any other workflow via [`getWorkflow()`](https://mastra.ai/reference/core/getWorkflow).
 
-See [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows) for a complete setup example and the [stored workflow definition reference](https://mastra.ai/reference/workflows/stored-workflow-definition) for the accepted fields and graph entries.
+See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) for a complete setup example and the [dynamic workflow definition reference](https://mastra.ai/reference/workflows/dynamic-workflow-definition) for the accepted fields and graph entries.
 
 ## Usage example
 
 ```typescript
-await mastra.addStoredWorkflow({
+await mastra.addDynamicWorkflow({
   id: 'greeting-workflow',
   description: 'Returns a greeting for the supplied name',
   inputSchema: {
@@ -41,7 +41,7 @@ const result = await run.start({ inputData: { name: 'Ada' } })
 
 ## Parameters
 
-**def** (`StoredWorkflowGraph`): The workflow definition: id, optional description and metadata, JSON Schema input/output schemas, optional state and request-context schemas, and the step graph.
+**def** (`DynamicWorkflowGraph | WorkflowBuilderDefinitionInput`): The workflow definition: id, optional description and metadata, JSON Schema input/output schemas, optional state and request-context schemas, and the step graph.
 
 ## Returns
 
@@ -52,11 +52,11 @@ A promise that resolves once the definition is validated, registered, and persis
 - The definition is fully validated (structure, references, schema flow) before anything is mutated. Agents, tools, and workflows referenced by the graph must already be registered on the instance.
 - Adding a definition with an existing ID replaces both the stored definition and the live registration. In-flight runs keep the graph they started with.
 - Without a storage adapter that supports the `workflowDefinitions` domain, the workflow is still validated and registered in memory, but the definition is lost on restart.
-- To add a root workflow together with helper workflows it nests, use [`addStoredWorkflows()`](https://mastra.ai/reference/core/addStoredWorkflows).
+- To add a root workflow together with helper workflows it nests, use [`addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows).
 
 ## Related
 
-- [Mastra.addStoredWorkflows()](https://mastra.ai/reference/core/addStoredWorkflows): Add a dependency-ordered bundle of definitions
+- [Mastra.addDynamicWorkflows()](https://mastra.ai/reference/core/addDynamicWorkflows): Add a dependency-ordered bundle of definitions
 - [Mastra.getWorkflow()](https://mastra.ai/reference/core/getWorkflow): Retrieve a registered workflow
-- [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows): Set up and use stored workflows
-- [Stored workflow definition](https://mastra.ai/reference/workflows/stored-workflow-definition): Definition fields and graph entries
+- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows): Set up and use dynamic workflows
+- [Dynamic workflow definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition): Definition fields and graph entries

package/.docs/reference/core/{addStoredWorkflows.md → addDynamicWorkflows.md}

@@ -1,19 +1,19 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Mastra.addStoredWorkflows()
+# Mastra.addDynamicWorkflows()
 
-> **Beta:** Stored workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
-The `.addStoredWorkflows()` method adds a bundle of stored workflow definitions that may reference each other. The typical case is a root workflow plus helper workflows it nests, where none of the definitions exist yet.
+The `.addDynamicWorkflows()` method adds a bundle of dynamic workflow definitions that may reference each other. The typical case is a root workflow plus helper workflows it nests, where none of the definitions exist yet.
 
 The whole bundle is validated up front. Members are then registered in dependency order, so a helper is always in place before the workflow that nests it.
 
-[`addStoredWorkflow()`](https://mastra.ai/reference/core/addStoredWorkflow) is the single-member case.
+[`addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow) is the single-member case.
 
 ## Usage example
 
 ```typescript
-await mastra.addStoredWorkflows([
+await mastra.addDynamicWorkflows([
   helperDefinition, // nested by the root — order in the array doesn't matter
   rootDefinition, // graph contains { type: 'workflow', workflowId: helperDefinition.id }
 ])
@@ -21,7 +21,7 @@ await mastra.addStoredWorkflows([
 
 ## Parameters
 
-**defs** (`readonly StoredWorkflowGraph[]`): The workflow definitions to add. Nested-workflow references may resolve against the live registries or against other members of the same bundle.
+**defs** (`readonly (DynamicWorkflowGraph | WorkflowBuilderDefinitionInput)[]`): The workflow definitions to add. Nested-workflow references may resolve against the live registries or against other members of the same bundle.
 
 ## Returns
 
@@ -35,6 +35,6 @@ A promise that resolves once every member is validated, registered, and persiste
 
 ## Related
 
-- [Mastra.addStoredWorkflow()](https://mastra.ai/reference/core/addStoredWorkflow): Add a single definition
-- [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows): Set up and use stored workflows
-- [Stored workflow definition](https://mastra.ai/reference/workflows/stored-workflow-definition): Definition fields and graph entries
+- [Mastra.addDynamicWorkflow()](https://mastra.ai/reference/core/addDynamicWorkflow): Add a single definition
+- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows): Set up and use dynamic workflows
+- [Dynamic workflow definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition): Definition fields and graph entries

package/.docs/reference/core/getStorage.md

@@ -21,4 +21,4 @@ This method doesn't accept any parameters.
 ## Related
 
 - [Storage overview](https://mastra.ai/reference/storage/overview)
-- [Storage reference](https://mastra.ai/reference/storage/libsql)
+- [Storage reference](https://mastra.ai/integrations/databases/libsql)

package/.docs/reference/core/getVector.md

@@ -20,5 +20,5 @@ mastra.getVector('testVectorStore')
 
 ## Related
 
-- [Vector stores overview](https://mastra.ai/guides/rag/vector-databases)
-- [RAG overview](https://mastra.ai/guides/rag/overview)
+- [Vector stores overview](https://mastra.ai/reference/rag/vector-databases)
+- [RAG overview](https://mastra.ai/reference/rag/overview)

package/.docs/reference/core/listVectors.md

@@ -20,5 +20,5 @@ This method doesn't accept any parameters.
 
 ## Related
 
-- [Vector stores overview](https://mastra.ai/guides/rag/vector-databases)
-- [RAG overview](https://mastra.ai/guides/rag/overview)
+- [Vector stores overview](https://mastra.ai/reference/rag/vector-databases)
+- [RAG overview](https://mastra.ai/reference/rag/overview)

package/.docs/reference/core/setStorage.md

@@ -26,4 +26,4 @@ This method doesn't return a value.
 ## Related
 
 - [Storage overview](https://mastra.ai/reference/storage/overview)
-- [Storage reference](https://mastra.ai/reference/storage/libsql)
+- [Storage reference](https://mastra.ai/integrations/databases/libsql)

package/.docs/reference/datasets/startExperiment.md

@@ -79,6 +79,14 @@ console.log(`Status: ${summary2.status}`)
 
 **unmockedToolPolicy** (`'allow' | 'deny'`): Controls undeclared agent tool calls. allow executes them live. deny fails the item with TOOL\_MOCK\_NOT\_DECLARED before execution. An item-level value overrides this experiment default. (Default: `'allow'`)
 
+**beforeAll** (`(args: ExperimentHookArgs) => void | Promise<void>`): Runs once before any item executes. Receives experimentId, mastra, and signal. A failure fails the experiment and no items run.
+
+**beforeEach** (`(args: ExperimentItemHookArgs) => void | Promise<void>`): Runs before each item executes. Also receives the item (id, input, groundTruth, metadata). A failure fails that item with EXPERIMENT\_ITEM\_BEFORE\_EACH\_FAILED and skips its target, scorers, and afterEach.
+
+**afterEach** (`(args: ExperimentItemResultHookArgs) => void | Promise<void>`): Runs after each item completes. Also receives the item's result with its scores. Skipped when beforeEach failed. A failure is logged and doesn't change the item's outcome.
+
+**afterAll** (`(args: ExperimentRunResultHookArgs) => void | Promise<void>`): Runs once after the experiment finishes, on every exit path including failure. Also receives the summary. A failure is logged and doesn't change the summary.
+
 **persistence** (`ExperimentPersistencePolicy`): Controls whether this run writes experiment records and score records. Targets and scorers still execute, and results remain available in the returned summary.
 
 **persistence.experiments** (`'default' | 'none'`): Set to none to skip experiment creation, item results, progress, and terminal status writes.