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

package/.docs/docs/browser/stagehand.md

@@ -146,8 +146,25 @@ const browser = new StagehandBrowser({
 
 > **Note:** See [StagehandBrowser reference](https://mastra.ai/reference/browser/stagehand-browser) for all configuration options.
 
+## Recording
+
+Stagehand can opt into alpha browser recording tools:
+
+```typescript
+const browser = new StagehandBrowser({
+  headless: false,
+  model: 'openai/gpt-5.5',
+  recording: {
+    outputDir: './browser-recordings',
+  },
+})
+```
+
+This adds `browser_record` and `browser_record_caption` to the agent's toolset. See [Browser recording (alpha)](https://mastra.ai/docs/browser/recording) for details.
+
 ## Related
 
 - [Browser overview](https://mastra.ai/docs/browser/overview)
 - [AgentBrowser](https://mastra.ai/docs/browser/agent-browser)
+- [Browser recording (alpha)](https://mastra.ai/docs/browser/recording)
 - [StagehandBrowser reference](https://mastra.ai/reference/browser/stagehand-browser)

package/.docs/docs/mastra-platform/configuration.md

@@ -6,7 +6,7 @@ This page explains both mechanisms and how they differ between Studio and Server
 
 ## Project config
 
-The `.mastra-project.json` file is auto-generated on your first Studio or Server deploy. It links your local project to a platform project.
+The `.mastra-project.json` file is auto-generated on your first Studio or Server deploy. It links your local project to a platform project. The [GitHub integration](https://mastra.ai/docs/mastra-platform/github) writes the same file into linked repositories.
 
 Commit it to your version control so that subsequent deploys (including from CI) target the correct project.
 

package/.docs/docs/mastra-platform/database.md

@@ -0,0 +1,150 @@
+# Hosted databases
+
+From your [platform](https://mastra.ai/docs/mastra-platform/overview) project settings, provision a fully managed database and attach it to your project. Mastra creates it with your provider, stores credentials securely, and injects connection details as runtime environment variables when the database is ready, so there are no connection strings to copy or configure.
+
+## When to use hosted databases
+
+Use a hosted database when your project needs durable storage that's managed by the platform, including:
+
+- **Agent memory**: Persist conversation history, working memory, and semantic recall across sessions.
+- **Application data**: Store and retrieve relational or structured data your project needs at runtime.
+- **Vector search**: Store embeddings for retrieval-augmented generation and semantic search.
+
+## Providers
+
+Hosted databases are available through three providers. Pick one when you attach a database from project settings. Mastra provisions it with the provider, stores credentials securely, and injects connection details as runtime environment variables when the database is ready. Wire those variables into the matching Mastra storage adapter in your code.
+
+You can attach one database per provider to a project. This keeps environment variable names unambiguous — for example, a project has a single `DATABASE_URL` for Postgres and separate `TURSO_*` variables for Turso. Attach Turso and Postgres to the same project when you need separate stores for different workloads.
+
+For most agent-focused projects, **Turso** is the simplest starting point. It provides a lightweight, SQLite-compatible engine well suited to agent memory, conversation history, and per-tenant isolation. Choose **Postgres** when your workload needs full SQL, relational schemas, or structured application data beyond Mastra runtime state. **MongoDB** (_coming soon_) will add document storage and built-in vector search for workloads that don't map cleanly to SQL.
+
+| Provider       | Engine                     | Best for                                        |
+| -------------- | -------------------------- | ----------------------------------------------- |
+| **Turso**      | LibSQL, SQLite-compatible  | Agent memory, per-tenant isolation              |
+| **PostgreSQL** | Serverless Postgres        | Relational workloads, structured data           |
+| **MongoDB**    | Document and vector search | Document storage, vector search (_coming soon_) |
+
+## Attach a database
+
+1. Open your project in the [platform](https://mastra.ai/docs/mastra-platform/overview) and go to **Project Settings**.
+
+2. Open the **Database** section, then select **Add database**.
+
+3. Select a **provider** (Turso or Postgres). You can switch providers before attaching.
+
+4. Configure the database:
+
+   - **Name**: A label for the database within your project.
+   - **Region**: Where the database is hosted. Select the region closest to your users. Turso defaults to `sjc` (San Jose) and is available in 20+ locations worldwide. Postgres defaults to `aws-us-west-2` and is available across AWS and Azure regions in the US, EU, and APAC.
+
+5. Select **Attach database**. Provisioning runs in the background. The database starts in a `provisioning` state and moves to `ready` once the provider finishes setup. Connection details are injected into your project as server runtime environment variables automatically.
+
+> **Note:** Hosted databases are created from your platform project settings. There is currently no CLI or public API for provisioning them.
+
+## Connect from your code
+
+When a database is `ready`, the provider has finished provisioning and the platform has injected connection details as managed environment variables. Check status in **Project Settings → Database** — each attached database shows `provisioning` while setup runs in the background, then `ready` when you can connect. Open a `ready` database to view its environment variables and a copy-pasteable code snippet. Wire those variables into a Mastra storage adapter, with no manual configuration required.
+
+### Turso (LibSQL)
+
+Turso exposes two environment variables: `TURSO_DATABASE_URL` and `TURSO_AUTH_TOKEN`. The following example connects a [LibSQLStore](https://mastra.ai/reference/storage/libsql) using those variables.
+
+```ts
+import { LibSQLStore } from '@mastra/libsql'
+
+export const storage = new LibSQLStore({
+  url: process.env.TURSO_DATABASE_URL!,
+  authToken: process.env.TURSO_AUTH_TOKEN!,
+})
+```
+
+Install the adapter:
+
+**npm**:
+
+```bash
+npm install @mastra/libsql@latest
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/libsql@latest
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/libsql@latest
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/libsql@latest
+```
+
+### PostgreSQL
+
+PostgreSQL exposes a single `DATABASE_URL` connection string. The following example connects a [PostgresStore](https://mastra.ai/reference/storage/postgresql) using that variable.
+
+```ts
+import { PostgresStore } from '@mastra/pg'
+
+export const storage = new PostgresStore({
+  connectionString: process.env.DATABASE_URL!,
+})
+```
+
+Install the adapter:
+
+**npm**:
+
+```bash
+npm install @mastra/pg@latest
+```
+
+**pnpm**:
+
+```bash
+pnpm add @mastra/pg@latest
+```
+
+**Yarn**:
+
+```bash
+yarn add @mastra/pg@latest
+```
+
+**Bun**:
+
+```bash
+bun add @mastra/pg@latest
+```
+
+Pass the `storage` instance to your `Mastra` configuration so agents, memory, and workflows can use it:
+
+```ts
+import { Mastra } from '@mastra/core'
+import { storage } from './storage'
+
+export const mastra = new Mastra({
+  storage,
+})
+```
+
+## Environment variables
+
+Each provider injects a fixed set of managed environment variables. These are available to your project at runtime when the database is `ready`. You don't define them yourself.
+
+| Provider | Variables                                |
+| -------- | ---------------------------------------- |
+| Turso    | `TURSO_DATABASE_URL`, `TURSO_AUTH_TOKEN` |
+| Postgres | `DATABASE_URL`                           |
+
+> **Warning:** Treat connection credentials as secrets. The auth token (`TURSO_AUTH_TOKEN`) and the Postgres connection string (`DATABASE_URL`) grant full access to your data. The platform masks them by default and only reveals them on request.
+
+## Manage a database
+
+- **View connection details**: Open a `ready` database in your project settings to see its environment variables and a copy-pasteable code snippet.
+- **Detach**: Removing a database from a project deletes it with the provider and clears its injected environment variables. This is irreversible, so ensure you no longer need the data.

package/.docs/docs/mastra-platform/github.md

@@ -0,0 +1,131 @@
+# GitHub integration on Mastra platform
+
+The GitHub integration links a Mastra platform project to a GitHub repository. When you push changes to your repository Studio and Server will automatically be deployed.
+
+> **Note:** The integration only works with repositories hosted on GitHub.com. Self-hosted GitHub Enterprise instances are not currently supported.
+
+After a repository is linked, the platform:
+
+- Builds and deploys Studio and Server on every push to the configured branches.
+- Provisions managed databases and the Mastra gateway API key for projects created from a template.
+- Surfaces commit, branch, and pull request context on each deploy.
+- Reports build status back to GitHub as check runs and to the project dashboard with live status badges and inline logs.
+
+## When to use the GitHub integration
+
+Choose the GitHub integration when you want one of the following:
+
+- Push-to-deploy from `main` or any other branch, including separate branches for Studio and Server.
+- A managed onboarding flow that scaffolds a project from a Mastra template, including a fresh repository, managed database, and gateway API key.
+- Pull-request and commit context inside the platform dashboard for triage.
+
+The CLI flow (`mastra studio deploy` and `mastra server deploy`) is still available for ad-hoc deploys and CI providers other than GitHub. See [Studio](https://mastra.ai/docs/mastra-platform/studio) and [Server](https://mastra.ai/docs/mastra-platform/server) for the CLI-only path.
+
+## Install the Mastra GitHub App
+
+The integration is powered by the Mastra GitHub App. The App reads repository contents, listens for `push` events on the configured branches, and writes deploy status back as check runs.
+
+1. In the [Mastra platform dashboard](https://projects.mastra.ai), open your organization settings. The page includes a **GitHub App** section.
+
+2. Select **Install GitHub App** and choose the GitHub account or organization to install on.
+
+   If you don't own the GitHub organization, GitHub creates a pending **installation request** that an admin must approve. The dashboard tracks pending requests alongside completed installations.
+
+3. Select the repositories the App can access. You can scope to specific repositories or grant access to all repositories on the account.
+
+   You can revoke or change repository access at any time from GitHub's App settings.
+
+> **Note:** If GitHub later updates the App's required permissions, the dashboard surfaces an **outdated permissions** warning with an approval link. Repository operations return a `403` until an admin re-approves.
+
+### Pending installation requests
+
+When a non-admin requests the App on an organization, the request stays pending until an organization admin approves it on GitHub.com. The dashboard:
+
+- Lists pending requests next to active installations.
+- Lets the same user request access to multiple GitHub accounts at once.
+- Reconciles pending state against GitHub when you open the page, removing requests an admin has declined or the requester has withdrawn.
+
+To cancel a pending request, select **Cancel** next to it in the dashboard.
+
+## Create a project from a template
+
+Templates are the fastest way to get started. The platform creates a new repository from a Mastra template, links it to a fresh project, provisions any managed databases the template declares, and runs the first deploy.
+
+1. In the dashboard, select **Create project** and choose **Start from a template**.
+
+2. Pick a template and select the GitHub account that owns the new repository. Name the repository and choose whether it should be private.
+
+3. Configure the template's managed database requirements. Templates can declare required databases (such as Turso or Neon) and you pick the provider and region per requirement.
+
+4. Add any template-specific environment variables (for example, AI provider API keys). The platform seeds `MASTRA_GATEWAY_API_KEY` and `MASTRA_PLATFORM_ACCESS_TOKEN` automatically so that template code that talks to the Mastra gateway works on the first deploy.
+
+5. Select **Create project**. The platform creates the repository, writes a `.mastra-project.json` config file into it, provisions the managed databases, and triggers the initial Studio and Server deploys.
+
+The initial deploy waits for managed databases to finish provisioning before it starts, so the template's first build sees the database connection environment variables.
+
+## Link an existing repository
+
+Use this flow when you already have a Mastra project in a GitHub repository.
+
+1. In the dashboard, select **Create project** and choose **Connect an existing repository**, or open an existing project and select **Link repository** from the project settings.
+
+2. Pick an installation, then choose the repository. Repository search works across every repository the App has access to on that installation.
+
+3. Choose the Studio and Server deploy branches. Both targets default to the repository's default branch, and they can share a branch or use different branches.
+
+   You can disable Studio or Server for the project. The manual **Deploy from GitHub** drawer selects both targets by default when both are configured.
+
+4. Select **Link repository**. The platform validates that the repository doesn't already have a `.mastra-project.json` file pointing at a different project. If it does, the dashboard warns you and offers an **Overwrite** option that replaces the file on link.
+
+After linking, the next push to the configured branch triggers a deploy.
+
+### `.mastra-project.json` conflicts
+
+The platform writes a `.mastra-project.json` file into every linked repository to identify the project. When you link a repository that already has one of these files, the dashboard checks its contents before submitting:
+
+- **Missing**: The platform creates the file on link.
+- **Matching**: The file already points at the project you're linking, so no change is needed.
+- **Conflicting**: The file points at a different project. You can cancel or explicitly overwrite the file.
+
+See [Configuration](https://mastra.ai/docs/mastra-platform/configuration) for the file's schema.
+
+## Push-to-deploy
+
+After a repository is linked, every push to a configured branch triggers a deploy:
+
+- A push to the **Studio branch** triggers a Studio deploy.
+- A push to the **Server branch** triggers a Server deploy.
+- If both targets share a branch, one push triggers both deploys in parallel.
+
+Each deploy carries the commit SHA, branch, and (when available) the pull request number that introduced the commit. Builds run inside the platform and report status back to GitHub as check runs on the commit.
+
+Only one build per deploy target runs at a time. If a new push arrives while a build is in progress, the platform cancels older queued builds for that same target and runs the latest. Studio and Server builds are tracked independently, so they can run in parallel when both targets are configured.
+
+### Manual GitHub deploys
+
+You can also trigger a deploy from the dashboard without pushing. Open the project, select **Deploy from GitHub**, pick the target (Studio, Server, or both) and a branch, and submit. The platform runs the deploy against the head commit of that branch and records the trigger as a **GitHub Workflow** deploy.
+
+## Track deploys
+
+After a project is created from a template or linked to a repository, the **Setup** page shows one row per deploy target. Each row:
+
+- Displays a live status badge that polls the deploy until it finishes.
+- Links to the deploy detail page via the deploy ID.
+- Exposes a **Show logs** toggle that streams build and runtime logs inline. Server logs poll every three seconds while the deploy is active.
+
+## Permissions and revocation
+
+To stop deploys from a repository, do one of the following:
+
+- **Unlink the repository** from the project in **Project settings → Repository**. The project keeps its history and you can re-link a different repository later.
+- **Remove repository access** for the Mastra GitHub App on GitHub.com. Existing deploys keep running, but no new push triggers a deploy.
+- **Uninstall the GitHub App** from the GitHub account. This removes access to every repository on that account.
+
+If GitHub revokes or rotates the App's installation token, repository reads return a `github_app_permissions_outdated` error and the dashboard prompts an admin to re-approve permissions.
+
+## Related
+
+- [Mastra platform overview](https://mastra.ai/docs/mastra-platform/overview)
+- [Studio on Mastra platform](https://mastra.ai/docs/mastra-platform/studio)
+- [Server on Mastra platform](https://mastra.ai/docs/mastra-platform/server)
+- [Configuration](https://mastra.ai/docs/mastra-platform/configuration)

package/.docs/docs/mastra-platform/overview.md

@@ -6,6 +6,10 @@ The [Mastra platform](https://projects.mastra.ai) provides three products for de
 - [**Studio**](https://mastra.ai/docs/mastra-platform/studio): A hosted visual environment for testing agents, running workflows, and inspecting traces. Starting with Studio also gives you Observability.
 - [**Server**](https://mastra.ai/docs/mastra-platform/server): A production deployment target that runs your Mastra application as an API server. Starting with Server also gives you Observability.
 
+You can deploy Studio and Server from the CLI or connect a GitHub repository for push-to-deploy. See the [GitHub integration](https://mastra.ai/docs/mastra-platform/github) for the repository-linked flow.
+
+You can also provision [**Hosted databases**](https://mastra.ai/docs/mastra-platform/database) from your project settings to persist your application data with no manual configuration.
+
 ## Get started
 
 Choose the path that matches what you want to do:

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

@@ -58,10 +58,82 @@ You get a stable API endpoint, environment variable management, custom domain su
 
 A deploy transitions through **queued → uploading → building → deploying → running** (or **failed**, **cancelled**, **crashed**, or **stopped**). Only one build runs per project at a time. If multiple deploys queue up, only the latest proceeds and the rest are cancelled. Builds running longer than 15 minutes are automatically failed. The first deploy provisions Railway infrastructure and seeds environment variables from your local `.env`. Your server URL remains stable across deploys.
 
+## Idle behavior
+
+Server on Mastra platform runs on Railway, which can sleep a service after a period of inactivity to save resources. Railway measures inactivity by outbound network traffic. A service is considered idle only after roughly 10 minutes with no outbound packets. Any recurring outbound traffic resets this timer and keeps the service awake.
+
+A server that never sleeps usually has a background task or a long-lived connection sending traffic on a timer. Check for the following common causes.
+
+### Persistent database connections
+
+A database client that stays open keeps the connection alive even when the server is idle. Many drivers also run a background health check that pings the database on an interval, which counts as outbound traffic. For example, a MongoDB client that's never closed keeps a monitoring socket open and sends a heartbeat about every 10 seconds.
+
+Connection pool settings that drain idle connections aren't enough on their own, because the driver's monitoring connection stays open and keeps pinging. To let the server sleep, close the client after a period of inactivity and reconnect on the next request.
+
+> **Note:** Closing the client adds a short reconnect delay to the first request after the server wakes. If your workload can't tolerate that delay, keep the connection open and don't rely on idle sleep.
+
+### Scheduled tasks and timers
+
+A `setInterval`, cron job, or polling loop that makes network calls keeps the server awake. If you need scheduled work, run it as a separate service or use an external scheduler that wakes the server with a request.
+
+### External pings and keep-alive checks
+
+An uptime monitor, health check, or keep-alive ping that hits the server on an interval resets the idle timer. Remove these checks or increase their interval beyond the idle window if you want the server to sleep.
+
+### Observability exporters
+
+An exporter that streams traces, logs, or metrics to a remote endpoint sends outbound traffic. Confirm the exporter batches and stops sending when the server is idle, rather than flushing on a fixed interval.
+
+### Long-lived streams
+
+An open server-sent events (SSE) stream, WebSocket, or other long-lived connection holds traffic open until it closes. A streaming response that stays subscribed in the background keeps the connection active. Confirm streams close when the client disconnects and that no stream stays open while the server is otherwise idle.
+
+### Chat integrations
+
+Some chat integrations hold a persistent connection and send a regular heartbeat, which keeps the server awake. For example, a Slack app in Socket Mode opens a WebSocket and pings about every 30 seconds, and a Discord bot keeps its gateway WebSocket open with a heartbeat on a timer. Both the open socket and the heartbeat prevent idle.
+
+If you want the server to sleep, receive events over HTTP webhooks instead of a persistent connection where the integration supports it. Slack apps, for example, can use the Events API with a request URL instead of Socket Mode. If your app needs a persistent connection, keep the service running with the **Persistent Server add-on** described below.
+
+### Inspect active connections
+
+To find what keeps the server awake, inspect the process's active handles during idle periods. A handle that remains after all requests finish is the cause to investigate. Open sockets point to a persistent connection that needs to close, and active timers point to a `setInterval` or self-rescheduling `setTimeout`.
+
+Drop the following helper into your app, then watch the log after traffic stops. Anything still listed once the server is idle is keeping it awake:
+
+```typescript
+export function logActiveHandles() {
+  // process._getActiveHandles is undocumented but useful for diagnosis.
+  const handles = (process as any)._getActiveHandles() as Array<any>
+
+  const summary = handles.map(handle => {
+    const type = handle?.constructor?.name ?? typeof handle
+    if (type === 'Socket') {
+      return `Socket -> ${handle.remoteAddress}:${handle.remotePort}`
+    }
+    return type
+  })
+
+  console.log(`[idle] ${handles.length} active handles:`, summary)
+}
+
+// Log every 30 seconds so you can see what persists while the server is idle.
+setInterval(logActiveHandles, 30_000).unref()
+```
+
+Call `unref()` on the diagnostic interval so the helper itself doesn't keep the server awake.
+
+### Keep a service running
+
+Some applications genuinely need the connections or tasks described above, such as a persistent database connection for low first-request latency, a background scheduler, or a long-lived stream. If your app requires any of these, don't force the service to sleep. Use the **Persistent Server add-on** to keep the service running continuously instead.
+
+With the **Persistent Server add-on** enabled, the service stays awake even with no traffic, so persistent connections, scheduled tasks, and open streams keep working without being interrupted by idle sleep.
+
 ## CI/CD
 
 Automate deployments from GitHub Actions, GitLab CI, or any CI provider. After your first interactive deploy, CI/CD needs two things: an API token and the `.mastra-project.json` file committed to your repository.
 
+> **Tip:** If your code lives on GitHub, the [GitHub integration](https://mastra.ai/docs/mastra-platform/github) gives you push-to-deploy without writing a workflow file. Use the CLI-based CI/CD flow below when you need GitLab, another CI provider, or custom build steps before deploy.
+
 ### Create an API token
 
 1. Run the following command locally:

package/.docs/docs/mastra-platform/studio.md

@@ -2,6 +2,8 @@
 
 Studio on Mastra platform is a hosted visual environment for testing agents, running workflows, and inspecting traces. Use it when you want to share Studio with your team without hosting the Studio UI yourself.
 
+You can deploy Studio from the CLI as shown below, or link a GitHub repository for push-to-deploy. See the [GitHub integration](https://mastra.ai/docs/mastra-platform/github) for the repository-linked flow.
+
 ## Quickstart
 
 1. Follow the [get started guide](https://mastra.ai/docs) to create your first Mastra project.

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

@@ -44,12 +44,16 @@ then interact with elements using their refs (e.g., @e5).`,
 
 **screencast** (`ScreencastOptions`): Configuration for streaming browser frames to Studio.
 
+**recording** (`BrowserRecordingOptions`): Alpha option for adding browser recording tools. Provide outputDir to add browser\_record and browser\_record\_caption to the toolset.
+
 **excludeTools** (`BrowserToolName[]`): Tool names to exclude from the browser toolset. Use this to disable specific tools for models that do not support certain capabilities, such as vision.
 
 ## Tools
 
 `AgentBrowser` provides 16 deterministic tools for browser automation. All tools that interact with elements use refs from the accessibility tree snapshot.
 
+When `recording` is configured, `AgentBrowser` also adds the alpha `browser_record` and `browser_record_caption` tools. See [Browser recording (alpha)](https://mastra.ai/docs/browser/recording).
+
 ### Core tools
 
 | Tool                 | Description                                                                           |

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

@@ -61,11 +61,17 @@ Use stagehand_extract to get data from pages.`,
 
 **screencast** (`ScreencastOptions`): Configuration for streaming browser frames to Studio.
 
+**recording** (`BrowserRecordingOptions`): Alpha option for adding browser recording tools. Provide outputDir to add browser\_record and browser\_record\_caption to the toolset.
+
 **excludeTools** (`StagehandToolName[]`): Tool names to exclude from the browser toolset. Use this to disable specific tools for models that do not support certain capabilities, such as vision.
 
 ## Tools
 
-`StagehandBrowser` provides 7 AI-powered tools for browser automation:
+`StagehandBrowser` provides 7 AI-powered tools for browser automation.
+
+When `recording` is configured, `StagehandBrowser` also adds the alpha `browser_record` and `browser_record_caption` tools. See [Browser recording (alpha)](https://mastra.ai/docs/browser/recording).
+
+Core tools:
 
 | Tool                   | Description                                                                           |
 | ---------------------- | ------------------------------------------------------------------------------------- |

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

@@ -522,6 +522,26 @@ response.processDataStream({
 })
 ```
 
+### Shape client tool output for the model
+
+Client tools support `toModelOutput` to control what the model receives, including multimodal content such as images. Because client tools execute locally, the mapping also runs on the client after `execute` completes. The transformed output is sent back to the server alongside the raw result, so the raw result stays available for storage and application logic.
+
+```typescript
+const screenshotTool = createTool({
+  id: 'takeScreenshot',
+  description: 'Takes a screenshot of the current page',
+  inputSchema: z.object({}),
+  execute: async () => {
+    const base64 = await captureScreenshot()
+    return { ok: true, data: base64 }
+  },
+  toModelOutput: output => ({
+    type: 'content',
+    value: [{ type: 'media', data: output.data, mediaType: 'image/jpeg' }],
+  }),
+})
+```
+
 ### Tracing client tools
 
 When `@mastra/observability` is installed and configured on the server, a client-side tool records a `CLIENT_TOOL_CALL` span as a child of the current `AGENT_RUN` span. The server creates that span when the model emits the client tool call, injects a W3C trace carrier into the outgoing tool-call chunk, and ends the span once the tool arguments are available. Without server-side observability configured, client tool tracing is a no-op.

package/.docs/reference/streaming/ChunkType.md

@@ -610,6 +610,36 @@ Contains monitoring and observability data from agent execution. Can include wor
 
 **payload.\[key: string]** (`any`): Additional monitoring and execution data
 
+### goal
+
+Emitted on every evaluation of an agent [goal](https://mastra.ai/docs/agents/goals). Consumers use this to render judge progress and the result mid-run. A goal that has no judge model configured produces no `goal` chunk.
+
+**type** (`"goal"`): Chunk type identifier
+
+**payload** (`GoalEvaluationPayload`): The result of one goal evaluation
+
+**payload.objective** (`string`): The objective being judged
+
+**payload.iteration** (`number`): Goal evaluations consumed so far (runsUsed after this evaluation)
+
+**payload.maxRuns** (`number`): Max evaluations before the goal stops
+
+**payload.passed** (`boolean`): Whether the goal is judged complete
+
+**payload.status** (`"active" | "paused" | "done"`): The objective status after this evaluation
+
+**payload.results** (`ScorerResult[]`): Individual scorer results
+
+**payload.reason** (`string`): Judge feedback or stop reason
+
+**payload.duration** (`number`): Total duration of the goal scoring check
+
+**payload.timedOut** (`boolean`): Whether scoring timed out
+
+**payload.maxRunsReached** (`boolean`): Whether the run budget (maxRuns) was reached
+
+**payload.suppressFeedback** (`boolean`): Whether the goal feedback message is suppressed from memory
+
 ### tripwire
 
 Emitted when the stream is forcibly terminated due to content being blocked by a processor. This acts as a safety mechanism to prevent harmful or inappropriate content from being streamed. The payload includes information about why the content was blocked and whether a retry was requested.

package/.docs/reference/templates/overview.md

@@ -9,6 +9,16 @@ Mastra templates are pre-built project structures that demonstrate specific use
 - **Educational resources**: Learn Mastra patterns through real implementations
 - **Quickstarts**: Bootstrap projects faster than building from scratch
 
+## Available templates
+
+The following templates demonstrate Gateway-first Mastra applications:
+
+- `template-docs-expert`: Answers documentation questions with Mastra Gateway web search, citations, memory, and structured responses.
+- `template-browser-agent`: Uses AgentBrowser to browse, inspect, and interact with web pages.
+- `template-meeting-notes`: Turns Zoom transcripts or uploaded transcripts into structured notes with decisions and action items.
+- `template-company-knowledge`: Indexes Linear and Notion content into pgvector and answers internal knowledge questions.
+- `template-claw-assistant`: Operates a workspace with filesystem, sandbox, browser, and web-search tools.
+
 ## Using templates
 
 ### Installation

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # @mastra/mcp-docs-server
 
+## 1.1.49-alpha.0
+
+### 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 [[`77a2351`](https://github.com/mastra-ai/mastra/commit/77a2351ee79296e360bce822cb3391f7cfd6489d)]:
+  - @mastra/core@1.43.1-alpha.0
+  - @mastra/mcp@1.10.1-alpha.0
+
+## 1.1.47
+
+### Patch Changes
+
+- Updated dependencies [[`de66bb0`](https://github.com/mastra-ai/mastra/commit/de66bb040570444c702ce4d8e1e228a5de2949cb), [`67bf8e2`](https://github.com/mastra-ai/mastra/commit/67bf8e206dfe583954d96015cf0d09f7ac50e45f), [`8216d05`](https://github.com/mastra-ai/mastra/commit/8216d0528d866eb9a07f5d4c87ea3bb1e1139b45), [`d18b23c`](https://github.com/mastra-ai/mastra/commit/d18b23c5e29dfc381e73e3c51fcf6c779afd1823), [`5eb94eb`](https://github.com/mastra-ai/mastra/commit/5eb94ebcf66d4e28c9e26d5821ac93379bab20a0), [`1fa3e12`](https://github.com/mastra-ai/mastra/commit/1fa3e123582b63cfe49de4ee52dc6a065e8d956a), [`f9ee2ac`](https://github.com/mastra-ai/mastra/commit/f9ee2ac661af584e61bc063ac208c9035cd752ef), [`c853d53`](https://github.com/mastra-ai/mastra/commit/c853d535d2df84ab89db1adb4c28900c54c9a2d2), [`d8df1f8`](https://github.com/mastra-ai/mastra/commit/d8df1f8e947e1966c9d4e54713df56d0d0d65226), [`9192ddb`](https://github.com/mastra-ai/mastra/commit/9192ddbced8949113b30de444cbe763f075b59f5), [`ae96523`](https://github.com/mastra-ai/mastra/commit/ae965231f562d9766b0c90c49a69fc68acaa031c), [`17d5a92`](https://github.com/mastra-ai/mastra/commit/17d5a9211aa293b4d4418de3de70dc0394d58101), [`5573693`](https://github.com/mastra-ai/mastra/commit/5573693b589822250e20dfe6cf66e9ff3bc96da8), [`ec4da8a`](https://github.com/mastra-ai/mastra/commit/ec4da8a09e0d2ab452c6ee2c786042ea826b77e5), [`adc44e1`](https://github.com/mastra-ai/mastra/commit/adc44e13c7e570b91e86b20ea7556e61d819db31), [`ed346c0`](https://github.com/mastra-ai/mastra/commit/ed346c0bee2d8496690a4e538bfba1e46894660f), [`c9ce1b2`](https://github.com/mastra-ai/mastra/commit/c9ce1b28d10871110648f9d7b6d76e880b9fa999), [`3ef01fd`](https://github.com/mastra-ai/mastra/commit/3ef01fd130b53d5bd4f828beb174e516a2eb1158), [`245a9a3`](https://github.com/mastra-ai/mastra/commit/245a9a315705fce17ddd980f78a92504b6615c4a), [`dc0b611`](https://github.com/mastra-ai/mastra/commit/dc0b6119b769bd00ee2c5df9259fb376fe63077a), [`38b5de8`](https://github.com/mastra-ai/mastra/commit/38b5de8e5d1d41a69522addf53d96f4b3a1d5bf0), [`dc0b611`](https://github.com/mastra-ai/mastra/commit/dc0b6119b769bd00ee2c5df9259fb376fe63077a), [`dd6a66e`](https://github.com/mastra-ai/mastra/commit/dd6a66ea0b32e0dea8059aec6b35d151e2c87dc4), [`d785c59`](https://github.com/mastra-ai/mastra/commit/d785c593b67fcb4cdc4fab9fdbde5f3b7665efc0), [`1fa3e12`](https://github.com/mastra-ai/mastra/commit/1fa3e123582b63cfe49de4ee52dc6a065e8d956a), [`8b984f4`](https://github.com/mastra-ai/mastra/commit/8b984f4361c202270ceb69257185c4756c9a7c56), [`bf08402`](https://github.com/mastra-ai/mastra/commit/bf084022374fa5d06ca70ed67a86dd64e379071b), [`81fe587`](https://github.com/mastra-ai/mastra/commit/81fe587275035715c1720ddf3fee0505cf053036), [`1fa3e12`](https://github.com/mastra-ai/mastra/commit/1fa3e123582b63cfe49de4ee52dc6a065e8d956a), [`403c438`](https://github.com/mastra-ai/mastra/commit/403c438e417278989ce247233d2c465b8d902cdd), [`f8ba195`](https://github.com/mastra-ai/mastra/commit/f8ba1954e27ee2b20586cc6cd9cf13c002c232f2)]:
+  - @mastra/core@1.43.0
+
 ## 1.1.46
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/mcp-docs-server",
-  "version": "1.1.46",
+  "version": "1.1.49-alpha.0",
   "description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
   "type": "module",
   "main": "dist/index.js",
@@ -28,15 +28,15 @@
     "jsdom": "^26.1.0",
     "local-pkg": "^1.1.2",
     "zod": "^4.4.3",
-    "@mastra/core": "1.42.0",
-    "@mastra/mcp": "^1.10.0"
+    "@mastra/core": "1.43.1-alpha.0",
+    "@mastra/mcp": "^1.10.1-alpha.0"
   },
   "devDependencies": {
     "@hono/node-server": "^1.19.11",
     "@types/jsdom": "^21.1.7",
-    "@types/node": "22.19.15",
-    "@vitest/coverage-v8": "4.1.5",
-    "@vitest/ui": "4.1.5",
+    "@types/node": "22.19.21",
+    "@vitest/coverage-v8": "4.1.8",
+    "@vitest/ui": "4.1.8",
     "@wong2/mcp-cli": "^2.0.0",
     "cross-env": "^10.1.0",
     "eslint": "^10.4.1",
@@ -44,10 +44,10 @@
     "tsup": "^8.5.1",
     "tsx": "^4.22.4",
     "typescript": "^6.0.3",
-    "vitest": "4.1.5",
-    "@internal/types-builder": "0.0.79",
-    "@internal/lint": "0.0.104",
-    "@mastra/core": "1.42.0"
+    "vitest": "4.1.8",
+    "@internal/types-builder": "0.0.80",
+    "@mastra/core": "1.43.1-alpha.0",
+    "@internal/lint": "0.0.105"
   },
   "homepage": "https://mastra.ai",
   "repository": {