@mastra/mcp-docs-server 1.1.49-alpha.2 → 1.2.0-alpha.0

package/.docs/docs/harness/modes.md

@@ -1,10 +1,16 @@
 # Modes
 
-Modes define the different personalities or capability sets available within a Harness. Each mode layers its own instructions and tool overrides on top of a shared backing agent. The Harness ensures only one mode is active at a time and handles transitions between them.
+Modes define the different behaviors a Harness can run. Each mode layers its own instructions and tool overrides on top of a shared backing agent, so the same agent can act as a planner in one mode and an executor in another. The Harness keeps exactly one mode active at a time, carries the thread and state across switches, and handles the transition between them.
 
-## When to use modes
+Every Harness needs at least one mode — the `modes` array is required, and the Harness throws at construction if it's empty. A single-purpose Harness still defines one mode; multiple modes are how you give a session more than one behavior to switch between.
 
-Use modes when a single conversational session needs to switch between distinct behaviors. For example, a planning mode that reasons about tasks and a build mode that executes them. Modes share the same thread and state, so the agent retains context across switches.
+A mode supplies three things that change how the agent behaves:
+
+- **Instructions**: layered on top of the backing agent's own instructions while the mode is active.
+- **Tools**: either replacing or adding to the backing agent's tools (see [Mode tool overrides](#mode-tool-overrides)).
+- **Model**: an optional `defaultModelId` to bootstrap model selection when the session enters the mode.
+
+Because every mode shares the same backing agent, thread, and state, switching modes changes how the agent behaves without losing conversation context.
 
 ## Quickstart
 
@@ -98,6 +104,8 @@ await harness.switchMode({ modeId: 'build' })
 
 ## Querying modes
 
+The Harness exposes the full mode catalog, while the Session tracks which mode is active. Use `harness.listModes()` to read every configured mode, `harness.session.mode.get()` for the active mode ID, and `harness.session.mode.resolve()` for the active mode's full definition:
+
 ```typescript
 // List all configured modes
 const modes = harness.listModes()

package/.docs/docs/harness/overview.md

@@ -10,14 +10,15 @@ A Harness exposes a [`Session`](https://mastra.ai/docs/harness/session) — the
 
 ## What you can build
 
-The Harness is designed for applications where a user has an ongoing, interactive session with one or more AI agents:
+The Harness gives you the runtime pieces to ship interactive agent applications. Each outcome below maps to a capability you can use today:
 
-| Application                    | How the Harness helps                                                                                                                                                                              |
-| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Coding agents** (TUI or IDE) | Plan mode reasons about changes, build mode executes them. Thread persistence resumes conversations across sessions. Tool approvals gate destructive operations like file writes.                  |
-| **Multi-step assistants**      | A research mode gathers information, a drafting mode produces output. Shared state tracks progress. Subagents handle focused subtasks (e.g., web search, code review).                             |
-| **Copilot UIs**                | Model switching lets users pick the right model for the job. Permission policies control which tools run automatically vs. requiring confirmation. Event subscriptions drive real-time UI updates. |
-| **Autonomous task runners**    | Background agents with structured task lists, heartbeat handlers for health checks, and observational memory for learning across threads.                                                          |
+- **Resume a conversation exactly where the user left off.** Persistent [threads and state](https://mastra.ai/docs/harness/threads-and-state) reload the active mode, model, and progress across restarts, so a coding agent or assistant picks up mid-task instead of starting over.
+- **Gate destructive actions behind human approval.** [Tool approvals and permission policies](https://mastra.ai/docs/harness/tool-approvals) let you require confirmation for risky operations like file writes or deployments, while trusted tools run automatically.
+- **Move a task through distinct phases without losing context.** [Modes](https://mastra.ai/docs/harness/modes) switch the agent's instructions, tools, and model on the same thread, so you can build a plan-then-execute coding agent or a research-then-draft assistant.
+- **Let users pick the right model for each step.** Per-mode [model management](https://mastra.ai/reference/harness/harness-class) switches models at runtime and tracks usage, which powers copilot UIs where users trade speed for capability.
+- **Delegate focused work to child agents.** [Subagents](https://mastra.ai/docs/harness/subagents) run subtasks with constrained tools and can fork the parent conversation, so a research mode can spin off web search or code review without polluting the main thread.
+- **Drive a live UI from agent activity.** The [event system](https://mastra.ai/docs/harness/session) emits typed events and coalesced display snapshots, so your TUI or web app reflects message updates, mode changes, and pending approvals in real time.
+- **Run long-lived autonomous agents.** Structured task lists, heartbeat handlers, and observational memory keep background task runners on track and let them learn across threads.
 
 ## When to use the Harness
 
@@ -29,7 +30,7 @@ Use the Harness when your application needs:
 - Subagent orchestration to delegate focused subtasks with constrained tools
 - Session continuity with persistent threads, state, and observational memory across restarts
 
-For single-shot agent calls or basic request-response patterns, use the [Agent class](https://mastra.ai/docs/agents/overview) directly. The Harness adds value when you need session state, mode switching, or interactive approval flows.
+You could assemble all of this yourself on top of the [Agent class](https://mastra.ai/docs/agents/overview), which exposes the full agent loop, tools, and memory. The Harness is an opinionated set of defaults that wires those pieces into one application style: an ongoing session where the agent acts as a collaborator rather than a one-shot endpoint. Reach for the Agent class directly when you want full control or a simple request-response call; reach for the Harness when you want the collaborative-session model without building the runtime around it.
 
 ## Key capabilities
 
@@ -38,10 +39,10 @@ For single-shot agent calls or basic request-response patterns, use the [Agent c
 - **Threads and state**: Persist conversations and structured state across sessions, users, and mode switches. See [Threads and state](https://mastra.ai/docs/harness/threads-and-state).
 - **Subagents**: Spawn focused child agents with constrained tools for subtasks, optionally forking the parent conversation. See [Subagents](https://mastra.ai/docs/harness/subagents).
 - **Tool approvals and permissions**: Configure which tools require user confirmation, grant session-wide exceptions, and handle interactive tool suspension. See [Tool approvals](https://mastra.ai/docs/harness/tool-approvals).
-- **Model management**: Switch models per-mode at runtime, track usage, and resolve gateway-backed models.
-- **Follow-ups and steering**: Queue messages while the agent is running, or inject mid-stream instructions to redirect the agent.
-- **Event system**: Subscribe to typed events (message updates, mode changes, tool approvals) or coalesced `HarnessDisplayState` snapshots to drive your UI.
-- **Observational memory**: Automatic summarization and reflection across threads for long-running agent sessions.
+- **Model management**: Switch models per-mode at runtime, track usage, and resolve gateway-backed models through Mastra's [model router](https://mastra.ai/models).
+- **Follow-ups and steering**: Queue messages while the agent is running, or inject mid-stream instructions to redirect the agent. Built on [signals](https://mastra.ai/docs/agents/signals).
+- **Event system**: Subscribe to typed events (message updates, mode changes, tool approvals) or coalesced `HarnessDisplayState` snapshots to drive your UI. See [Events](https://mastra.ai/reference/harness/harness-class).
+- **Observational memory**: Automatic summarization and reflection across threads for long-running agent sessions. See [Observational memory](https://mastra.ai/docs/memory/observational-memory).
 
 ## Quickstart
 

package/.docs/docs/harness/session.md

@@ -1,26 +1,21 @@
 # Session
 
-A `Session` holds the per-conversation state of a Harness: who the conversation is for, which thread is active, the selected mode and model, permission grants, queued follow-ups, token usage, application state, and the display snapshot. You reach it through `harness.session`.
+A [`Session`](https://mastra.ai/reference/harness/session) holds the live state of a Harness: who the session is for, which thread is active, the selected mode and model, permission grants, queued follow-ups, token usage, application state, and the display snapshot. You reach it through `harness.session`.
 
-## Harness vs. Session
+## What the Session tracks
 
-The Harness is the shared host. It owns the machinery that doesn't change from one conversation to the next: configuration, storage, the agent registry, the thread lock, the event bus, and permission _policy_. The Session is the per-conversation state that sits on top of that machinery.
+The Session is the live state of a single user's interaction with the Harness. It answers "what is true right now": who the session belongs to, which thread is currently bound, which mode and model are selected, what the user has approved, what's queued or running, the application state, and the snapshot to render. A session has one active thread at a time but can list, switch between, and clone many threads over its lifetime. Anything that describes the current state lives here; the Harness owns the shared infrastructure every session runs on.
 
-A useful way to remember the split: the **Harness** is the application, and the **Session** is the current conversation running inside it. Operations that mutate shared infrastructure or coordinate the event bus stay on the Harness; everything that describes "this conversation right now" lives on the Session.
+Because each session has its own identity and state, one Harness can serve many users at once — each backed by its own Session — without one session's mode, grants, or active thread leaking into another.
 
-| Lives on the Harness (shared host)                                                              | Lives on the Session (per-conversation)                                                                     |
-| ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
-| Configuration, storage, and memory                                                              | Resource ID and active thread binding ([`session.identity`](#identity), [`session.thread`](#thread))        |
-| Thread lifecycle: `createThread`, `switchThread`, `cloneThread`, `renameThread`, `deleteThread` | Thread and message reads ([`session.thread.list()`](#thread))                                               |
-| The event bus (`subscribe`, event emission)                                                     | Selected mode and model ([`session.mode`](#mode-and-model), [`session.model`](#mode-and-model))             |
-| Permission _policy_ (`setPermissionForCategory`, `getToolCategory`)                             | Permission _grants_ ([`session.grantCategory`](#permission-grants))                                         |
-| Mode and model _definitions_ (`config.modes`)                                                   | Run state, abort, follow-ups, suspensions ([`session.run`](#run-state), [`session.followUps`](#follow-ups)) |
-| The `stateSchema` definition                                                                    | Application state and its updates ([`session.state`](#state))                                               |
-| The shared agent loop and subagent spawning                                                     | Token usage and the display snapshot ([`session.displayState`](#display-state))                             |
+The rest of this page walks through the Session's state. Each part is a focused sub-object on `harness.session`:
 
-This is why thread _creation_ is `harness.createThread()` (it acquires the shared lock and emits an event) while thread _reads_ are `harness.session.thread.list()` (they describe the current conversation's view).
+- **Who and where**: [Identity](#identity) sets the resource the session belongs to, and [Thread](#thread) tracks the currently bound thread.
+- **How the agent behaves**: [Mode and model](#mode-and-model) controls which agent profile and model are active, and [Permission grants](#permission-grants) records what the user has approved to run without prompting.
+- **What's happening right now**: [Run state](#run-state) reflects the in-flight generation, and [Follow-ups](#follow-ups) holds messages queued to send when it finishes.
+- **What you store and render**: [State](#state) holds your application's structured data, and [Display state](#display-state) is the single snapshot your UI renders from.
 
-In single-player apps there is one Harness and one Session, so the split is mostly organizational. In a multi-user host, the same Harness can serve many conversations — each backed by its own Session — without one conversation's mode, grants, or active thread leaking into another.
+The Harness performs actions that change this state — switching threads, modes, or models — because those operations coordinate shared infrastructure and emit events. The Session is where you read the result. The sections below note this split where it matters.
 
 ## Identity
 
@@ -31,7 +26,7 @@ const resourceId = harness.session.identity.getResourceId()
 const threadId = harness.session.thread.getId()
 ```
 
