@mastra/mcp-docs-server 1.2.11 → 1.2.12-alpha.3

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

@@ -6,7 +6,7 @@
 
 > **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
 
-Signals are a way to interact with an agent through a thread. Instead of starting every interaction with `agent.stream()`, subscribe to a thread and send messages or signals. Mastra either wakes the agent when the thread is idle, drops input into the running agent loop, or queues input for the next turn.
+Signals are a way to interact with an agent through a thread. Instead of starting every interaction with `agent.stream()`, subscribe to a thread and send messages or signals. Mastra either wakes the agent when the thread is idle or drops input into the running agent loop, or alternatively queues input for the next turn.
 
 Use message APIs for user-authored input. Use `sendSignal()` for lower-level system context, such as background task notifications, policy reminders, or processor-generated context.
 
@@ -29,7 +29,7 @@ const agent = new Agent({
   id: 'support-agent',
   name: 'Support Agent',
   instructions: 'Help the user compare options.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
 })
 
 const thread = {
@@ -143,7 +143,7 @@ The model receives the signal as context like this:
 <notification source="github" pr="123">PR #123 has a new review comment from User X about the API surface.</notification>
 ```
 
-Use XML-safe `tagName` and attribute names. They can contain letters, numbers, underscores, periods, and hyphens. They must start with a letter or underscore.
+Use XML-safe `tagName` and attribute names. They can contain letters, numbers, shows, periods, and hyphens. They must start with a letter or underscore.
 
 #### Storage support
 
@@ -320,7 +320,9 @@ Use `createNotificationInboxTool()` to give agents one tool for inbox actions in
 
 Signals coordinate runs through a pub/sub backend. When a signal arrives on a backend that implements `LeaseProvider`, Mastra acquires a lease on the target thread so a single process owns the conversation at a time, then either wakes the agent or routes the input into the running loop. Backends without leasing fall back to a no-op that always grants ownership, which is fine in a single process but not across instances.
 
-The default in-memory pub/sub can't cross instance boundaries. On serverless platforms like Vercel, or any multi-instance deployment, a follow-up signal can land on a different instance than the one running the agent. Without a shared pub/sub, that instance can't reach the active run and starts its own, leaving the original run untouched and the thread processed twice.
+The default in-memory pub/sub can't cross instance boundaries. On serverless platforms like Vercel, or any multi-instance deployment, a follow-up signal can be routed to a different instance than the one running the agent.
+
+Without a shared pub/sub, that instance can't reach the active run and starts its own, leaving the original run untouched and the thread processed twice.
 
 Configure a shared pub/sub backed by Redis Streams on the `Mastra` instance so leases and signals coordinate across instances:
 
@@ -360,7 +362,9 @@ If you call Mastra over HTTP directly, use `POST /api/agents/:agentId/send-messa
 
 ### Use the client SDK
 
-The JavaScript client exposes thread signal APIs. Use `subscribeToThread()` before sending thread input so the client can render the stream that wakes from, or receives, the input.
+The JavaScript client exposes thread signal APIs.
+
+Use `subscribeToThread()` before sending thread input so the client can render the stream that receives the input or wakes in response to it.
 
 ```typescript
 const agent = client.getAgent('supportAgent')

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

@@ -34,7 +34,7 @@ A local env file is optional. [`mastra deploy`](https://mastra.ai/docs/mastra-pl
 
 - **Managed variables**: Injected by platform resources like [hosted databases](https://mastra.ai/docs/mastra-platform/database). The platform defines these, and you can't edit them.
 - **Stored variables**: Saved on the project or environment through the dashboard. Used as-is on every deploy with no local file needed.
-- **Local env files**: An explicit `--env-file`, or ambient `.env` and `.env.local` files, layered on top at deploy time. Variables from `.env.local` override those in `.env`.
+- **Local env files**: Deployments layer an explicit `--env-file` or the ambient `.env` and `.env.local` files on top. Variables from `.env.local` override those in `.env`.
 
 To pin the deploy to a specific env file instead of relying on the default selection, pass `--env-file`:
 
@@ -59,11 +59,11 @@ The following environment variables configure the Observability product on the M
 
 ## Multiple environments
 
-A single project runs the same codebase across multiple [environments](https://mastra.ai/docs/mastra-platform/environments), such as `production` and `staging`. Each environment has its own URL, its own stored variables, and its own deploy history. One `.mastra-project.json` file covers all of them:
+A single project runs the same codebase across multiple [environments](https://mastra.ai/docs/mastra-platform/environments), such as `production` and `staging`. Each environment has its own URL and its own stored variables, plus its own deploy history. One `.mastra-project.json` file covers all of them:
 
 ```bash
 mastra deploy --env production --yes
 mastra deploy --env staging --env-file .env.staging --yes
 ```
 
-> **Note:** Earlier platform versions required one project per environment. Environments replace that pattern, so keep one project and deploy to named environments instead.
+> **Note:** Earlier platform versions required one project per environment. Environments replace that pattern, so keep one project and deploy to environments instead.

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

@@ -2,7 +2,7 @@
 
 # Hosted databases
 
-Provision a fully managed database from the CLI or your [platform](https://mastra.ai/docs/mastra-platform/overview) project settings 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.
+Provision a fully managed database from the CLI or your [platform](https://mastra.ai/docs/mastra-platform/overview) project settings and attach it to your project. Mastra creates it with your provider and stores credentials securely, plus injects connection details as runtime environment variables when the database is ready, so there are no connection strings to copy or configure.
 
 ```bash
 mastra env db create --kind turso
@@ -12,15 +12,15 @@ mastra env db create --kind turso
 
 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.
+- **Agent memory**: Persist conversation history and working memory, plus 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 two providers today — Turso and Postgres — with MongoDB coming soon. Pick one when you attach a database, then wire its injected variables into the matching Mastra storage adapter in your code.
+Hosted databases are available through two providers today, Turso and Postgres, with MongoDB coming soon. Pick one when you attach a database, then wire its injected variables into the matching Mastra storage adapter in your code.
 
-Each provider injects a fixed set of variable names — for example, a single `DATABASE_URL` for Postgres and separate `TURSO_*` variables for Turso. Those names must be unique within each environment, which means an environment can use at most one database per provider. Attach Turso and Postgres to the same project when you need separate stores for different workloads.
+Each provider injects a fixed set of variable names, for example, a single `DATABASE_URL` for Postgres and separate `TURSO_*` variables for Turso. Those names must be unique within each environment, which means an environment can use at most one database per provider. 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.
 
@@ -39,7 +39,7 @@ A database is attached at one of two scopes:
 
 The scope is set when you attach the database and shown in `mastra env db list`.
 
-The two scopes can't overlap for the same provider. Because a project-scoped database already injects its variables into every environment, attaching an environment-scoped database of the same provider is rejected with a variable name conflict. To move from a shared database to per-environment databases, delete the project-scoped database first, then attach one database per environment. Deleting a database destroys it with the provider along with all of its data — export anything you need to keep before switching scopes. Environment-scoped databases on different environments never conflict — each deploy only receives the variables for its own environment.
+The scopes can't overlap for the same provider. Because a project-scoped database already injects its variables into every environment, attaching an environment-scoped database of the same provider is rejected with a variable name conflict. To move from a shared database to per-environment databases, delete the project-scoped database first, then attach one database per environment. Deleting a database destroys it with the provider along with all of its data, export anything you need to keep before switching scopes. Environment-scoped databases on different environments never conflict, each deploy only receives the variables for its own environment.
 
 ## Attach with the CLI
 
@@ -60,7 +60,7 @@ mastra env db create --kind turso --shared
 
 Supported kinds are `turso` and `neon` (Postgres). Useful flags:
 
-- `--shared`: Attach a project-scoped database shared by every environment. Cannot be combined with an environment argument.
+- `--shared`: Attach a project-scoped database shared by every environment. Can't be combined with an environment argument.
 - `--name <name>`: Database name. Defaults to a name derived from the project slug.
 - `--region <region>`: Provider region ID for project-scoped databases (for example `fra`). Environment-scoped databases are placed near the environment's region automatically, and an explicit `--region` is ignored.
 - `--no-wait`: Return immediately instead of polling. Check progress later with `mastra env db show`.
@@ -74,7 +74,7 @@ mastra env db show <database>
 mastra env db delete <database>
 ```
 
-`mastra env db list` shows each database's kind, status, scope, and injected variable names. `mastra env db show` prints connection instructions with secret values masked; pass `--show-secrets` to reveal them. `mastra env db delete` permanently deletes the database and all of its data with the provider. Creating and deleting databases requires the admin role in your organization.
+`mastra env db list` shows each database's kind, status, scope, and injected variable names. `mastra env db show` prints connection instructions with secret values masked. Pass `--show-secrets` to reveal them. `mastra env db delete` permanently deletes the database and all of its data with the provider. Creating and deleting databases requires the admin role in your organization.
 
 ## Attach from project settings
 
@@ -95,7 +95,7 @@ Databases attached from project settings are project-scoped. Use the [CLI](#atta
 
 ## 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.
+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)
 

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

@@ -2,7 +2,9 @@
 
 # Deploy to Mastra platform
 
-[`mastra deploy`](https://mastra.ai/reference/cli/mastra) is the single command for shipping a Mastra application to the [Mastra platform](https://mastra.ai/docs/mastra-platform/overview). One command builds your project, validates it before anything ships, creates the platform project and environment on your first run, deploys, streams build logs, and prints your public URL once the deploy is serving traffic.
+[`mastra deploy`](https://mastra.ai/reference/cli/mastra) is the single command for releasing a Mastra application to the [Mastra platform](https://mastra.ai/docs/mastra-platform/overview).
+
+One command builds your project and validates it before anything includes, plus creates the platform project and environment on your first run, deploys, streams build logs, and prints your public URL once the deploy is serving traffic.
 
 ```bash
 mastra deploy
@@ -73,7 +75,9 @@ The first deploy writes a `.mastra-project.json` file linking your directory to
 mastra deploy --env staging
 ```
 
-Each environment gets its own URL, its own environment variables, and optionally its own [hosted database](https://mastra.ai/docs/mastra-platform/database). See [Environments](https://mastra.ai/docs/mastra-platform/environments) for the full model.
+Each environment gets a separate URL and environment variables. It can also have its own [hosted database](https://mastra.ai/docs/mastra-platform/database).
+
+See [Environments](https://mastra.ai/docs/mastra-platform/environments) for the full model.
 
 ## Choose a region
 
@@ -87,7 +91,7 @@ The region is fixed when the environment is created. Databases attached to an en
 
 ## Preflight checks
 
-Preflight validates the built output before anything ships, and only flags issues in your own code:
+Preflight validates the built output before anything includes, and only flags issues in your own code:
 
 - **Local storage paths**: A hard block. File-backed storage (for example `file:./mastra.db`) is lost on every deploy. Preflight passes when the path is guarded by an environment variable that's set locally, stored on the platform, or provided by a managed database:
 
@@ -120,7 +124,7 @@ Deploys resolve environment variables from three sources:
 
 - **Managed variables**: Injected by platform resources like hosted databases (for example `TURSO_DATABASE_URL`). The platform defines these, and you can't edit them.
 - **Stored variables**: Saved on the project or environment through the dashboard. Used as-is on every deploy with no local file needed.
-- **Local env files**: An explicit `--env-file`, or ambient `.env` and `.env.local` files, layered on top at deploy time.
+- **Local env files**: Deployments layer an explicit `--env-file` or the ambient `.env` and `.env.local` files on top.
 
 ```bash
 mastra deploy --env staging --env-file .env.staging

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

@@ -2,7 +2,11 @@
 
 # Environments
 
-Every platform project contains one or more environments. An environment is an isolated deployment target with its own URL, its own environment variables, its own deploy history, and optionally its own [hosted database](https://mastra.ai/docs/mastra-platform/database). Use environments to run `production`, `staging`, and preview versions of the same codebase inside a single project.
+Every platform project contains one or more environments.
+
+An environment is an isolated deployment target with its own URL, environment variables, and deploy history. It can also have its own [hosted database](https://mastra.ai/docs/mastra-platform/database).
+
+Use environments to run `production`, `staging`, and preview versions of the same codebase inside a single project.
 
 Your first [`mastra deploy`](https://mastra.ai/docs/mastra-platform/deploy) creates the `production` environment. Create more with the CLI or by deploying to a name that doesn't exist yet.
 
@@ -54,13 +58,13 @@ Variables are applied when a deploy starts. To apply changed variables to a runn
 mastra env restart staging
 ```
 
-To see the full set an environment's deploys actually run with — environment-scoped and project-scoped values merged, with managed variables listed by name — pull them into a local env file:
+To see the full set an environment's deploys actually run with, environment-scoped and project-scoped values merged, with managed variables listed by name, pull them into a local env file:
 
 ```bash
 mastra env vars pull staging --output .env.staging
 ```
 
-Managed variable values are injected at deploy time and never written to the file; they appear as name-only comments.
+Managed variable values are injected at deploy time and never written to the file. They appear as name-only comments.
 
 > **Note:** Environment variables don't override managed database variables. To point an environment at a different database, attach an [environment-scoped database](https://mastra.ai/docs/mastra-platform/database) instead.
 
@@ -86,7 +90,7 @@ mastra env db create staging --kind turso --name my-project-staging-db
 
 If you'd rather share one database across every environment, attach it with `--shared` instead: `mastra env db create --kind turso --shared`.
 
-An environment can only use one database per provider. If the project already has a shared (`--shared`) database of the same provider, attaching an environment-scoped one is rejected with a variable name conflict — delete the shared database with `mastra env db delete` first. Deleting a database destroys it with the provider along with all of its data, so export anything you need to keep. See [Hosted databases](https://mastra.ai/docs/mastra-platform/database) for the full scoping model.
+An environment can only use one database per provider. If the project already has a shared (`--shared`) database of the same provider, attaching an environment-scoped one is rejected with a variable name conflict, delete the shared database with `mastra env db delete` first. Deleting a database destroys it with the provider along with all of its data, so export anything you need to keep. See [Hosted databases](https://mastra.ai/docs/mastra-platform/database) for the full scoping model.
 
 ## Delete an environment
 

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

@@ -25,7 +25,9 @@ The CLI flow (`mastra studio deploy` and `mastra server deploy`) is still availa
 
 ## 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.
+The integration is powered by the Mastra GitHub App.
+
+The App reads repository contents and listens for `push` events on the configured branches. It 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.
 

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

@@ -128,7 +128,7 @@ Call `unref()` on the diagnostic interval so the helper itself doesn't keep the
 
 ### 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.
+Some applications actually 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.
 

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

@@ -2,7 +2,7 @@
 
 # Studio on Mastra platform
 
-Studio on Mastra platform is a hosted visual workspace 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.
+Studio on Mastra platform is a hosted visual workspace for testing agents and running workflows, plus 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.
 
@@ -50,7 +50,7 @@ On your first deploy, the CLI prompts you to create a new project or select an e
 
 ## How deploy works
 
-The `mastra studio deploy` command builds your project, compiles `src/mastra/` into `.mastra/output`, packages the output as an artifact ZIP, uploads it, and deploys it to a cloud sandbox.
+The `mastra studio deploy` command builds your project and compiles `src/mastra/` into `.mastra/output`. It packages that output as an artifact ZIP, then uploads and deploys it to a cloud sandbox.
 
 A deploy transitions through **queued → uploading → starting → running** or **failed** if something goes wrong. If a sandbox is already running for your project, the platform updates it in place with no downtime. Otherwise, it creates a fresh sandbox. Your instance URL is assigned per project slug and remains stable across deploys.
 

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

@@ -7,7 +7,7 @@ A workspace gives an environment two things your agents can use at runtime:
 - A **bucket** for filesystem storage, exposed to your code as [`PlatformFilesystem`](https://mastra.ai/reference/workspace/platform-filesystem).
 - A **sandbox** for executing commands, exposed as [`PlatformSandbox`](https://mastra.ai/reference/workspace/platform-sandbox).
 
-Workspaces are provisioned per [environment](https://mastra.ai/docs/mastra-platform/environments), so `production` and `staging` each get their own bucket and sandbox. The platform manages provisioning, credentials, and lifecycle; your deploy code only needs to construct the providers.
+Workspaces are provisioned per [environment](https://mastra.ai/docs/mastra-platform/environments), so `production` and `staging` each get their own bucket and sandbox. The platform manages provisioning, credentials, and lifecycle. Your deploy code only needs to construct the providers.
 
 ## When workspaces are provisioned
 
@@ -15,7 +15,7 @@ New projects have workspaces enabled by default. When you create an environment,
 
 Existing projects that haven't opted in show an **Enable workspaces** action in the Workspaces tab. Enabling provisions a bucket for every environment on the project.
 
-If provisioning fails for an environment — for example while Railway is under load — the Workspaces tab shows the failure and offers a retry. The environment itself is still created; only the workspace is unavailable until you retry.
+If provisioning fails for an environment, for example while Railway is under load, the Workspaces tab shows the failure and offers a retry. The environment itself is still created. Only the workspace is unavailable until you retry.
 
 ## Use the workspace from your code
 
@@ -92,7 +92,7 @@ MASTRA_ENVIRONMENT_ID=your-environment-id
 MASTRA_PLATFORM_BUCKET_NAME=your-bucket-name
 ```
 
-`PlatformFilesystem` and `PlatformSandbox` behave the same locally as on the platform — they connect to the same bucket and sandbox pool for that environment. Use a `staging` or `preview` environment's variables for local runs if you want to keep production data isolated.
+`PlatformFilesystem` and `PlatformSandbox` behave the same locally as on the platform, they connect to the same bucket and sandbox pool for that environment. Use a `staging` or `preview` environment's variables for local runs if you want to keep production data isolated.
 
 For a purely offline loop that never touches the platform, swap the providers for [`LocalFilesystem`](https://mastra.ai/reference/workspace/local-filesystem) and [`LocalSandbox`](https://mastra.ai/reference/workspace/local-sandbox) in a local build.
 
@@ -106,6 +106,6 @@ The Workspaces tab in your platform project shows, per environment:
 
 ## See also
 
-- [`PlatformFilesystem`](https://mastra.ai/reference/workspace/platform-filesystem) — reference for the filesystem provider.
-- [`PlatformSandbox`](https://mastra.ai/reference/workspace/platform-sandbox) — reference for the sandbox provider.
-- [Environments](https://mastra.ai/docs/mastra-platform/environments) — how environments scope workspaces, variables, and databases.
+- [`PlatformFilesystem`](https://mastra.ai/reference/workspace/platform-filesystem): reference for the filesystem provider.
+- [`PlatformSandbox`](https://mastra.ai/reference/workspace/platform-sandbox): reference for the sandbox provider.
+- [Environments](https://mastra.ai/docs/mastra-platform/environments): how environments scope workspaces, variables, and databases.

package/.docs/docs/mcp/mcp-apps.md

@@ -85,7 +85,7 @@ Visit [MCPServer reference](https://mastra.ai/reference/tools/mcp-server) for th
 
 ## Connecting MCP Apps to agents
 
-Agents consume tools — they don't need to know about MCP servers. Pass tools to the agent's `tools` config, and register the MCP server at the Mastra level so Studio can resolve app resources.
+Agents consume tools, they don't need to know about MCP servers. Pass tools to the agent's `tools` config, and register the MCP server at the Mastra level so Studio can resolve app resources.
 
 ```typescript
 import { Agent } from '@mastra/core/agent'

package/.docs/docs/mcp/overview.md

@@ -2,7 +2,7 @@
 
 # MCP overview
 
-Mastra supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction), an open standard for connecting AI agents to external tools and resources. It serves as a universal plugin system, enabling agents to call tools regardless of language or hosting environment.
+Mastra supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction), an open standard for connecting AI agents to external tools and resources. It's a universal plugin system, enabling agents to call tools regardless of language or hosting environment.
 
 Mastra can also be used to author MCP servers, exposing agents, tools, and other structured resources via the MCP interface. These can then be accessed by any system or agent that supports the protocol.
 
@@ -64,7 +64,7 @@ export const testMcpClient = new MCPClient({
 
 Visit [MCPClient](https://mastra.ai/reference/tools/mcp-client) for a full list of configuration options.
 
-> **Authentication:** For connecting to OAuth-protected MCP servers — including completing the browser-based authorization flow with `authenticate()` — see the [OAuth Authentication](https://mastra.ai/reference/tools/mcp-client) section.
+> **Authentication:** For connecting to OAuth-protected MCP servers, including completing the browser-based authorization flow with `authenticate()`, see the [OAuth Authentication](https://mastra.ai/reference/tools/mcp-client) section.
 
 ## Using `MCPClient` with an agent
 
@@ -84,7 +84,7 @@ export const testAgent = new Agent({
       - US National Weather Service
 
       Answer questions using the information you find using the MCP Servers.`,
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: await testMcpClient.listTools(),
 })
 ```
@@ -106,7 +106,7 @@ export const mcp = new MCPClient({
 })
 ```
 
-You can also pass a function to decide dynamically per-call. See the [MCPClient reference](https://mastra.ai/reference/tools/mcp-client) for the full API.
+You can also pass a function to decide per runtime-call. See the [MCPClient reference](https://mastra.ai/reference/tools/mcp-client) for the full API.
 
 ## Configuring `MCPServer`
 
@@ -147,14 +147,14 @@ export const mastra = new Mastra({
 })
 ```
 
-## Static and dynamic tools
+## Static and runtime tools
 
 `MCPClient` offers two approaches to retrieving tools from connected servers, suitable for different application architectures:
 
 | Feature           | Static Configuration (`await mcp.listTools()`) | Dynamic Configuration (`await mcp.listToolsets()`)   |
 | ----------------- | ---------------------------------------------- | ---------------------------------------------------- |
-| **Use Case**      | Single-user, static config (e.g., CLI tool)    | Multi-user, dynamic config (e.g., SaaS app)          |
-| **Configuration** | Fixed at agent initialization                  | Per-request, dynamic                                 |
+| **Use Case**      | Single-user, static config (e.g., CLI tool)    | Multi-user, runtime config (e.g., SaaS app)          |
+| **Configuration** | Fixed at agent initialization                  | Per-request, runtime                                 |
 | **Credentials**   | Shared across all uses                         | Can vary per user/request                            |
 | **Agent Setup**   | Tools added in `Agent` constructor             | Tools passed in `.generate()` or `.stream()` options |
 
@@ -257,7 +257,7 @@ const mcp = new MCPClient({
 })
 ```
 
-> **Important:** Treat the mcp.run SSE URL like a password. Store it securely, for example, in an environment variable.
+> **Requirement:** Treat the mcp.run SSE URL like a password. Store it securely, for example, in an environment variable.
 >
 > ```bash
 > MCP_RUN_SSE_URL=https://www.mcp.run/api/mcp/sse?nonce=...
@@ -410,7 +410,7 @@ As an alternative to MCP, Ampersand's AI SDK also has an adapter for Mastra, so
 
 ## MCP Apps
 
-MCP servers can serve interactive HTML UIs via the MCP Apps extension. Tools with associated `ui://` resources render sandboxed iframes in Studio — both on tool detail pages and inline in agent chat. The app iframe can call server tools and inject messages into the conversation. Visit [MCP Apps](https://mastra.ai/docs/mcp/mcp-apps) for setup instructions and the app bridge API.
+MCP servers can serve interactive HTML UIs via the MCP Apps extension. Tools with associated `ui://` resources render sandboxed iframes in Studio, both on tool detail pages and inline in agent chat. The app iframe can call server tools and inject messages into the conversation. Visit [MCP Apps](https://mastra.ai/docs/mcp/mcp-apps) for setup instructions and the app bridge API.
 
 ## Related
 

package/.docs/docs/memory/memory-processors.md

@@ -2,9 +2,9 @@
 
 # Memory processors
 
-Memory processors transform and filter messages as they pass through an agent with memory enabled. They manage context window limits, remove unnecessary content, and optimize the information sent to the language model.
+Memory processors transform and filter messages as they pass through an agent with memory enabled. They manage context window limits and remove unnecessary content, plus optimize the information sent to the language model.
 
-When memory is enabled on an agent, Mastra adds memory processors to the agent's processor pipeline. These processors retrieve message history, working memory, and semantically relevant messages, then persist new messages after the model responds.
+When memory is enabled on an agent, Mastra adds memory processors to the agent's processor pipeline. These processors retrieve message history and working memory, plus semantically relevant messages, then persist new messages after the model responds.
 
 Memory processors are [processors](https://mastra.ai/docs/agents/processors) that operate specifically on memory-related messages and state.
 
@@ -47,7 +47,7 @@ const agent = new Agent({
   id: 'test-agent',
   name: 'Test Agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({
       id: 'memory-store',
@@ -97,7 +97,7 @@ import { openai } from '@ai-sdk/openai'
 const agent = new Agent({
   name: 'semantic-agent',
   instructions: 'You are a helpful assistant with semantic memory',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({
       id: 'memory-store',
@@ -150,7 +150,7 @@ import { openai } from '@ai-sdk/openai'
 const agent = new Agent({
   name: 'working-memory-agent',
   instructions: 'You are an assistant with working memory',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({
       id: 'memory-store',
@@ -182,7 +182,7 @@ const customMessageHistory = new MessageHistory({
 const agent = new Agent({
   name: 'custom-memory-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({ id: 'memory-store', url: 'file:memory.db' }),
     lastMessages: 10, // This would normally add MessageHistory(10)
@@ -207,7 +207,7 @@ Understanding the execution order is important when combining guardrails with me
 1. **Memory processors run FIRST**: `WorkingMemory`, `MessageHistory`, `SemanticRecall`
 2. **Your input processors run AFTER**: guardrails, filters, validators
 
-This means memory loads message history before your processors can validate or filter the input.
+As a result, memory loads message history before your processors can validate or filter the input.
 
 ### Output Processors
 
@@ -253,7 +253,7 @@ const agent = new Agent({
   id: 'safe-agent',
   name: 'safe-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({ lastMessages: 10 }),
   // Your guardrail runs BEFORE memory saves
   outputProcessors: [contentBlocker],
@@ -293,7 +293,7 @@ const agent = new Agent({
   id: 'validated-agent',
   name: 'validated-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({ lastMessages: 10 }),
   // Your guardrail runs AFTER memory loads history
   inputProcessors: [inputValidator],
@@ -370,7 +370,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'Support agent',
   instructions: 'Answer customer support questions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({ lastMessages: 10 }),
   inputProcessors: [new AttachmentUploader()],
 })

package/.docs/docs/memory/message-history.md

@@ -134,7 +134,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'Support agent',
   instructions: 'Answer customer support questions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     options: {
       generateTitle: true,
@@ -155,7 +155,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'Support agent',
   instructions: 'Answer customer support questions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     options: {
       generateTitle: {
@@ -176,7 +176,7 @@ const agent = mastra.getAgentById('test-agent')
 const memory = await agent.getMemory()
 ```
 
-The `Memory` instance gives you access to functions for listing threads, recalling messages, cloning conversations, and more.
+The `Memory` instance gives you access to functions for listing threads and recalling messages, plus cloning conversations, and more.
 
 ## Querying
 
@@ -279,7 +279,13 @@ const { messages } = await memory.recall({
 })
 ```
 
-Metadata filters match shallow scalar values only: `string`, finite `number`, `boolean`, and `null`. All specified metadata keys must match with AND semantics, and `null` matches an explicit `null` value, not a missing metadata key. Metadata keys must start with a letter or underscore, may contain only alphanumeric characters and underscores, must be 128 characters or fewer, and can't use reserved prototype keys such as `__proto__`, `constructor`, or `prototype`. Performance depends on the storage backend. Some backends can push parts of the filter into the database, while others scan candidate messages after thread, resource, and date constraints are applied but before pagination.
+Metadata filters match shallow scalar values only: `string`, finite `number`, `boolean`, and `null`.
+
+All specified metadata keys use AND semantics. A `null` filter matches only an explicit `null` value. A missing metadata key doesn't match.
+
+Metadata keys must start with a letter or underscore and contain only alphanumeric characters. They must be 128 characters or fewer and can't use reserved prototype keys such as `__proto__`, `constructor`, or `prototype`.
+
+Performance depends on the storage backend. Some backends can push parts of the filter into the database, while others scan candidate messages after thread, resource, and date constraints are applied but before pagination.
 
 Fetch a single message by ID:
 
@@ -324,7 +330,7 @@ Message queries return `MastraDBMessage[]` format. To display messages in a fron
 
 ## Thread cloning
 
-Thread cloning creates a copy of an existing thread with its messages. This is useful for branching conversations, creating checkpoints before a potentially destructive operation, or testing variations of a conversation.
+Thread cloning creates a copy of an existing thread with its messages. This is useful for branching conversations or creating checkpoints before a potentially destructive operation, or alternatively testing variations of a conversation.
 
 ```typescript
 const { thread, clonedMessages } = await memory.cloneThread({

package/.docs/docs/memory/multi-user-threads.md

@@ -14,13 +14,13 @@ Use multi-user threads when several people collaborate on the same subject throu
 
 ## Share one `resourceId` across all participants
 
-A thread belongs to exactly one `resourceId`, so all participants on a shared thread need to pass the same value. Instead of using a user id (the default for single-user apps), key `resourceId` on the conversation itself — for example `doc_${docId}` for a shared document, or `room_${roomId}` for a group chat. With everyone pointing at the same `resourceId`, they read and write the same history.
+A thread belongs to exactly one `resourceId`, so all participants on a shared thread need to pass the same value. Instead of using a user id (the default for single-user apps), key `resourceId` on the conversation itself, for example `doc_${docId}` for a shared document, or `room_${roomId}` for a group chat. With everyone pointing at the same `resourceId`, they read and write the same history.
 
 ## Tag each user message with the speaker's identity
 
 The model needs to know who's talking on every turn. Since the message body is the one place that survives into history and back into context, wrap each user message in a small `<turn>` tag with the speaker's id, name, and role. The tag stays attached to the message, so when prior turns are recalled the model still sees who said what.
 
-Build the tag with a small helper. The example below is one way to do it — copy it into your project and adapt it to your shape of user data:
+Build the tag with a small helper. The example below is one way to do it, copy it into your project and adapt it to your shape of user data:
 
 ```typescript
 export type Speaker = {
@@ -113,11 +113,11 @@ The `<turn>` tag persists in the message body, so when history is recalled on la
 
 The user-tagging pattern composes with every memory layer. Pick the layer based on how long the conversation needs to remember per-user facts:
 
-- **Short conversations** (a single session, or a thread small enough to fit in `lastMessages`), or when you need a verbatim record of who said what: use [message history alone](#message-history-alone). The user tags in history are enough; no extra memory layer needed.
+- **Short conversations** (a single session, or a thread small enough to fit in `lastMessages`), or when you need a verbatim record of who said what: use [message history alone](#message-history-alone). The user tags in history are enough. No extra memory layer needed.
 - **Long-running threads** (conversations that outgrow `lastMessages`, where you need per-user facts to survive history eviction): use [observational memory](#with-observational-memory-recommended).
 - **Need a structured participants list, or your storage adapter doesn't support OM** (OM requires LibSQL, PG, or MongoDB): use [working memory](#with-working-memory).
 
-We recommend using observational memory or working memory, not both — they cover overlapping needs, and running both at once adds latency and token cost without much benefit.
+We recommend using either observational memory or working memory because they cover overlapping needs. Running both adds latency and token cost without much benefit.
 
 ### Message history alone
 
@@ -139,7 +139,7 @@ The model reads identity from the `<turn>` tag on the current message and from p
 
 ### With Observational Memory (recommended)
 
-[Observational Memory](https://mastra.ai/docs/memory/observational-memory) (OM) extracts per-user facts into a background log without burning the agent's tool budget. The default Observer model reads `<turn>` tags natively and produces named attribution like `Alice stated her favorite color is teal.` and `Bob asked for QA sign-off before publish.`
+[Observational Memory](https://mastra.ai/docs/memory/observational-memory) (OM) extracts per-user facts into a background log without burning the agent's tool budget. The default Observer model reads `<turn>` tags natively and produces attribution like `Alice stated her favorite color is teal.` and `Bob asked for QA sign-off before publish.`
 
 Prefer OM over working memory for multi-user threads when your storage supports it. OM extracts facts automatically, scales to any number of participants, and doesn't need template upkeep. Enable it with no overrides:
 
@@ -162,7 +162,7 @@ OM requires a storage adapter that supports it: `@mastra/libsql`, `@mastra/pg`,
 
 ### With working memory
 
-Use working memory when OM isn't an option — for example, when your storage adapter doesn't support OM, or when you need a structured, deterministic participants list the agent can read and write on every turn.
+Use working memory when OM isn't an option, for example, when your storage adapter doesn't support OM, or when you need a structured, deterministic participants list the agent can read and write on every turn.
 
 The default [working memory](https://mastra.ai/docs/memory/working-memory) template assumes one user per thread ("First Name", "Last Name", etc.). For multi-user threads, provide a template with a participants list: