@mastra/mcp-docs-server 1.2.15-alpha.6 → 1.2.15-alpha.9

package/.docs/docs/capabilities/channels/overview.md

@@ -153,6 +153,25 @@ When the agent calls this tool, users see a card with the tool name, arguments,
 
 Set `toolDisplay: 'text'` on an adapter to render tool calls as plain text instead of interactive cards. In `'hidden'` mode, `autoResumeSuspendedTools` can resume suspended tools when a later user message arrives on the same thread. This requires memory. Hidden mode only suppresses the approval buttons.
 
+## Reply formatting
+
+Agent replies post as markdown by default. Platforms with native markdown rendering, such as Slack, render bold text, links, and tables directly. Other platforms convert the markdown to their own format. Agents write standard markdown and it renders correctly everywhere, matching how the same reply renders in Studio.
+
+Set `textFormat: 'plain'` on an adapter to post replies as literal plain text instead:
+
+```typescript
+channels: {
+  adapters: {
+    slack: {
+      adapter: createSlackAdapter(),
+      textFormat: 'plain',
+    },
+  },
+},
+```
+
+Use this escape hatch if your agent is prompted to emit a platform-specific dialect, such as Slack mrkdwn, instead of standard markdown. If you added such prompt instructions to work around markdown rendering literally, remove them instead. The default now renders standard markdown natively. `textFormat` affects final reply text only. Tool cards, error messages, and natively streamed text are unaffected.
+
 ## Multi-user awareness
 
 In group conversations, Mastra prefixes each message with the sender's name and platform ID so the agent can distinguish between speakers:

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