-To change the resource a conversation operates under, use `harness.setResourceId()` — it lives on the Harness because it also clears the active thread and releases the shared lock.
+The resource ID is set on the Harness constructor and defaults to the harness `id`. See [Resource IDs](https://mastra.ai/docs/harness/threads-and-state) for how it scopes threads.
 
 ## Thread
 
@@ -94,12 +89,14 @@ harness.abort()
 
 ## Follow-ups
 
-While a run is in progress, queued follow-up messages live on `session.followUps`. They are sent when the current run finishes:
+A user may want to add to the conversation while the agent is still working. Instead of dropping or interrupting those messages, the Session queues them on `session.followUps` and sends them when the current run finishes:
 
 ```typescript
 const queued = harness.session.followUps.count()
 ```
 
+Queue a follow-up with `harness.followUp({ content })`. To redirect the agent mid-run instead of waiting, use `harness.steer({ content })`. Both build on [signals](https://mastra.ai/docs/agents/signals).
+
 ## State
 
 `session.state` holds the conversation's application state — structured values that agents and the UI share, such as model preferences, feature flags, or progress. The Harness defines the shape with a `stateSchema`; the Session owns the live snapshot, validates updates against the schema, and emits `state_changed` on every write:
@@ -113,12 +110,16 @@ See [Threads and state](https://mastra.ai/docs/harness/threads-and-state) for de
 
 ## Display state
 
-`session.displayState` is the coalesced `HarnessDisplayState` snapshot — the single object a UI renders from. It folds run status, streaming messages, active tools, tasks, token usage, and pending approvals into one place:
+A conversation emits many fine-grained events: tokens streaming in, tools starting and finishing, approvals pending, tasks updating, token usage climbing. Subscribing to each event type and reassembling the current picture yourself is tedious and error-prone. `session.displayState` does that work for you.
+
+It's a reducer-maintained snapshot. The Session keeps one `HarnessDisplayState` object and folds every harness event into it as it happens, so the snapshot always reflects the latest state. It captures everything a UI needs to render: whether the agent is running and what it's streaming, which tools and subagents are active, anything waiting on the user such as approvals, the current task list, and running totals like token usage and queued follow-ups.
+
+Because it's a single object, you can drive an entire UI from one place: read the current snapshot with `get()`, and re-render whenever the Harness emits `display_state_changed` (fired after every other event):
 
 ```typescript
 const snapshot = harness.session.displayState.get()
 
-// React to changes
+// Re-render from the snapshot on every change
 harness.subscribe(event => {
   if (event.type === 'display_state_changed') {
     render(harness.session.displayState.get())
@@ -126,6 +127,8 @@ harness.subscribe(event => {
 })
 ```
 
+This is the recommended pattern for most UIs. Subscribe to individual typed events only when you need to react to a specific transition rather than re-render the whole view.
+
 > **Note:** Visit the [Session reference](https://mastra.ai/reference/harness/session) for the full list of sub-objects and method signatures.
 
 ## Related

package/.docs/docs/harness/subagents.md

@@ -1,14 +1,6 @@
 # Subagents
 
-Subagents let a parent agent delegate focused tasks to child agents with constrained tools and instructions. The Harness auto-generates a `subagent` built-in tool that the parent model can call to spawn any configured subagent type.
-
-## When to use subagents
-
-Use subagents when:
-
-- A task needs a different toolset or instruction set than the parent agent
-- You want to isolate a subtask's messages from the parent thread
-- The parent agent needs to delegate to a cheaper or faster model for specific work
+Subagents let a parent agent delegate focused tasks to child agents with constrained tools and instructions. The Harness auto-generates a `subagent` built-in tool that the parent model can call to spawn any configured subagent type. Reach for a subagent when a task needs a different toolset or instruction set than the parent agent, when you want to isolate a subtask's messages from the parent thread, or when the parent should delegate to a cheaper or faster model for specific work.
 
 ## Quickstart
 
@@ -52,11 +44,17 @@ const harness = new Harness({
 
 The parent agent can then call the auto-generated `subagent` tool with a `task` description and optional `agentType`.
 
+When you define a subagent, write its `description` and `instructions` to be clear and narrow. The `description` is what the parent model reads to decide _when_ to delegate, so state the single job the subagent is for and, by implication, what it's not for — "Reads files and gathers context without making changes" tells the parent to reach for it during exploration and to handle edits elsewhere. The `instructions` then keep the child agent inside that job. A subagent scoped to one task with a focused toolset stays predictable and is easier for the parent to route to; a broadly described subagent invites the parent to over-delegate and blurs the boundary between types. Pair the narrow scope with `allowedWorkspaceTools` so the subagent can only do what its description promises.
+
 For the full list of subagent configuration options, see [`Harness` reference](https://mastra.ai/reference/harness/harness-class).
 
 ## Forked subagents
 
-By default, a subagent runs with a fresh context and doesn't see the parent conversation. **Forked subagents** run on a clone of the parent thread and reuse the parent agent's configuration. This preserves prompt-cache prefixes and gives the subagent full conversation context.
+A default subagent starts with a fresh context: it can't see the parent conversation, so you pass everything it needs in the `task` description. That's the right model for self-contained work, but it has two costs. The subagent has no access to what's already happened, and it builds a brand-new request prefix — a different system prompt and tool schemas — so it can't reuse the parent's prompt cache.
+
+**Forked subagents** solve both. Instead of a fresh agent, a fork clones the parent thread and runs the parent agent itself, so it sees the full conversation history and keeps the same system prompt and tool schemas as the parent. The identical prefix means the model's prompt cache still hits, which makes context-heavy delegation cheaper and faster.
+
+Use a fork when the subtask depends on the conversation so far — prior messages, earlier tool results, or the parent's tool environment — and you want to run it without paying to rebuild that context. Use a default subagent when the task is self-contained and benefits from a narrower toolset, a tighter system prompt, or a cheaper model.
 
 Enable forked mode per-type:
 
@@ -65,24 +63,21 @@ const collaborator = {
   id: 'collaborator',
   name: 'Collaborator',
   description: 'Continues the conversation in a fork.',
-  instructions: '...', // Ignored in forked mode
   forked: true,
 }
 ```
 
-Or per-invocation via the `subagent` tool's `forked` input parameter.
+Or per-invocation via the `subagent` tool's `forked` input parameter, which overrides the type's default.
 
 ### Forked mode semantics
 
-- Memory must be configured on the Harness (forking clones the thread)
-- The parent agent's instructions, tools, model, and `maxSteps` apply
-- The subagent definition's own `instructions`, `tools`, and `defaultModelId` are ignored
-- Fork threads are tagged with `metadata.forkedSubagent === true` and hidden from `session.thread.list()` by default
-- Recursive forks are blocked at runtime to prevent infinite nesting
-
-### When to prefer non-forked mode
+Because a fork reuses the parent agent to keep the prompt prefix stable, the subagent's own definition is mostly set aside:
 
-Use non-forked subagents when the child needs a strictly smaller toolset, a different system prompt, or a cheaper model. Pass any required context explicitly in the `task` description.
+- Memory must be configured on the Harness, since forking clones the parent thread. Without it, the fork call returns an error.
+- The fork runs with the parent agent's instructions, tools, and model. The subagent definition's own `instructions`, `tools`, and `defaultModelId` are ignored, and a per-invocation `modelId` is ignored too.
+- Only the subagent definition's `description` still matters — it's what the parent model reads to decide when to delegate.
+- Fork threads are tagged with `metadata.forkedSubagent === true` and hidden from `session.thread.list()` by default.
+- Recursive forks are blocked at runtime: the inherited `subagent` tool is disabled inside a fork to prevent infinite nesting.
 
 ## Subagent model management
 

package/.docs/docs/harness/threads-and-state.md

@@ -1,15 +1,15 @@
 # Threads and state
 
-The Harness manages conversation threads and shared state that persist across mode switches, model changes, and sessions. Threads hold messages while state holds structured data that agents and the UI can read and write.
+Threads and state are how a Harness conversation survives beyond a single exchange. A **thread** is the persistent record of a conversation — its messages and metadata, saved to storage so a user can close the app and resume the same conversation later, or switch between several conversations. **State** is structured data attached to the conversation — values like model preferences, feature flags, or progress — that agents and your UI read and write as the conversation runs.
 
-Thread _lifecycle_ transitions (create, switch, clone, delete) live on the Harness because they coordinate the shared thread lock and emit events. The active thread binding and thread/message _reads_ live on the [`Session`](https://mastra.ai/docs/harness/session) as `harness.session.thread`.
+The two work together: the thread is the message history, and state is the shared scratchpad alongside it. Both persist across mode switches, model changes, and restarts, so nothing is lost when a user switches from plan mode to build mode or reopens the app the next day.
 
-## When to use threads and state
-
-Use threads when your application needs persistent conversation history, multi-session continuity, or when users switch between threads. Use state for structured values (model preferences, feature flags, UI settings) that agents and the UI layer share.
+Thread _lifecycle_ transitions — create, switch, clone, delete — live on the Harness because they coordinate the shared thread lock and emit events. The active thread binding and thread/message _reads_ live on the [`Session`](https://mastra.ai/docs/harness/session) as `harness.session.thread`.
 
 ## Threads
 
+A thread holds one conversation's full message history. The Harness binds the Session to one active thread at a time; messages you send and the agent's replies are appended to that thread and saved to storage. Threads let users resume a past conversation, keep several conversations side by side, or branch one into alternatives.
+
 ### Creating and selecting threads
 
 On startup, call `selectOrCreateThread()` to resume the most recent thread or create a new one:
@@ -72,6 +72,8 @@ const harness = new Harness({
 
 ## State
 
+Where a thread stores the conversation's messages, state stores structured values that describe the conversation but aren't messages — model preferences, feature flags, UI settings, or progress markers. Agents can read and update state during a run, and your UI can react to changes, so state is how the agent and the interface stay in sync on shared facts. You define its shape with a schema, and every update is validated against that schema before it's applied.
+
 ### Defining a state schema
 
 Pass a `stateSchema` (Standard JSON Schema) to validate state and extract defaults:
@@ -114,16 +116,19 @@ State changes emit a `state_changed` event with the new state and the set of cha
 
 ## Resource IDs
 
-Threads are scoped to a resource ID. The resource ID defaults to the harness `id` but can be set explicitly to group threads by project, user, or workspace:
+Threads are scoped to a resource ID, which groups a conversation's threads by project, user, or workspace. Set it on the Harness constructor; it defaults to the harness `id` when omitted:
 
 ```typescript
 const harness = new Harness({
   id: 'my-agent',
   resourceId: 'project-xyz',
 })
+```
+
+The resource ID is part of a conversation's identity, so you read it from the Session:
 
-// Change resource ID at runtime (clears the current thread)
-harness.setResourceId({ resourceId: 'project-abc' })
+```typescript
+const resourceId = harness.session.identity.getResourceId()
 ```
 
 ## Related

package/.docs/docs/harness/tool-approvals.md

@@ -1,10 +1,6 @@
 # Tool approvals and permissions
 
-The Harness provides a permission system that controls which tools require user approval before execution. You can configure policies at the category level or per-tool, and grant session-wide exceptions for trusted tools.
-
-## When to use tool approvals
-
-Use tool approvals when agents have access to destructive or sensitive tools (file writes, command execution, API calls) and you want a human-in-the-loop checkpoint before those tools run.
+The Harness provides a permission system that controls which tools require user approval before execution. You can configure policies at the category level or per-tool, and grant session-wide exceptions for trusted tools. This gives agents with access to destructive or sensitive tools — file writes, command execution, API calls — a human-in-the-loop checkpoint before those tools run.
 
 ## Permission policies
 

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # @mastra/mcp-docs-server
 
+## 1.2.0-alpha.0
+
+### Minor Changes
+
+- Random bump ([#18178](https://github.com/mastra-ai/mastra/pull/18178))
+
+### Patch Changes
+
+- Updated dependencies [[`7c0d868`](https://github.com/mastra-ai/mastra/commit/7c0d868d97d0fdbc04c14d0166dbf44d4c5a4a62), [`d9d2273`](https://github.com/mastra-ai/mastra/commit/d9d2273c702690c9a26eab2aebea879701d4355a), [`b04369d`](https://github.com/mastra-ai/mastra/commit/b04369d6b167c698ef103981171a8bf92808e756), [`8f3c262`](https://github.com/mastra-ai/mastra/commit/8f3c262587b335588a02d96b17fd6aca34c885b3)]:
+  - @mastra/core@1.45.0-alpha.0
+  - @mastra/mcp@1.11.0-alpha.0
+
+## 1.1.49
+
+### Patch Changes
+
+- Security remediation for the 2026-06-17 "easy-day-js" supply-chain incident. Patch bump to publish clean versions and move the `latest` dist-tag forward, superseding the compromised versions that declared the malicious `easy-day-js` dependency. ([#18056](https://github.com/mastra-ai/mastra/pull/18056))
+
+- Updated dependencies [[`339c57c`](https://github.com/mastra-ai/mastra/commit/339c57c5b2c6dbe75a125e138228e0556528976f), [`1dd4117`](https://github.com/mastra-ai/mastra/commit/1dd4117dcbd8e031ede9f0489436bfbc6f0315b8), [`2b11d1f`](https://github.com/mastra-ai/mastra/commit/2b11d1f6ac7024c5dd2b2dd12a48a956ac9d63bd), [`77a2351`](https://github.com/mastra-ai/mastra/commit/77a2351ee79296e360bce822cb3391f7cfd6489d), [`b7dff0a`](https://github.com/mastra-ai/mastra/commit/b7dff0a3d1022eb6868f48dc40a2b1febd5c277f), [`02087e1`](https://github.com/mastra-ai/mastra/commit/02087e1fbc54aa07f3071f7a200df1bf5be601a8), [`49af8df`](https://github.com/mastra-ai/mastra/commit/49af8df589c4ff71a5015a4553b377b32704b691), [`30ce559`](https://github.com/mastra-ai/mastra/commit/30ce55902ecf819b8ab8697398dd68b108228063), [`c241b92`](https://github.com/mastra-ai/mastra/commit/c241b929dc8c8d6a7b7219c99ed13ac1f3124a77), [`7d6ff70`](https://github.com/mastra-ai/mastra/commit/7d6ff708727297a0526ca0e26e93eeb5bbaaa187), [`ab975d4`](https://github.com/mastra-ai/mastra/commit/ab975d4dd9488752f05bda7afa03166d207e3e2a), [`9d6aa1b`](https://github.com/mastra-ai/mastra/commit/9d6aa1bae407e2afa6a089abc2a6accbbcb287b8)]:
+  - @mastra/core@1.44.0
+  - @mastra/mcp@1.10.1
+
 ## 1.1.49-alpha.2
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/mcp-docs-server",
-  "version": "1.1.49-alpha.2",
+  "version": "1.2.0-alpha.0",
   "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/core": "1.44.0-alpha.2",
-    "@mastra/mcp": "^1.10.1-alpha.0"
+    "@mastra/core": "1.45.0-alpha.0",
+    "@mastra/mcp": "^1.11.0-alpha.0"
   },
   "devDependencies": {
     "@hono/node-server": "^1.19.11",
@@ -45,9 +45,9 @@
     "tsx": "^4.22.4",
     "typescript": "^6.0.3",
     "vitest": "4.1.8",
-    "@internal/types-builder": "0.0.80",
-    "@internal/lint": "0.0.105",
-    "@mastra/core": "1.44.0-alpha.2"
+    "@internal/lint": "0.0.106",
+    "@mastra/core": "1.45.0-alpha.0",
+    "@internal/types-builder": "0.0.81"
   },
   "homepage": "https://mastra.ai",
   "repository": {