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

package/.docs/docs/deployment/web-framework.md

@@ -1,19 +1,19 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Deploy with a web framework
+# Web framework
 
 When Mastra is integrated with a web framework, it deploys alongside your application using the framework's standard deployment process. Follow the instructions below to ensure your Mastra integration deploys correctly.
 
-> **Warning:** If you're deploying to a cloud provider, remove any usage of [LibSQLStore](https://mastra.ai/reference/storage/libsql) from your Mastra configuration. LibSQLStore requires filesystem access and isn't compatible with serverless platforms.
+> **Warning:** If you're deploying to a cloud provider, remove any usage of [LibSQLStore](https://mastra.ai/integrations/databases/libsql) from your Mastra configuration. LibSQLStore requires filesystem access and isn't compatible with serverless platforms.
 
 Integration guides:
 
-- [With Next.js](https://mastra.ai/guides/getting-started/next-js)
-- [With Astro](https://mastra.ai/guides/getting-started/astro)
+- [With Next.js](https://mastra.ai/integrations/frameworks/next-js)
+- [With Astro](https://mastra.ai/integrations/frameworks/astro)
 
 ## With Next.js on Vercel
 
-If you've integrated Mastra with Next.js [by following our guide](https://mastra.ai/guides/getting-started/next-js) and plan to deploy to Vercel, add `serverExternalPackages: ["@mastra/*"]` to your `next.config.ts`:
+If you've integrated Mastra with Next.js [by following our guide](https://mastra.ai/integrations/frameworks/next-js) and plan to deploy to Vercel, add `serverExternalPackages: ["@mastra/*"]` to your `next.config.ts`:
 
 ```typescript
 import type { NextConfig } from 'next'
@@ -27,7 +27,7 @@ export default nextConfig
 
 ## With Astro on Vercel
 
-If you've integrated Mastra with Astro [by following our guide](https://mastra.ai/guides/getting-started/astro) and plan to deploy to Vercel, add the Vercel adapter and server output to your `astro.config.mjs`:
+If you've integrated Mastra with Astro [by following our guide](https://mastra.ai/integrations/frameworks/astro) and plan to deploy to Vercel, add the Vercel adapter and server output to your `astro.config.mjs`:
 
 ```javascript
 import { defineConfig } from 'astro/config'
@@ -41,7 +41,7 @@ export default defineConfig({
 
 ## With Astro on Netlify
 
-If you've integrated Mastra with Astro [by following our guide](https://mastra.ai/guides/getting-started/astro) and plan to deploy to Netlify, add the Netlify adapter and server output to your `astro.config.mjs`:
+If you've integrated Mastra with Astro [by following our guide](https://mastra.ai/integrations/frameworks/astro) and plan to deploy to Netlify, add the Netlify adapter and server output to your `astro.config.mjs`:
 
 ```javascript
 import { defineConfig } from 'astro/config'

package/.docs/docs/deployment/workers.md

@@ -2,7 +2,7 @@
 
 # Workers
 
-> **Beta:** This feature is in beta. The API is stable enough for production use, but some details may change. See [known limitations](#known-limitations) for current gaps.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable. See [known limitations](#known-limitations) for current gaps.
 
 Workers handle background processing outside the request-response cycle. Workflow step execution, cron-based scheduling, and long-running tool calls all run in workers, keeping the API responsive.
 
@@ -106,7 +106,23 @@ Run the same build artifact in multiple containers, each with a different [`MAST
 
 Split deployments require a distributed PubSub backend ([`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams) or [`GoogleCloudPubSub`](https://mastra.ai/reference/pubsub/google-cloud-pubsub)), a shared [storage backend](https://mastra.ai/reference/workers/overview), and network connectivity between the orchestration worker and the API.
 
-The [worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers) walks through this setup with Docker Compose and Kubernetes examples.
+### Select workers
+
+Set [`MASTRA_WORKERS`](https://mastra.ai/reference/workers/overview) to control which workers run in each process:
+
+| Value                           | Behavior                                                                       |
+| ------------------------------- | ------------------------------------------------------------------------------ |
+| `false`                         | Disable all workers. Use this for the API process in a fully split deployment. |
+| `orchestration`                 | Start the orchestration worker.                                                |
+| `scheduler`                     | Start the scheduler worker.                                                    |
+| `backgroundTasks`               | Start the background task worker.                                              |
+| `orchestration,backgroundTasks` | Start multiple workers from a comma-separated allowlist.                       |
+
+You can also pass a worker name to the CLI. The command sets `MASTRA_WORKERS` in the spawned process:
+
+```bash
+mastra worker start orchestration
+```
 
 ## Network architecture
 
@@ -120,6 +136,237 @@ In a split deployment:
 
 All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. If a worker-related feature needs an HTTP route (for example, token minting for a voice integration), that route runs on the API server, not on the worker process.
 
+## Deploy split workers
+
+Build the API and worker artifacts:
+
+```bash
+mastra build
+mastra worker build --output-dir .mastra/worker
+```
+
+`mastra build` creates the API artifact in `.mastra/output/`. [`mastra worker build`](https://mastra.ai/reference/cli/mastra) creates a worker artifact in `.mastra/worker/`. The following Dockerfile accepts either directory:
+
+```dockerfile
+FROM node:22-alpine
+
+ARG MASTRA_OUTPUT=.mastra/output
+
+WORKDIR /app
+
+COPY ${MASTRA_OUTPUT}/package.json ${MASTRA_OUTPUT}/.npmrc* ./
+RUN npm install --omit=dev
+
+COPY ${MASTRA_OUTPUT}/ .
+
+EXPOSE 4111
+CMD ["node", "index.mjs"]
+```
+
+See [Deploy a Mastra server](https://mastra.ai/docs/deployment/mastra-server) for more information about the build output.
+
+### Docker Compose
+
+The following configuration runs PostgreSQL, Redis, the API, and one process for each worker type. Every process uses shared infrastructure, and the worker processes use the worker artifact.
+
+```yaml
+x-worker: &worker
+  build:
+    context: .
+    args:
+      MASTRA_OUTPUT: .mastra/worker
+
+x-mastra-environment: &shared-environment
+  DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+  REDIS_URL: redis://redis:6379
+
+services:
+  postgres:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: mastra
+      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
+      POSTGRES_DB: mastra
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ['CMD-SHELL', 'pg_isready -U mastra']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    healthcheck:
+      test: ['CMD', 'redis-cli', 'ping']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  api:
+    build:
+      context: .
+      args:
+        MASTRA_OUTPUT: .mastra/output
+    ports:
+      - '4111:4111'
+    environment:
+      <<: *shared-environment
+      WORKER_TOKEN: ${WORKER_TOKEN}
+      MASTRA_WORKERS: 'false'
+    depends_on:
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+    healthcheck:
+      test: ['CMD', 'wget', '-qO-', 'http://localhost:4111/api/agents']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  orchestration-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: orchestration
+      MASTRA_STEP_EXECUTION_URL: http://api:4111/api
+      MASTRA_WORKER_AUTH_TOKEN: ${WORKER_TOKEN}
+    depends_on:
+      api:
+        condition: service_healthy
+
+  scheduler-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: scheduler
+    depends_on:
+      api:
+        condition: service_healthy
+
+  background-task-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: backgroundTasks
+    depends_on:
+      api:
+        condition: service_healthy
+
+volumes:
+  pgdata:
+```
+
+Set the secrets next to `docker-compose.yml`, along with any model provider credentials your application needs:
+
+```bash
+POSTGRES_PASSWORD=your-secure-password
+WORKER_TOKEN=your-shared-secret-token
+```
+
+Configure the API auth provider to accept `WORKER_TOKEN` before exposing the deployment. The orchestration worker sends the same value through `MASTRA_WORKER_AUTH_TOKEN`. The scheduler and background task workers don't call the step execution endpoint in this pull-based topology, so they don't need that variable.
+
+Start the stack and verify that the containers and API are available:
+
+```bash
+docker compose up -d
+docker compose ps
+curl http://localhost:4111/api/agents
+```
+
+### Kubernetes
+
+Create separate Deployments for the API, orchestration worker, scheduler worker, and background task worker. Use the same image and Secret for each Deployment. Set only the role-specific environment variables directly on each container.
+
+The orchestration worker Deployment has the following shape:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: orchestration-worker
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: orchestration-worker
+  template:
+    metadata:
+      labels:
+        app: orchestration-worker
+    spec:
+      containers:
+        - name: worker
+          image: your-registry/mastra-workers:latest
+          env:
+            - name: MASTRA_WORKERS
+              value: orchestration
+            - name: MASTRA_STEP_EXECUTION_URL
+              value: http://api:4111/api
+          envFrom:
+            - secretRef:
+                name: mastra-secrets
+          resources:
+            requests:
+              cpu: 250m
+              memory: 256Mi
+```
+
+Use `MASTRA_WORKERS: scheduler` and `MASTRA_WORKERS: backgroundTasks` for the other worker Deployments. Set `MASTRA_WORKERS: 'false'` on the API Deployment and expose the API with a Service. Give every process access to the same database and PubSub backend. Configure the API auth provider with a worker token, then expose that token to the orchestration worker as `MASTRA_WORKER_AUTH_TOKEN`. See [Deploy Mastra to Kubernetes](https://mastra.ai/integrations/deploy/kubernetes) for the base Kubernetes resources.
+
+Apply the manifests, then verify the pods and API:
+
+```bash
+kubectl apply -f k8s/
+kubectl get pods
+kubectl port-forward svc/api 4111:4111
+```
+
+In a separate terminal, request an API route:
+
+```bash
+curl http://localhost:4111/api/agents
+```
+
+### Step execution URL
+
+In a fully split deployment, the orchestration worker delegates workflow step execution to the API over HTTP. Set `MASTRA_STEP_EXECUTION_URL` to the API's internal URL, including the `/api` prefix:
+
+```bash
+MASTRA_STEP_EXECUTION_URL=http://api:4111/api
+```
+
+Without this variable, the orchestration worker attempts to execute steps in its own process. That process doesn't have access to the full Mastra runtime in a split deployment.
+
+The endpoint uses the server's normal auth pipeline. If the API has an auth provider, set `MASTRA_WORKER_AUTH_TOKEN` to a bearer token that provider accepts. Mastra forwards the value as an `Authorization: Bearer` credential. The configured auth provider validates the token. See [Worker authentication](https://mastra.ai/docs/server/auth/workers) for server configuration and other credential formats.
+
+### Scale workers
+
+The orchestration and background task workers can scale horizontally. PubSub consumer groups distribute events across their instances:
+
+```bash
+docker compose up -d --scale orchestration-worker=3
+docker compose up -d --scale background-task-worker=2
+```
+
+For Kubernetes, change the Deployment replica count manually or use a HorizontalPodAutoscaler:
+
+```bash
+kubectl scale deployment/orchestration-worker --replicas=3
+kubectl scale deployment/background-task-worker --replicas=2
+```
+
+Run exactly one scheduler worker. Multiple schedulers polling the same storage can publish duplicate events for a schedule.
+
+### Crash recovery
+
+A distributed PubSub backend persists unacknowledged events so orchestration and background task workers can resume processing after a restart. If the API is unavailable when the orchestration worker requests step execution, the request fails and the event is delivered again. An event can be processed more than once, so handlers should be idempotent when possible.
+
+The scheduler calculates the next fire time from the current time after it restarts. It doesn't replay schedules that elapsed while it was unavailable.
+
+If the API crashes while a step is executing, that work can be lost and the workflow run can remain in a `running` state. See [known limitations](#known-limitations) and [durable agent crash recovery](https://mastra.ai/docs/long-running-agents/durable-agents).
+
 ## Known limitations
 
 - **No dead-letter queue**: Failed events are nacked and retried, but there's no DLQ for events that fail after all retries.
@@ -129,7 +376,6 @@ All three worker types (orchestration, scheduler, background task) sit behind th
 
 ## Related
 
-- [Worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers): Docker Compose and Kubernetes examples
 - [Worker authentication](https://mastra.ai/docs/server/auth/workers): Secure worker-to-API communication
 - [Workers reference](https://mastra.ai/reference/workers/overview): Details about worker environment variables and types, with a list of supported storage backends
 - [CLI reference](https://mastra.ai/reference/cli/mastra): `mastra worker build` and `mastra worker start`

package/.docs/docs/deployment/workflow-runners.md

@@ -8,10 +8,10 @@ Mastra [workflows](https://mastra.ai/docs/workflows/overview) can be executed us
 
 Inngest is a developer platform for running background workflows without managing infrastructure. Mastra workflows can be deployed to Inngest, which provides step memoization, automatic retries, real-time monitoring, and suspend/resume capabilities.
 
-Visit the [Inngest deployment guide](https://mastra.ai/guides/deployment/inngest) for setup instructions and the [Inngest workflow example](https://github.com/mastra-ai/mastra/tree/main/examples/inngest) for a complete implementation.
+Visit the [Inngest deployment guide](https://mastra.ai/integrations/deploy/inngest) for setup instructions and the [Inngest workflow example](https://github.com/mastra-ai/mastra/tree/main/examples/inngest) for a complete implementation.
 
 ## Temporal
 
 Temporal is a durable execution platform for orchestrating long-running workflows. Mastra workflows can run on Temporal workers, with each `createStep` mapped to a Temporal activity for automatic retries and durable state.
 
-The `@mastra/temporal` package is experimental and not ready for production use. Visit the [Temporal deployment guide](https://mastra.ai/guides/deployment/temporal) for setup instructions.
+The `@mastra/temporal` package is experimental and not ready for production use. Visit the [Temporal deployment guide](https://mastra.ai/integrations/deploy/temporal) for setup instructions.

package/.docs/docs/evals/overview.md

@@ -1,6 +1,6 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Scorers overview
+# Evals
 
 While traditional software tests have clear pass/fail conditions, AI outputs are non-deterministic, they can vary with the same input. **Scorers** help bridge this gap by providing quantifiable metrics for measuring agent quality.
 

package/.docs/docs/evals/quick-checks.md

@@ -1,6 +1,6 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Quick Checks
+# Quick checks
 
 Quick Checks are composable micro-scorers for common assertions like "output contains X" or "agent called tool Y." They require no LLM, run instantly, and plug into the same `scorers: [...]` array as any other scorer.
 

package/.docs/docs/getting-started/develop.md

@@ -138,7 +138,7 @@ See the [project structure reference](https://mastra.ai/reference/project-struct
 
 ## File-based agents
 
-> **Beta:** File-based agents are in beta and may change before they're stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 >
 > File-based discovery only runs through `mastra dev` or `mastra build`. If your app imports `mastra` directly, including through a web framework or server adapter, file-based agents aren't discovered. Register those agents in code or run Mastra as a separate server.
 

package/.docs/{guides/concepts → docs/guides}/multi-agent-systems.md

@@ -46,7 +46,7 @@ Use this pattern when the task is open-ended and the full sequence isn't known i
 
 In Mastra, this pattern maps directly to [supervisor agents](https://mastra.ai/docs/capabilities/subagents). A supervisor agent defines subagents on the `agents` property and uses `stream()` or `generate()` to coordinate them. Mastra also provides delegation hooks, message filtering, and memory isolation to help control this pattern.
 
-> **Tip:** Follow the [supervisor agents tutorial](https://mastra.ai/guides/guide/research-coordinator) for a step-by-step guide.
+> **Tip:** Follow the [supervisor agents tutorial](https://mastra.ai/blog/build-a-research-coordinator-with-supervisor-agents) for a step-by-step guide.
 
 ## Council
 

package/.docs/docs/harness/agent-controller.md

@@ -1,16 +1,16 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# AgentController
+# Agent Controller
 
-> **Beta:** The [`AgentController`](https://mastra.ai/reference/agent-controller/agent-controller-class) feature is in beta stage and subject to breaking changes in minor versions until it graduates from its beta status.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 `AgentController` is a shared runtime host for interactive agent applications. It coordinates modes, models, storage, workspaces, tool approvals, subagents, and channels. Each user or active task works through an isolated [`Session`](https://mastra.ai/reference/agent-controller/session).
 
-[Mastra Code](https://code.mastra.ai) is the flagship AgentController implementation. It's a terminal-based coding agent with multi-model support, persistent conversations, and plan-then-execute workflows. Read [Building a coding agent](https://mastra.ai/guides/guide/coding-agent) for a step-by-step guide.
+[Mastra Code](https://code.mastra.ai) is the flagship AgentController implementation. It's a terminal-based coding agent with multi-model support, persistent conversations, and plan-then-execute workflows. Read [Building a coding agent](https://mastra.ai/blog/building-a-coding-agent) for a step-by-step guide.
 
-## When to use the AgentController
+## When to use the Agent Controller
 
-Use the AgentController when your application needs:
+Use the Agent Controller when your application needs:
 
 - Multiple agent modes that share one conversation thread (e.g., plan → build → review)
 - A control layer between your UI and the agent loop (model switching, state persistence, thread management)
@@ -343,11 +343,52 @@ Point each platform webhook at the controller-specific route:
 
 Each external chat thread maps to one controller Session and Mastra thread. By default, new sessions use a resource ID derived from the adapter's chat-thread ID, prefixed with `channel:`. Use `resolveResourceId` to map direct messages to an existing application user or choose another memory owner. The callback only affects new threads; an existing thread keeps its stored resource ID.
 
-Channel sessions are created by the controller rather than by your code, so `onSessionStart` is where you configure them. It runs once per session, after the session is bound to its mapped thread and before the first message is handled. Use it to apply a model, memory settings, or session state that a channel session would otherwise miss. Later messages in the same thread reuse the session and don't call it again. Errors are logged and swallowed so a session that can't be configured still answers the message.
+Channel sessions are created by the controller rather than by your code, so `onSessionStart` is where you configure them. It runs once per session, after the session is bound to its mapped thread and before the first message is handled. A channel session starts with controller defaults, so this is where you set its model and memory settings. Later messages in the same thread reuse the session and don't call it again. Errors are logged and swallowed so a session that can't be configured still answers the message.
+
+### Authorize and route channel sessions
+
+`onSessionStart` runs after the session exists and swallows errors, so it can't refuse a request. Use `resolveSession` when your host decides whether a session may exist. It replaces the built-in session creation and runs before any session exists. Throwing refuses the request before the controller creates a session or calls the model. Mastra logs the refusal and leaves the chat thread silent, so your authorization message never reaches the channel.
+
+```typescript
+channels: {
+  adapters: { slack: createSlackAdapter() },
+  resolveSession: async ({ controller, thread, requestContext }) => {
+    const install = await installs.authorize(requestContext.get('teamId'))
+
+    return controller.createSession({
+      resourceId: thread.resourceId,
+      scope: install.id,
+      ownerId: controller.id,
+      requestContext,
+    })
+  },
+}
+```
+
+Create the session under `thread.resourceId`. A session can only bind threads it owns, so use `resolveResourceId` if you want a different owner for the mapped thread. Sessions are get-or-create per `resourceId` and `scope`, so pass `scope` when one thread needs separate sessions per install or principal.
+
+Failures that aren't refusals (a storage outage, a bug in your resolver's dependencies) still post an error to the thread, so a broken bot doesn't look like a silent one. If you need to tell them apart in your own code, a refusal is a `ChannelSessionRejectedError` with the original error as its `cause`.
+
+`resolveSession` also runs when a user answers an approval card, with that action's request context, so a shared install revalidates the person approving rather than trusting the person who sent the original message.
+
+### Handle stale approvals
+
+An approval gate lives in memory, so every approval answered after a restart is stale. Mastra never runs the tool for a stale action. Use `onStaleToolApproval` to settle the attempt the user answered, instead of dropping it:
+
+```typescript
+channels: {
+  adapters: { slack: createSlackAdapter() },
+  onStaleToolApproval: async ({ decision, toolCallId, runId, memory }) => {
+    await runs.markInterrupted({ runId, toolCallId, decision, threadId: memory.thread })
+  },
+}
+```
+
+`runId` is the run the approval card was rendered for, which is the attempt the user answered and the one you settle against after a restart. The session's own run is passed separately as `currentRunId`, and is usually `null` or a different run by then.
 
 Controller channel sessions and auto-approval state are held in memory, so use a long-lived server. Pending approvals and live Session state don't survive process restarts. Adapters that can't render approval controls automatically run tools without an approval prompt so the run doesn't remain suspended.
 
-See [Channels](https://mastra.ai/docs/capabilities/channels/overview) for adapter setup and platform-specific webhook configuration.
+See [Channels](https://mastra.ai/docs/capabilities/channels) for adapter setup and platform-specific webhook configuration.
 
 ## Connect a UI
 
@@ -366,11 +407,11 @@ render(session.displayState.get())
 unsubscribe()
 ```
 
-Subscriptions are isolated by Session. Events from another Session on the same controller aren't delivered to this listener. Read the [Building a coding agent](https://mastra.ai/guides/guide/coding-agent) guide for a complete TUI example.
+Subscriptions are isolated by Session. Events from another Session on the same controller aren't delivered to this listener. Read the [Building a coding agent](https://mastra.ai/blog/building-a-coding-agent) guide for a complete TUI example.
 
 ## Related
 
 - [Agents](https://mastra.ai/docs/agents/overview)
 - [Workspace](https://mastra.ai/docs/workspace/overview)
 - [Observational memory](https://mastra.ai/docs/memory/observational-memory)
-- [Channels](https://mastra.ai/docs/capabilities/channels/overview)
+- [Channels](https://mastra.ai/docs/capabilities/channels)

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

@@ -1,15 +1,13 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Harness overview
+# Harness
 
 A harness lets an agent pursue long-running, complex goals while keeping its work durable, visible, and steerable. It preserves progress across retries and interruptions, while giving people and other systems a way to inspect progress, add context, approve actions, redirect the agent, or stop it.
 
-In Mastra, harness refers to a set of capabilities for managing an agent beyond a single uninterrupted run. You can adopt these capabilities individually or combine them as needed.
-
-[`AgentController`](https://mastra.ai/docs/harness/agent-controller) is a harness designed for interactive agent applications. It extends the base [`Agent`](https://mastra.ai/docs/agents/overview) loop with isolated sessions for each user or task, persistent threads and state, switchable modes and models, tool permissions and approvals, subagent orchestration, and streams for events and display state.
-
 Agent harnesses are useful wherever work continues over time. Common examples include coding agents that carry changes through CI and review, software factories that coordinate many tasks in parallel, SRE agents that adapt as incidents evolve, and go-to-market agents that respond as accounts, signals, and conversations change.
 
+In Mastra, harness refers to a set of capabilities for managing an agent beyond a single uninterrupted run. You can adopt these capabilities individually or combine them as needed.
+
 ## When to use a harness
 
 Choose a starting point based on what the agent needs. You may use one capability or several.

package/.docs/docs/index.md

@@ -147,20 +147,20 @@ yarn create mastra
 bunx create-mastra
 ```
 
-You can open [Studio](https://mastra.ai/docs/studio/overview) immediately, which is an interactive UI for your Mastra project. See the [quickstart guide](https://mastra.ai/guides/getting-started/quickstart) for a full walkthrough.
+You can open [Studio](https://mastra.ai/docs/studio/overview) immediately, which is an interactive UI for your Mastra project.
 
 ## Integrate with your framework
 
 Add Mastra to an existing project, or create a new app with your preferred framework:
 
-- [Next.js](https://mastra.ai/guides/getting-started/next-js)
-- [React](https://mastra.ai/guides/getting-started/vite-react)
-- [Astro](https://mastra.ai/guides/getting-started/astro)
-- [Express](https://mastra.ai/guides/getting-started/express)
-- [SvelteKit](https://mastra.ai/guides/getting-started/sveltekit)
-- [Hono](https://mastra.ai/guides/getting-started/hono)
+- [Next.js](https://mastra.ai/integrations/frameworks/next-js)
+- [React + Vite](https://mastra.ai/integrations/frameworks/vite-react)
+- [Astro](https://mastra.ai/integrations/frameworks/astro)
+- [Express](https://mastra.ai/integrations/frameworks/express)
+- [SvelteKit](https://mastra.ai/integrations/frameworks/sveltekit)
+- [Hono](https://mastra.ai/integrations/frameworks/hono)
 
-For other frameworks, see the [framework integration guides](https://mastra.ai/guides/getting-started/next-js).
+For other frameworks, see the [integration guides](https://mastra.ai/integrations).
 
 ## Templates
 

package/.docs/docs/long-running-agents/durable-agents.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/core@1.45.0`
 
-> **Warning:** Durable agents are currently in **beta**. APIs may change in future releases.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 A durable agent wraps a regular [`Agent`](https://mastra.ai/docs/agents/overview) so the agentic loop runs inside a workflow. Events flow through [PubSub](https://mastra.ai/docs/server/pubsub), which means a client can disconnect and reconnect without missing chunks. The run state is persisted, so it survives process restarts.
 
@@ -15,7 +15,7 @@ Use a durable agent when any of the following apply:
 - The client may drop and reconnect mid-stream (mobile, spotty networks, long-running calls).
 - The agentic loop may outlive a single HTTP request (background research, multi-step tool use).
 - You need an observe/reconnect API where a second client picks up a stream that a first client started.
-- You want [Inngest-powered execution](https://mastra.ai/guides/deployment/inngest) with step memoization, retries, and monitoring.
+- You want [Inngest-powered execution](https://mastra.ai/integrations/deploy/inngest) with step memoization, retries, and monitoring.
 
 For short-lived, request-scoped calls where the client stays connected, a regular `Agent` with `stream()` or `generate()` is simpler.
 
@@ -268,6 +268,6 @@ Mastra doesn't provide a distributed lease or lock yet. In multi-replica deploym
 - [DurableAgent reference](https://mastra.ai/reference/agents/durable-agent)
 - [`createInngestAgent()` reference](https://mastra.ai/reference/agents/inngest-agent)
 - [Background tasks](https://mastra.ai/docs/long-running-agents/background-tasks)
-- [Inngest deployment guide](https://mastra.ai/guides/deployment/inngest)
+- [Inngest deployment guide](https://mastra.ai/integrations/deploy/inngest)
 - [Agent overview](https://mastra.ai/docs/agents/overview)
 - [Worker overview](https://mastra.ai/docs/deployment/workers)

package/.docs/docs/long-running-agents/goals.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/core@1.42.0`
 
-> **Beta:** The Goals feature is in beta stage and subject to breaking changes in minor versions until it graduates from its beta status.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 A goal is a durable, thread-scoped objective: a standing instruction the agent keeps working toward across loop iterations until a judge model decides it's satisfied or a run budget is exhausted.
 

package/.docs/docs/long-running-agents/schedules.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/core@1.50.0`
 
-> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 A schedule runs an agent on a cron cadence. On each fire, Mastra sends a prompt to the agent, either as a [signal](https://mastra.ai/docs/long-running-agents/signals) into a thread or as a threadless [`agent.generate()`](https://mastra.ai/reference/agents/generate) run. Use schedules for recurring agent work such as daily summaries, periodic checks, or scheduled nudges into a conversation.
 

package/.docs/docs/long-running-agents/signal-providers.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/core@1.39.0`
 
-> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Breaking changes may occur without a major version bump until the API is stable.
 
 A signal provider monitors an external source, such as GitHub, Slack, continuous integration (CI), or your own API, and pushes [notification signals](https://mastra.ai/docs/long-running-agents/signals) into subscribed agent threads.
 
@@ -45,7 +45,7 @@ export const supportAgent = new Agent({
 })
 ```
 
-> **Note:** Notification delivery requires a storage adapter with notification support, such as [libSQL](https://mastra.ai/reference/storage/libsql), [PostgreSQL](https://mastra.ai/reference/storage/postgresql), or [MongoDB](https://mastra.ai/reference/storage/mongodb). Configure storage on the Mastra instance so `notify()` can store notification records.
+> **Note:** Notification delivery requires a storage adapter with notification support, such as [libSQL](https://mastra.ai/integrations/databases/libsql), [PostgreSQL](https://mastra.ai/integrations/databases/postgresql), or [MongoDB](https://mastra.ai/integrations/databases/mongodb). Configure storage on the Mastra instance so `notify()` can store notification records.
 
 ## Quickstart
 
@@ -122,7 +122,7 @@ ciSignals.watch({ resourceId: 'user_123', threadId: 'thread_456' }, 'acme-app-ma
 
 Mastra calls `poll()` on the `pollInterval` with all active subscriptions. It skips a cycle when there are no subscriptions and doesn't overlap cycles, so a slow `poll()` doesn't run concurrently with itself.
 
-> **Note:** For a complete polling-provider build with notification storage, agent registration, thread subscription, and testing, follow [Building a signal provider](https://mastra.ai/guides/guide/signal-provider).
+> **Note:** For a complete polling-provider build with notification storage, agent registration, thread subscription, and testing, follow [Building a signal provider](https://mastra.ai/blog/building-a-signal-provider).
 
 ## Polling and webhook providers
 
@@ -200,24 +200,11 @@ A provider can support more than event ingestion. Add only the capabilities your
 - **Lifecycle hooks:** Override [`start()`](https://mastra.ai/reference/signals/signal-provider) for async setup and [`stop()`](https://mastra.ai/reference/signals/signal-provider) for cleanup. Call `super.stop()` when overriding `stop()` so the base provider can stop polling and clear its registry.
 - **Processors and tools:** Return processors from [`getInputProcessors()`](https://mastra.ai/reference/signals/signal-provider) or [`getOutputProcessors()`](https://mastra.ai/reference/signals/signal-provider), and return agent-callable tools from [`getTools()`](https://mastra.ai/reference/signals/signal-provider).
 
-The `@mastra/github-signals` package is a production signal provider that watches GitHub pull requests and notifies threads about comments, review state, continuous integration status, and merges. Use it as a reference for polling, durable subscriptions, tools, processors, and lifecycle hooks.
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { GithubSignals } from '@mastra/github-signals'
-
-export const devAgent = new Agent({
-  id: 'dev-agent',
-  name: 'Dev Agent',
-  instructions: 'Help triage pull request activity.',
-  model: 'openai/gpt-5.6-sol',
-  signals: [new GithubSignals()],
-})
-```
+For a production provider that watches GitHub pull requests, see the [GitHub Channels integration](https://mastra.ai/integrations/channels/github).
 
 ## Related
 
-- [Guide: Building a signal provider](https://mastra.ai/guides/guide/signal-provider)
+- [Guide: Building a signal provider](https://mastra.ai/blog/building-a-signal-provider)
 - [Signals](https://mastra.ai/docs/long-running-agents/signals)
 - [Notification signals](https://mastra.ai/docs/long-running-agents/signals)
 - [`SignalProvider` reference](https://mastra.ai/reference/signals/signal-provider)