@@ -69,15 +69,15 @@ The Mastra Client SDK exposes all resources served by the Mastra Server.
 - **[Logs](https://mastra.ai/reference/client-js/logs)**: View logs and debug system behavior.
 - **[Telemetry](https://mastra.ai/reference/client-js/telemetry)**: View app performance and trace activity.
 
-## Create and run stored workflows
+## Create and run dynamic workflows
 
-Use `upsertStoredWorkflow()` to create or replace a persisted workflow definition. A successful upsert validates the complete definition, registers it with the running Mastra instance, and makes it available through the standard workflow execution API.
+Use `upsertDynamicWorkflow()` to create or replace a persisted workflow definition. A successful upsert validates the complete definition, registers it with the running Mastra instance, and makes it available through the standard workflow execution API.
 
 The following example shows the full lifecycle of a mapping workflow, from creation and inspection through execution and deletion:
 
 ```typescript
 import { MastraClient } from '@mastra/client-js'
-import type { UpsertStoredWorkflowParams } from '@mastra/client-js'
+import type { UpsertDynamicWorkflowParams } from '@mastra/client-js'
 
 const client = new MastraClient({
   baseUrl: process.env.MASTRA_API_URL || 'http://localhost:4111',
@@ -105,25 +105,25 @@ const definition = {
       }),
     },
   ],
-} satisfies UpsertStoredWorkflowParams
+} satisfies UpsertDynamicWorkflowParams
 
-await client.upsertStoredWorkflow(definition)
+await client.upsertDynamicWorkflow(definition)
 
-const storedWorkflow = client.getStoredWorkflow(definition.id)
-const storedDefinition = await storedWorkflow.details()
+const dynamicWorkflow = client.getDynamicWorkflow(definition.id)
+const dynamicDefinition = await dynamicWorkflow.details()
 
-const workflow = client.getWorkflow(storedDefinition.id)
+const workflow = client.getWorkflow(dynamicDefinition.id)
 const run = await workflow.createRun()
 const result = await run.startAsync({ inputData: { name: 'Ada' } })
 
 console.log(result)
 
-await storedWorkflow.delete()
+await dynamicWorkflow.delete()
 ```
 
-Use `listStoredWorkflows()` to list persisted definitions. Calling `upsertStoredWorkflow()` again with the same `id` replaces the stored definition and live workflow registration.
+Use `listDynamicWorkflows()` to list persisted definitions. Calling `upsertDynamicWorkflow()` again with the same `id` replaces the stored definition and live workflow registration.
 
-> **Warning:** Durable storage requires a configured storage adapter that supports the `workflowDefinitions` domain. Without that domain, Core can register a workflow in memory, but the server's stored-workflow API can't preserve it across restarts.
+> **Warning:** Durable storage requires a configured storage adapter that supports the `workflowDefinitions` domain. Without that domain, Core can register a workflow in memory, but the server's dynamic-workflow API can't preserve it across restarts.
 >
 > Stored definitions support declarative agent, tool, mapping, nested workflow, parallel, foreach, sleep, sleep-until, conditional, and loop entries. They can't contain JavaScript closures. Conditional and loop logic must use the declarative predicate format, and referenced agents, tools, and nested workflows must already be registered.
 >

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

@@ -123,7 +123,7 @@ export const testWorkflow = createWorkflow({})
   .commit()
 ```
 
-`.agent()` records a declarative entry in the workflow graph rather than an opaque step, so workflows built this way can be persisted as [stored workflows](https://mastra.ai/docs/workflows/stored-workflows). Visit [Workflow.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent) for all parameters.
+`.agent()` records a declarative entry in the workflow graph rather than an opaque step, so workflows built this way can be persisted as [dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows). Visit [Workflow.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent) for all parameters.
 
 ## Using tools in workflows
 
@@ -184,7 +184,7 @@ import { testTool } from '../tools/test-tool'
 export const testWorkflow = createWorkflow({}).then(step1).tool(testTool).commit()
 ```
 
-Like `.agent()`, `.tool()` records a declarative entry, so the workflow can be persisted as a [stored workflow](https://mastra.ai/docs/workflows/stored-workflows). Visit [Workflow.tool()](https://mastra.ai/reference/workflows/workflow-methods/tool) for all parameters.
+Like `.agent()`, `.tool()` records a declarative entry, so the workflow can be persisted as a [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows). Visit [Workflow.tool()](https://mastra.ai/reference/workflows/workflow-methods/tool) for all parameters.
 
 ## Related
 

package/.docs/docs/workflows/{stored-workflows.md → dynamic-workflows.md}

@@ -1,22 +1,22 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Stored workflows
+# Dynamic workflows
 
 > **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
 
-Stored workflows are workflow definitions expressed as data instead of code. A definition is a JSON document that describes the workflow's schemas and step graph. Mastra validates the definition and registers it as a runnable workflow, then persists it in storage so it survives process restarts.
+Dynamic workflows are workflow definitions expressed as data instead of code. A definition is a JSON document that describes the workflow's schemas and step graph. Mastra validates the definition and registers it as a runnable workflow, then persists it in storage so it survives process restarts.
 
-Because a definition contains no JavaScript closures, anything that can produce JSON can author a workflow: an HTTP client, an LLM, a visual editor, or your own tooling. Once registered, a stored workflow runs through the same execution API as a code-defined workflow.
+Because a definition contains no JavaScript closures, anything that can produce JSON can author a workflow: an HTTP client, an LLM, a visual editor, or your own tooling. Once registered, a dynamic workflow runs through the same execution API as a code-defined workflow.
 
-## When to use stored workflows
+## When to use dynamic workflows
 
-Use stored workflows when users, agents, visual editors, or external systems need to create workflows without changing application code or deploying again.
+Use dynamic workflows when users, agents, visual editors, or external systems need to create workflows without changing application code or deploying again.
 
-Keep defining workflows with [`createWorkflow()`](https://mastra.ai/docs/workflows/overview) when the workflow belongs in your application source or needs custom step functions. Stored workflows can invoke agents, tools, and workflows that are already registered on the `Mastra` instance.
+Keep defining workflows with [`createWorkflow()`](https://mastra.ai/docs/workflows/overview) when the workflow belongs in your application source or needs custom step functions. Dynamic workflows can invoke agents, tools, and workflows that are already registered on the `Mastra` instance.
 
 ## Quickstart
 
-The following example registers a tool and invokes it from a stored workflow. It then runs the workflow. `LibSQLStore` persists the definition in `mastra.db`, so Mastra can restore it after a restart.
+The following example registers a tool and invokes it from a dynamic workflow. It then runs the workflow. `LibSQLStore` persists the definition in `mastra.db`, so Mastra can restore it after a restart.
 
 ```typescript
 import { Mastra } from '@mastra/core/mastra'
@@ -46,7 +46,7 @@ const mastra = new Mastra({
   tools: { 'create-greeting': greetingTool },
 })
 
-await mastra.addStoredWorkflow({
+await mastra.addDynamicWorkflow({
   id: 'greeting-workflow',
   description: 'Create a greeting for the supplied name',
   inputSchema: {
@@ -83,9 +83,9 @@ if (result.status === 'success') {
 }
 ```
 
-The workflow prints `Hello, Ada!`. Calling [`addStoredWorkflow()`](https://mastra.ai/reference/core/addStoredWorkflow) validates the definition before it changes storage or the live workflow registry.
+The workflow prints `Hello, Ada!`. Calling [`addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow) validates the definition before it changes storage or the live workflow registry.
 
-The definition uses JSON Schema because it must survive a JSON round trip. The `graph` describes which registered components to invoke and how data moves between them. See the [stored workflow definition reference](https://mastra.ai/reference/workflows/stored-workflow-definition) for every field and graph entry.
+The definition uses JSON Schema because it must survive a JSON round trip. The `graph` describes which registered components to invoke and how data moves between them. See the [dynamic workflow definition reference](https://mastra.ai/reference/workflows/dynamic-workflow-definition) for every field and graph entry.
 
 ## Build and update definitions
 
@@ -93,54 +93,54 @@ A definition can come from any source that produces JSON. For example, an API ro
 
 ```typescript
 const definition = await request.json()
-await mastra.addStoredWorkflow(definition)
+await mastra.addDynamicWorkflow(definition)
 ```
 
 ### Register dependencies first
 
-Register referenced components on the same `Mastra` instance before adding the stored workflow. Agent and nested workflow entries use their intrinsic IDs. A tool entry uses its key from the `Mastra` `tools` object, so the quickstart registers the tool under `create-greeting` before referencing that key with `toolId`.
+Register referenced components on the same `Mastra` instance before adding the dynamic workflow. Agent and nested workflow entries use their intrinsic IDs. A tool entry uses its key from the `Mastra` `tools` object, so the quickstart registers the tool under `create-greeting` before referencing that key with `toolId`.
 
-Use a `mapping` entry when one step's output doesn't match the next step's input. Mapping entries can read data from the workflow input and previous step results, along with workflow state and request context. The [definition reference](https://mastra.ai/reference/workflows/stored-workflow-definition) lists the supported mapping descriptors.
+Use a `mapping` entry when one step's output doesn't match the next step's input. Mapping entries can read data from the workflow input and previous step results, along with workflow state and request context. The [definition reference](https://mastra.ai/reference/workflows/dynamic-workflow-definition) lists the supported mapping descriptors.
 
 ### Replace a workflow
 
 Add a new definition with the same `id` to replace the persisted definition and live registration:
 
 ```typescript
-await mastra.addStoredWorkflow(updatedDefinition)
+await mastra.addDynamicWorkflow(updatedDefinition)
 ```
 
 New runs use the updated graph. Runs that already started continue with their original graph.
 
 ### Add nested workflows together
 
-When a root workflow references helper workflows that aren't registered yet, add the full set with [`addStoredWorkflows()`](https://mastra.ai/reference/core/addStoredWorkflows):
+When a root workflow references helper workflows that aren't registered yet, add the full set with [`addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows):
 
 ```typescript
-await mastra.addStoredWorkflows([rootDefinition, helperDefinition])
+await mastra.addDynamicWorkflows([rootDefinition, helperDefinition])
 ```
 
 Mastra validates the bundle as a unit and determines the registration order from the dependencies. If validation fails, none of the definitions are registered.
 
 ### Manage definitions over HTTP
 
-Applications don't need direct access to the `Mastra` instance to manage stored workflows. Use one of these interfaces:
+Applications don't need direct access to the `Mastra` instance to manage dynamic workflows. Use one of these interfaces:
 
-- [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows): Call `upsertStoredWorkflow()` from a JavaScript or TypeScript client.
+- [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows): Call `upsertDynamicWorkflow()` from a JavaScript or TypeScript client.
 - [Server routes](https://mastra.ai/reference/server/routes): Send definitions to `POST /api/stored/workflows`.
 
-On authenticated servers, stored-workflow management requires the `stored-workflows:read` and `stored-workflows:write` permissions. Running the registered workflow requires `workflows:execute`.
+On authenticated servers, dynamic-workflow management requires the `stored-workflows:read` and `stored-workflows:write` permissions. Running the registered workflow requires `workflows:execute`.
 
 ### Persist definitions
 
 Stored definitions use the `workflowDefinitions` storage domain. On startup, Mastra loads active definitions from storage and registers them in dependency order.
 
-Without a storage adapter that supports this domain, `addStoredWorkflow()` still registers the workflow in memory, but the definition is lost when the process restarts. See the [storage reference](https://mastra.ai/reference/storage/overview) for adapter support.
+Without a storage adapter that supports this domain, `addDynamicWorkflow()` still registers the workflow in memory, but the definition is lost when the process restarts. See the [storage reference](https://mastra.ai/reference/storage/overview) for adapter support.
 
 ## Related
 
-- [Stored workflow definition](https://mastra.ai/reference/workflows/stored-workflow-definition)
-- [`Mastra.addStoredWorkflow()`](https://mastra.ai/reference/core/addStoredWorkflow)
-- [`Mastra.addStoredWorkflows()`](https://mastra.ai/reference/core/addStoredWorkflows)
+- [Dynamic workflow definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition)
+- [`Mastra.addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow)
+- [`Mastra.addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows)
 - [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows)
 - [Server routes](https://mastra.ai/reference/server/routes)

package/.docs/guides/voice/realtime-voice.md

@@ -378,12 +378,38 @@ Tracing is on by default. Pass `observability: false` to `createLiveKitWorker` t
 
 ## Deployment
 
-The worker is a separate process from your Mastra server. Deploy it as a long-running Node service with the production command:
+The worker is a separate process from your Mastra server, so `mastra build` needs to emit it as its own entry. Add it to [`bundler.entries`](https://mastra.ai/reference/configuration):
+
+```typescript
+import { Mastra } from '@mastra/core'
+
+export const mastra = new Mastra({
+  bundler: {
+    entries: { 'voice-worker': './voice-worker.ts' },
+    // Keep LiveKit's native modules out of the bundle. `mastra build` only applies
+    // this default when you set no other bundler options, so set it explicitly here.
+    externals: true,
+  },
+})
+```
+
+`mastra build` now writes both processes into `.mastra/output`, sharing one `package.json` and one dependency install:
+
+```text
+.mastra/output/
+  index.mjs         # Mastra server
+  voice-worker.mjs  # LiveKit worker
+```
+
+Deploy that directory as a single artifact and start each process with its own command:
 
 ```bash
-node dist/voice-worker.js start
+node .mastra/output/index.mjs             # server
+node .mastra/output/voice-worker.mjs start # worker
 ```
 
+The worker needs the same environment variables as the server, plus `LIVEKIT_URL`, `LIVEKIT_API_KEY`, and `LIVEKIT_API_SECRET`.
+
 LiveKit's guidance on sizing, graceful shutdown, and hosting applies unchanged. See [Deploying agents](https://docs.livekit.io/agents/ops/deployment/). Workers connect outbound to LiveKit, so they don't need inbound ports.
 
 ## How it works

package/.docs/reference/agents/channels.md

@@ -102,6 +102,8 @@ const agent = new Agent({
 
 **streaming** (`boolean | { updateIntervalMs?: number }`): Stream agent text deltas to the channel as the agent generates them instead of buffering and posting once per step. Requires the underlying adapter to support post-and-edit streaming. Slack defaults to true; other adapters default to false. (Default: `false (true for Slack)`)
 
+**textFormat** (`'markdown' | 'plain'`): Dialect for the agent's final reply text. 'markdown' (the default) posts replies as markdown: adapters with native markdown rendering (Slack) render it directly, others convert it to their platform format. 'plain' posts replies as literal plain text, restoring the pre-markdown behavior for agents prompted to emit a platform dialect such as Slack mrkdwn. Applies to final reply text only; tool cards, error messages, and tripwire notices are unaffected. Native streaming is always markdown regardless of this setting. (Default: `'markdown'`)
+
 **toolDisplay** (`'cards' | 'text' | 'timeline' | 'grouped' | 'hidden' | ToolDisplayFn`): How tool calls are rendered in the channel. "cards" posts per-tool running/result cards as rich Block Kit. "text" posts the same lifecycle as plain text (no Block Kit). "timeline" and "grouped" stream tool state as inline task\_update chunks (requires streaming: true; Slack only today — other adapters may render a placeholder). "hidden" executes tools silently. Pass a function to render tool events yourself; return { kind: "post", message } for a discrete post/edit, { kind: "stream", chunk } to push into the streaming widget, or undefined to skip rendering that event. Add openIfEmpty: false to a stream result when its chunk should only apply to an active streaming session. Approve/deny prompts always render as a separate card regardless of mode. (Default: `'cards' ('grouped' for Slack)`)
 
 **typingStatus** (`boolean | ((chunk: AgentChunkType, ctx: TypingStatusContext) => string | false | null | undefined | void)`): Control the platform typing indicator. true uses built-in defaults (is typing… on text, is calling {tool}… on tool-call, is waiting for approval… on tool-call-approval). false suppresses typing entirely — useful when a live streaming widget (e.g. toolDisplay: "grouped" in Slack) already conveys progress. Pass a function to set custom status copy per chunk; return a string to set the status, or false/null/undefined to leave it unchanged. Compose with defaultTypingStatus (exported from @mastra/core/channels) to fall back to defaults for chunks you don't handle. (Default: `true`)

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

@@ -53,6 +53,8 @@ await slack.configure({
 
 **streaming** (`StreamingConfig | false`): Stream agent text deltas to Slack as they're generated. Pass { updateIntervalMs } to customize the post-and-edit interval, or false to buffer text until step-finish. Disabling streaming restricts toolDisplay to static modes. (Default: `true`)
 
+**textFormat** (`'markdown' | 'plain'`): Dialect for the agent's final reply text, forwarded to the Slack adapter. 'markdown' (the default) posts replies as markdown so Slack renders bold text, links, and tables natively. 'plain' posts literal plain text, the escape hatch for agents prompted to emit Slack mrkdwn. Applies to buffered replies (streaming: false) and the streaming fallback; native streaming is always markdown. (Default: `'markdown'`)
+
 **toolDisplay** (`ToolDisplay`): How tool calls are rendered in Slack: 'cards', 'text', 'timeline', 'grouped', 'hidden', or a function. 'hidden' suppresses tool call/result rendering entirely. 'timeline' and 'grouped' require streaming. With streaming: false, only static modes are available and the default is 'cards'. (Default: `'grouped'`)
 
 **typingStatus** (`boolean | TypingStatusFn`): Show a typing indicator while the agent works. Set false to disable, or pass a function to return custom status text per stream chunk (return undefined to fall back to the default for that chunk). (Default: `true`)

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

@@ -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:** Dynamic workflows are in 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/configuration.md

@@ -500,6 +500,31 @@ 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[]`\

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:** Dynamic workflows are in 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`): 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:** Dynamic workflows are in 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[]`): 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/editor/tool-provider.md

@@ -83,7 +83,32 @@ Composio tools use uppercase slug format: `GITHUB_CREATE_ISSUE`, `SLACK_SEND_MES
 
 ### Authentication
 
-Connections use per-author scope by default. Set `defaultScope: 'caller-supplied'` to bucket authorization by the caller identity resolved from request context.
+Connections use per-author scope by default. Set `defaultScope: 'caller-supplied'` to bucket authorization by the caller identity resolved from `MASTRA_RESOURCE_ID_KEY` in request context. Ensure each authenticated request provides a stable, unique resource ID. When using `MastraAuthWorkos`, configure `mapUserToResourceId` to set this value from the authenticated user.
+
+### Connection management tools
+
+Composio provides tools for starting and monitoring authorization from an agent chat. When `allowedToolkits` is set, include `composio` to make these tools available:
+
+```typescript
+const editor = new MastraEditor({
+  toolProviders: {
+    composio: new ComposioToolProvider({
+      apiKey: process.env.COMPOSIO_API_KEY!,
+      allowedToolkits: ['composio', 'gmail'],
+      defaultScope: 'caller-supplied',
+    }),
+  },
+})
+```
+
+Add only the connection management tools that the agent needs:
+
+| Tool                            | Behavior                                                                     |
+| ------------------------------- | ---------------------------------------------------------------------------- |
+| `COMPOSIO_MANAGE_CONNECTIONS`   | Creates an authorization link in chat through a session owned by the caller. |
+| `COMPOSIO_WAIT_FOR_CONNECTIONS` | Waits for the caller to finish authorization before the agent continues.     |
+
+`COMPOSIO_WAIT_FOR_CONNECTIONS` is optional. Without it, complete authorization and return to the chat. Then ask the agent to continue. The connected account remains associated with the caller resource ID for later requests.
 
 ***
 

package/.docs/reference/index.md

@@ -82,9 +82,9 @@ The Reference section provides documentation of Mastra's API, including paramete
 - [createCodingAgent()](https://mastra.ai/reference/coding-agent/create-coding-agent)
 - [Mastra Class](https://mastra.ai/reference/core/mastra-class)
 - [MastraModelGateway](https://mastra.ai/reference/core/mastra-model-gateway)
+- [.addDynamicWorkflow()](https://mastra.ai/reference/core/addDynamicWorkflow)
+- [.addDynamicWorkflows()](https://mastra.ai/reference/core/addDynamicWorkflows)
 - [.addGateway()](https://mastra.ai/reference/core/addGateway)
-- [.addStoredWorkflow()](https://mastra.ai/reference/core/addStoredWorkflow)
-- [.addStoredWorkflows()](https://mastra.ai/reference/core/addStoredWorkflows)
 - [.getAgent()](https://mastra.ai/reference/core/getAgent)
 - [.getAgentById()](https://mastra.ai/reference/core/getAgentById)
 - [.getDeployer()](https://mastra.ai/reference/core/getDeployer)
@@ -366,9 +366,9 @@ The Reference section provides documentation of Mastra's API, including paramete
 - [.speak()](https://mastra.ai/reference/voice/voice.speak)
 - [.updateConfig()](https://mastra.ai/reference/voice/voice.updateConfig)
 - [Overview](https://mastra.ai/reference/workers/overview)
+- [Dynamic Workflow Definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition)
 - [Run Class](https://mastra.ai/reference/workflows/run)
 - [Step Class](https://mastra.ai/reference/workflows/step)
-- [Stored Workflow Definition](https://mastra.ai/reference/workflows/stored-workflow-definition)
 - [Workflow Class](https://mastra.ai/reference/workflows/workflow)
 - [Workflow State Reader](https://mastra.ai/reference/workflows/workflow-state-reader)
 - [.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent)

package/.docs/reference/server/routes.md

@@ -197,18 +197,18 @@ The `/api/workflows/run-counts` endpoint returns counts of `running` and [`suspe
 }
 ```
 
-### Stored workflows
+### Dynamic workflows
 
-Stored workflow definitions (beta) are workflows expressed as JSON, persisted through the `workflowDefinitions` storage domain, and live-registered on the running instance. See [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows).
+Dynamic workflow definitions (beta) are workflows expressed as JSON, persisted through the `workflowDefinitions` storage domain, and live-registered on the running instance. See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows).
 
-| Method   | Path                                      | Description                                                                    |
-| -------- | ----------------------------------------- | ------------------------------------------------------------------------------ |
-| `GET`    | `/api/stored/workflows`                   | List stored workflow definitions, filterable by `status` and `authorId`        |
-| `GET`    | `/api/stored/workflows/:storedWorkflowId` | Get a stored workflow definition by ID                                         |
-| `POST`   | `/api/stored/workflows`                   | Upsert a definition (plus optional helper `dependencies`) and live-register it |
-| `DELETE` | `/api/stored/workflows/:storedWorkflowId` | Delete a stored definition and unregister the live workflow                    |
+| Method   | Path                                       | Description                                                                    |
+| -------- | ------------------------------------------ | ------------------------------------------------------------------------------ |
+| `GET`    | `/api/stored/workflows`                    | List dynamic workflow definitions, filterable by `status` and `authorId`       |
+| `GET`    | `/api/stored/workflows/:dynamicWorkflowId` | Get a dynamic workflow definition by ID                                        |
+| `POST`   | `/api/stored/workflows`                    | Upsert a definition (plus optional helper `dependencies`) and live-register it |
+| `DELETE` | `/api/stored/workflows/:dynamicWorkflowId` | Delete a dynamic workflow definition and unregister the live workflow          |
 
-On authenticated servers, the read routes require the `stored-workflows:read` permission and the write routes require `stored-workflows:write`. Registered stored workflows are executed through the ordinary `/api/workflows/:workflowId` routes above.
+On authenticated servers, the read routes require the `stored-workflows:read` permission and the write routes require `stored-workflows:write`. Registered dynamic workflows are executed through the ordinary `/api/workflows/:workflowId` routes above.
 
 ### Create run request body
 

package/.docs/reference/storage/overview.md

@@ -10,15 +10,15 @@ Mastra storage is organized into domains. Each domain owns a set of tables or co
 
 Not every storage adapter implements every domain. Composite storage lets you mix adapters per domain when the adapter packages export the corresponding domain classes.
 
-| Domain                | Description                                                                                                                            |
-| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `memory`              | Conversation persistence: messages, threads, and resources (including working memory).                                                 |
-| `workflows`           | Workflow run snapshots used for suspend and resume.                                                                                    |
-| `workflowDefinitions` | Persisted [stored workflow](https://mastra.ai/docs/workflows/stored-workflows) definitions (beta). Loaded and live-registered on boot. |
-| `scores`              | Evaluation score records from eval runs.                                                                                               |
-| `observability`       | Traces and spans used by observability exporters and Studio.                                                                           |
-| `datasets`            | Dataset records, versioned items, and dataset versions used by experiments.                                                            |
-| `experiments`         | Experiment runs and per-item experiment results.                                                                                       |
+| Domain                | Description                                                                                                                              |
+| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| `memory`              | Conversation persistence: messages, threads, and resources (including working memory).                                                   |
+| `workflows`           | Workflow run snapshots used for suspend and resume.                                                                                      |
+| `workflowDefinitions` | Persisted [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows) definitions (beta). Loaded and live-registered on boot. |
+| `scores`              | Evaluation score records from eval runs.                                                                                                 |
+| `observability`       | Traces and spans used by observability exporters and Studio.                                                                             |
+| `datasets`            | Dataset records, versioned items, and dataset versions used by experiments.                                                              |
+| `experiments`         | Experiment runs and per-item experiment results.                                                                                         |
 
 The schema definitions below cover the built-in database-backed tables documented for `memory`, `workflows`, `scores`, and `observability`. Other domains, and non-database adapters, use implementation-specific storage structures.
 

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

@@ -92,7 +92,7 @@ Each domain declares which of its tables can be age-pruned and which timestamp c
 > - Experiments prune as whole units: an aged experiment's result rows are deleted together with it (results cascade with their parent), so a run is never left partially deleted. Retention doesn't have a separate `results` key.
 > - For `schedules`, the growth table is the fire history (`schedule_triggers`, one row per fire): schedule definitions are config and aren't pruned.
 > - On PostgreSQL, timestamp anchors use the timezone-aware mirror columns (for example `createdAtZ`, `completedAtZ`).
-> - LibSQL supports all domains above; PostgreSQL and MongoDB support all except `threadState` and `harness`, which they don't implement.
+> - LibSQL and PostgreSQL support all domains above except `harness`, which PostgreSQL doesn't implement. MongoDB supports all except `threadState` and `harness`.
 > - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
 
 ## Methods

package/.docs/reference/workflows/{stored-workflow-definition.md → dynamic-workflow-definition.md}

@@ -1,12 +1,12 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Stored workflow definition
+# Dynamic workflow definition
 
-> **Beta:** Stored workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Dynamic workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
 
-A stored workflow definition is a JSON-compatible `StoredWorkflowGraph` accepted by [`Mastra.addStoredWorkflow()`](https://mastra.ai/reference/core/addStoredWorkflow), the stored-workflow server routes, and the Client SDK workflows API.
+A dynamic workflow definition is a JSON-compatible `DynamicWorkflowGraph` accepted by [`Mastra.addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow), the stored-workflow server routes, and the Client SDK workflows API.
 
-See [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows) for a complete setup and usage example.
+See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) for a complete setup and usage example.
 
 ## Definition fields
 
@@ -286,7 +286,7 @@ Validation errors include a dotted path, such as `graph.2.steps.0`, that identif
 
 ## Related
 
-- [Use stored workflows](https://mastra.ai/docs/workflows/stored-workflows)
-- [`Mastra.addStoredWorkflow()`](https://mastra.ai/reference/core/addStoredWorkflow)
-- [`Mastra.addStoredWorkflows()`](https://mastra.ai/reference/core/addStoredWorkflows)
+- [Use dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows)
+- [`Mastra.addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow)
+- [`Mastra.addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows)
 - [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows)

package/.docs/reference/workflows/workflow-methods/agent.md

@@ -4,7 +4,7 @@
 
 The `.agent()` method adds an agent as a declarative step. The step accepts `{ prompt: string }` as input and returns `{ text: string }` by default. Use `.map()` before the agent to build the prompt from workflow data.
 
-Unlike wrapping an agent with `createStep()`, `.agent()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [stored workflow](https://mastra.ai/docs/workflows/stored-workflows).
+Unlike wrapping an agent with `createStep()`, `.agent()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows).
 
 ## Usage example
 
@@ -53,10 +53,10 @@ workflow.agent("test-agent", { maxSteps: 3 }).commit();
 
 ## Persisting agent steps
 
-Workflows built with `.agent()` serialize to the same declarative entries that [stored workflows](https://mastra.ai/docs/workflows/stored-workflows) use. Only `retries` and `metadata` round-trip through storage. Options that hold functions, such as `onFinish` or a function-valued `toolChoice`, throw an error when the workflow is stored.
+Workflows built with `.agent()` serialize to the same declarative entries that [dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) use. Only `retries` and `metadata` round-trip through storage. Options that hold functions, such as `onFinish` or a function-valued `toolChoice`, throw an error when the workflow is stored.
 
 ## Related
 
 - [Agents and Tools](https://mastra.ai/docs/workflows/agents-and-tools)
-- [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows)
+- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows)
 - [Workflow.tool()](https://mastra.ai/reference/workflows/workflow-methods/tool)

package/.docs/reference/workflows/workflow-methods/tool.md

@@ -4,7 +4,7 @@
 
 The `.tool()` method adds a tool as a declarative step. The tool's own input and output schemas apply, so the previous step's output must satisfy the tool's input schema. Use `.map()` to transform the data if they don't match.
 
-Unlike wrapping a tool with `createStep()`, `.tool()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [stored workflow](https://mastra.ai/docs/workflows/stored-workflows).
+Unlike wrapping a tool with `createStep()`, `.tool()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows).
 
 ## Usage example
 
@@ -34,10 +34,10 @@ workflow.tool("lookup-customer", { retries: 2 }).commit();
 
 ## Persisting tool steps
 
-Workflows built with `.tool()` serialize to the same declarative entries that [stored workflows](https://mastra.ai/docs/workflows/stored-workflows) use. Only `retries` and `metadata` round-trip through storage. A function-valued `scorers` option throws an error when the workflow is stored.
+Workflows built with `.tool()` serialize to the same declarative entries that [dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) use. Only `retries` and `metadata` round-trip through storage. A function-valued `scorers` option throws an error when the workflow is stored.
 
 ## Related
 
 - [Agents and Tools](https://mastra.ai/docs/workflows/agents-and-tools)
-- [Stored workflows](https://mastra.ai/docs/workflows/stored-workflows)
+- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows)
 - [Workflow.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent)

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # @mastra/mcp-docs-server
 
+## 1.2.15-alpha.8
+
+### Patch Changes
+
+- Updated dependencies [[`6445eba`](https://github.com/mastra-ai/mastra/commit/6445eba6020abac681aba1cc9289f446cb400cbe), [`df31eb0`](https://github.com/mastra-ai/mastra/commit/df31eb0c7087d782a0d9346e467f9a4af4b0eef6), [`fcd0667`](https://github.com/mastra-ai/mastra/commit/fcd0667a4e378be35c9a1b1eb19cce78fbfd7282), [`bab06b1`](https://github.com/mastra-ai/mastra/commit/bab06b18923873a584bdfc71a6b4ec7fb4727fb7)]:
+  - @mastra/core@1.58.0-alpha.5
+
+## 1.2.15-alpha.7
+
+### Patch Changes
+
+- Updated dependencies [[`76e5132`](https://github.com/mastra-ai/mastra/commit/76e51328dbc0749c8304e6b3f21e4401f451b081), [`0282e16`](https://github.com/mastra-ai/mastra/commit/0282e16115538c8e9b248b90f0748eb01cb5dc98)]:
+  - @mastra/core@1.58.0-alpha.4
+
 ## 1.2.15-alpha.6
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/mcp-docs-server",
-  "version": "1.2.15-alpha.6",
+  "version": "1.2.15-alpha.9",
   "description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
   "type": "module",
   "main": "dist/index.js",
@@ -28,8 +28,8 @@
     "jsdom": "^26.1.0",
     "local-pkg": "^1.1.2",
     "zod": "^4.4.3",
-    "@mastra/mcp": "^1.16.0-alpha.1",
-    "@mastra/core": "1.58.0-alpha.3"
+    "@mastra/core": "1.58.0-alpha.5",
+    "@mastra/mcp": "^1.16.0-alpha.1"
   },
   "devDependencies": {
     "@hono/node-server": "^2.0.0",
@@ -45,9 +45,9 @@
     "tsx": "^4.23.1",
     "typescript": "^6.0.3",
     "vitest": "4.1.10",
-    "@internal/lint": "0.0.121",
-    "@mastra/core": "1.58.0-alpha.3",
-    "@internal/types-builder": "0.0.96"
+    "@internal/types-builder": "0.0.96",
+    "@mastra/core": "1.58.0-alpha.5",
+    "@internal/lint": "0.0.121"
   },
   "homepage": "https://mastra.ai",
   "repository": {