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

package/.docs/reference/processors/tool-call-filter.md

@@ -93,7 +93,7 @@ export const agent = new Agent({
   id: 'filtered-agent',
   name: 'filtered-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: {
     searchDatabase,
     sendEmail,
@@ -119,7 +119,7 @@ export const agent = new Agent({
   id: 'no-tools-context-agent',
   name: 'no-tools-context-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: {
     searchDatabase,
     sendEmail,

package/.docs/reference/processors/tool-search-processor.md

@@ -2,7 +2,7 @@
 
 # ToolSearchProcessor
 
-The `ToolSearchProcessor` is an **input processor** that enables dynamic tool discovery and loading. Instead of providing all tools to the agent upfront, it gives the agent two meta-tools (`search_tools` and `load_tool`) that let it find and load tools on demand. This reduces context token usage when working with large tool libraries.
+The `ToolSearchProcessor` is an **input processor** that enables runtime-defined tool discovery and loading. Instead of providing all tools to the agent upfront, it gives the agent two meta-tools (`search_tools` and `load_tool`) that let it find and load tools on demand. This reduces context token usage when working with large tool libraries.
 
 ## Usage example
 
@@ -91,11 +91,11 @@ Immediately runs TTL cleanup instead of waiting for the scheduled sweep.
 const cleaned = processor.cleanupNow()
 ```
 
-Returns: `number` — the count of threads cleaned up.
+Returns: `number`: the count of threads cleaned up.
 
 ## Request-aware filtering
 
-Use `filter` to apply request-specific policy to dynamic tools. The hook receives the resolved tool ID as `toolName`, the tool, request context, and phase. `toolName` is the ID returned by `search_tools`, which may differ from the key used in the `tools` object.
+Use `filter` to apply request-specific policy to runtime-defined tools. The hook receives the resolved tool ID as `toolName`, the tool, request context, and phase. `toolName` is the ID returned by `search_tools`, which may differ from the key used in the `tools` object.
 
 ```typescript
 import { ToolSearchProcessor } from '@mastra/core/processors'
@@ -120,7 +120,7 @@ The `phase` value describes where the filter is being applied:
 - `load`: Blocks `load_tool` from loading disallowed tools.
 - `active`: Hides already-loaded tools from the current request if they're no longer allowed.
 
-If the hook throws or rejects, `ToolSearchProcessor` treats the tool as disallowed for that request. The hook may run for every matching search candidate, so keep async policy checks cheap or cached. The `search_tools` meta-tool is always available; `load_tool` is available unless `search.autoLoad` is enabled. Tools passed directly through the agent or `processInputStep` remain available unless you filter them outside `ToolSearchProcessor`.
+If the hook throws or rejects, `ToolSearchProcessor` treats the tool as disallowed for that request. The hook may run for every matching search candidate, so keep async policy checks cheap or cached. The `search_tools` meta-tool is always available. `load_tool` is available unless `search.autoLoad` is enabled. Tools passed directly through the agent or `processInputStep` remain available unless you filter them outside `ToolSearchProcessor`.
 
 ## Extended usage example
 
@@ -150,7 +150,7 @@ const agent = new Agent({
   name: 'dynamic-tools-agent',
   instructions:
     'You are a helpful assistant with access to many tools. Use search_tools to find relevant tools, then load_tool to make them available.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [toolSearch],
 })
 ```
@@ -188,7 +188,7 @@ Every match is activated, so keep `topK` small (for example, `3`) to avoid addin
 
 ## Loaded-tool storage
 
-The `storage` option controls where the set of loaded tools is tracked. The default is `'in-memory'`; the `'context'` store is opt-in.
+The `storage` option controls where the set of loaded tools is tracked. The default is `'in-memory'`. The `'context'` store is opt-in.
 
 ### `'in-memory'` (default)
 
@@ -205,7 +205,7 @@ Use `clearState`, `clearAllState`, `getStateStats`, and `cleanupNow` to inspect
 Loaded state is derived from the conversation messages: a tool is loaded while a `search_tools` or `load_tool` result naming it remains in the messages. This mode:
 
 - Requires no memory configuration.
-- Is restart-safe — the durable record is the persisted message history.
+- Is restart-safe: the durable record is the persisted message history.
 - De-loads a tool automatically once that result is no longer present in the messages.
 
 ```typescript
@@ -219,7 +219,7 @@ const toolSearch = new ToolSearchProcessor({
 
 Loading tools is cache-friendly in both modes: loads are append-only, so the cached prompt prefix stays stable for providers that support prompt caching.
 
-Unloading a tool changes the tool definitions sent to the model, which shifts the cached prefix and causes the next turn to pay a cache write instead of a cache hit. In `'in-memory'` mode this happens when a thread's state is evicted by `ttl`. In `'context'` mode it happens when a tool's discovery result is no longer present in the messages (for example, when older messages are trimmed) — the tool de-loads and the model must search for it again before reuse. This is expected: removing an unused tool trades one cache write for a smaller prefix on later turns.
+Unloading a tool changes the tool definitions sent to the model, which shifts the cached prefix and causes the next turn to pay a cache write instead of a cache hit. In `'in-memory'` mode this happens when a thread's state is evicted by `ttl`. In `'context'` mode it happens when a tool's discovery result is no longer present in the messages (for example, when older messages are trimmed). The tool de-loads, and the model must search for it again before reuse. This is expected: removing an unused tool trades one cache write for a smaller prefix on later turns.
 
 ## Combining with other processors
 
@@ -230,7 +230,7 @@ import { ToolSearchProcessor, TokenLimiter } from '@mastra/core/processors'
 const agent = new Agent({
   id: 'my-agent',
   name: 'my-agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new ToolSearchProcessor({
       tools: allTools,

package/.docs/reference/processors/unicode-normalizer.md

@@ -2,7 +2,7 @@
 
 # UnicodeNormalizer
 
-The `UnicodeNormalizer` is an **input processor** that normalizes Unicode text to ensure consistent formatting and remove potentially problematic characters before messages are sent to the language model. This processor helps maintain text quality by handling various Unicode representations, removing control characters, and standardizing whitespace formatting.
+The `UnicodeNormalizer` is an **input processor** that normalizes Unicode text to ensure consistent formatting and remove potentially problematic characters before messages are sent to the language model. This processor handles Unicode representations and removes control characters. It also standardizes whitespace formatting.
 
 ## Usage example
 
@@ -45,7 +45,7 @@ export const agent = new Agent({
   id: 'normalized-agent',
   name: 'normalized-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new UnicodeNormalizer({
       stripControlChars: true,

package/.docs/reference/processors/working-memory-processor.md

@@ -70,7 +70,7 @@ export const agent = new Agent({
   id: 'personalized-agent',
   name: 'personalized-agent',
   instructions: 'You are a helpful assistant that remembers user preferences',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new WorkingMemory({
       storage,

package/.docs/reference/project-structure.md

@@ -4,7 +4,7 @@
 
 Your new Mastra project, created with the `create mastra` command, comes with a predefined set of files and folders to help you get started.
 
-Mastra is a framework, but it's mostly **unopinionated** about how you organize or colocate your files. The CLI provides a sensible default structure that works well for most projects, but you're free to adapt it to your workflow or team conventions. You could even build your entire project in a single file if you wanted! Whatever structure you choose, keep it consistent to ensure your code stays maintainable and straightforward to navigate.
+Mastra is a framework, but it's mostly **unopinionated** about how you organize or colocate your files. The CLI provides a sensible default structure that works well for most projects, but you're free to adapt it to your workflow or team conventions. You could even build your entire project in a single file if you wanted! Whatever structure you choose, keep it consistent to ensure your code stays maintainable and straightforward to browse.
 
 ## Default project structure
 

package/.docs/reference/pubsub/base.md

@@ -77,7 +77,7 @@ await pubsub.publish('my-topic', {
 
 Registers a callback to receive events published to a topic. When `options.group` is set, subscribers in the same group compete for messages and each event is delivered to one member. Without a group, every subscriber receives every event.
 
-Pass `options.batch` to opt in to batched delivery. The callback signature is unchanged: a batch of N events is delivered as N consecutive `cb(event, ack, nack)` calls in publish order. Batching is honored only when the backend's [`supportsNativeBatching`](#properties) is `true`; other backends ignore the option and deliver events one at a time.
+Pass `options.batch` to opt in to batched delivery. The callback signature is unchanged: a batch of N events is delivered as N consecutive `cb(event, ack, nack)` calls in publish order. Batching is honored only when the backend's [`supportsNativeBatching`](#properties) is `true`. Other backends ignore the option and deliver events one at a time.
 
 ```typescript
 await pubsub.subscribe('my-topic', (event, ack, nack) => {
@@ -103,9 +103,9 @@ await pubsub.flush()
 
 #### `clearTopic(topic)`
 
-Deletes all retained state for a topic — cached history, persistent stream entries, and consumer groups — once no more events will be published to it. Mastra's run lifecycles (durable agents and the evented workflow engine) call this automatically when a run reaches a terminal state, so per-run topics don't accumulate on transports that retain messages.
+Deletes all retained state for a topic (cached history, persistent stream entries, and consumer groups) once no more events will be published to it. Mastra's run lifecycles (durable agents and the evented workflow engine) call this automatically when a run reaches a terminal state, so per-run topics don't accumulate on transports that retain messages.
 
-The default implementation is a no-op: transports that retain nothing per topic (such as `EventEmitterPubSub`) have nothing to clear. Backends that persist messages, like [`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams), override it. The contract is best-effort — implementations log failures rather than throwing, because callers invoke it fire-and-forget at cleanup boundaries.
+The default implementation is a no-op: transports that retain nothing per topic (such as `EventEmitterPubSub`) have nothing to clear. Backends that persist messages, like [`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams), override it. The contract is best-effort: implementations log failures rather than throwing, because callers invoke it fire-and-forget at cleanup boundaries.
 
 ```typescript
 await pubsub.clearTopic('workflow.events.v2.run-123')
@@ -177,7 +177,7 @@ await pubsub.subscribeFromOffset('my-topic', 42, event => {
 
 ### `SubscribeBatchOptions`
 
-Per-subscription batching policy. The callback signature doesn't change; a batch of N events becomes N consecutive callback invocations in publish order.
+Per-subscription batching policy. The callback signature doesn't change. A batch of N events becomes N consecutive callback invocations in publish order.
 
 **maxSize** (`number`): Maximum events held before forcing a flush.
 

package/.docs/reference/pubsub/google-cloud-pubsub.md

@@ -6,7 +6,7 @@
 
 Use it for distributed deployments on Google Cloud. For single-process delivery, use [`EventEmitterPubSub`](https://mastra.ai/reference/pubsub/event-emitter). For Redis, use [`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams).
 
-Each topic maps to a Google Cloud topic. Subscriptions with a group share a named subscription, so members compete for events. Subscriptions without a group create a per-instance subscription, so every instance receives every event.
+Each topic maps to a Google Cloud topic. Subscriptions with a group share a subscription, so members compete for events. Subscriptions without a group create a per-instance subscription, so every instance receives every event.
 
 ## Installation
 
@@ -85,7 +85,7 @@ await pubsub.flush()
 
 ### `destroy(topicName)`
 
-Removes the subscription and topic for a given topic name. Use this to clean up Google Cloud resources.
+Removes the subscription and topic for a topic name. Use this to clean up Google Cloud resources.
 
 ```typescript
 await pubsub.destroy('workflow.events')

package/.docs/reference/pubsub/lease-provider.md

@@ -2,9 +2,9 @@
 
 # LeaseProvider
 
-`LeaseProvider` is the distributed leasing contract, separate from event delivery ([`PubSub`](https://mastra.ai/reference/pubsub/base)). Mastra's [signals layer](https://mastra.ai/docs/long-running-agents/signals) uses it to elect a single owner across multiple processes (for example, serverless invocations) for a given resource, most commonly a thread key. The owner is the process that wakes and runs the agent stream, so other processes route follow-up work to it instead of starting a competing run.
+`LeaseProvider` is the distributed leasing contract, separate from event delivery ([`PubSub`](https://mastra.ai/reference/pubsub/base)). Mastra's [signals layer](https://mastra.ai/docs/long-running-agents/signals) uses it to elect a single owner across multiple processes (for example, serverless invocations) for a resource, most commonly a thread key. The owner is the process that wakes and runs the agent stream, so other processes route follow-up work to it instead of starting a competing run.
 
-Leasing is a distinct concern from pub/sub. A backend implements `LeaseProvider` only when it can genuinely coordinate a lock, such as Redis via atomic `SET`/Lua, or an in-memory map for single-process. Backends that can't lease omit it; the signals runtime feature-detects the capability and falls back to a no-op provider, preserving single-process behavior.
+Leasing is a distinct concern from pub/sub. A backend implements `LeaseProvider` only when it can actually coordinate a lock, such as Redis via atomic `SET`/Lua, or an in-memory map for single-process. Backends that can't lease omit it; the signals runtime feature-detects the capability and falls back to a no-op provider, preserving single-process behavior.
 
 The built-in [`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams) implements `LeaseProvider`, which is what enables signals to coordinate across instances in distributed and serverless deployments.
 
@@ -102,7 +102,7 @@ Returns: `Promise<boolean>`
 
 #### `transferLease(key, fromOwner, toOwner, ttlMs)`
 
-Atomically hands a held lease from `fromOwner` to `toOwner`, refreshing its TTL, without releasing the key in between. This is the gap-free primitive used when one owner finishes but a follow-up owner must take over the same key immediately, for example when a thread run completes and a queued follow-up run drains on the same thread. A naive release-then-acquire would briefly leave the key empty, letting a racing process win the freed lease and start a competing run.
+Atomically transfers a held lease from `fromOwner` to `toOwner` and refreshes its TTL without releasing the key in between. This gap-free primitive lets a follow-up owner take over the same key immediately after the current owner finishes. For example, a queued follow-up run can take over when a thread run completes. A naive release-then-acquire briefly leaves the key empty. A racing process could then win the freed lease and start a competing run.
 
 Returns `true` if `fromOwner` still held the lease and ownership moved to `toOwner`, or `false` if the lease was already lost, in which case the caller should fall back to a fresh `acquireLease`.
 
@@ -129,5 +129,5 @@ When the configured pub/sub backend doesn't implement `LeaseProvider`, the runti
 
 - [PubSub](https://mastra.ai/reference/pubsub/base): The event delivery contract, separate from leasing
 - [RedisStreamsPubSub](https://mastra.ai/reference/pubsub/redis-streams): The built-in backend that implements `LeaseProvider`
-- [Signals](https://mastra.ai/docs/long-running-agents/signals): The runtime that uses leasing to coordinate thread runs across processes
+- [Signals](https://mastra.ai/docs/long-running-agents/signals): The runtime that uses leasing to coordinate thread execution across processes
 - [Channels](https://mastra.ai/docs/capabilities/channels/overview): Uses leasing to coordinate agent runs in serverless and multi-instance deployments

package/.docs/reference/pubsub/redis-streams.md

@@ -101,7 +101,7 @@ await pubsub.flush()
 
 ### `clearTopic(topic)`
 
-Deletes a topic's stream and every consumer group on it, freeing the memory a finished topic would otherwise hold. Mastra's run lifecycles — durable agents and the evented workflow engine — call this automatically when a run reaches a terminal state; call it yourself only once nothing will read the topic again. It's best-effort and never throws — failures are logged at warn level. A subscriber still attached when the stream is deleted recovers on its own but misses the deleted entries.
+Deletes a topic's stream and every consumer group on it, freeing the memory a finished topic would otherwise hold. Mastra's run lifecycles (durable agents and the evented workflow engine) call this automatically when a run reaches a terminal state. Call it yourself only once nothing will read the topic again. It's best-effort and never throws. Failures are logged at warn level. A subscriber still attached when the stream is deleted recovers on its own but misses the deleted entries.
 
 Automatic cleanup requires `@mastra/core` and `@mastra/redis-streams` versions that both support `clearTopic`: the runtime routes the call through its caching layer, so upgrade the two packages together to get end-of-run stream deletion.
 

package/.docs/reference/pubsub/unix-socket-pubsub.md

@@ -51,4 +51,4 @@ await pubsub.close()
 
 ## Broker election
 
-The first process to bind the socket becomes the broker and routes events between all connected clients. Other processes connect as clients. When the broker exits, an exclusive lock file serializes the next election so exactly one client becomes the new broker, and the remaining clients resubscribe to it. This avoids a split-brain state where two processes both act as broker.
+The first process to bind the socket becomes the broker and routes events between all connected clients. Other processes connect as clients. When the broker exits, an exclusive lock file serializes the next election. Exactly one client becomes the new broker. The remaining clients resubscribe to it. This avoids a split-brain state where two processes both act as broker.

package/.docs/reference/rag/chunk.md

@@ -2,7 +2,7 @@
 
 # .chunk()
 
-The `.chunk()` function splits documents into smaller segments using various strategies and options.
+The `.chunk()` function splits documents into smaller segments using strategies and options.
 
 ## Example
 
@@ -39,11 +39,11 @@ const chunksWithMetadata = await doc.chunk({
 
 ## Parameters
 
-The following parameters are available for all chunking strategies. **Important:** Each strategy will only utilize a subset of these parameters relevant to its specific use case.
+The following parameters are available for all chunking strategies. Each strategy will only utilize a subset of these parameters relevant to its specific use case.
 
 **strategy** (`'recursive' | 'character' | 'token' | 'markdown' | 'semantic-markdown' | 'html' | 'json' | 'latex' | 'sentence'`): The chunking strategy to use. If not specified, defaults based on document type. Depending on the chunking strategy, there are additional optionals. Defaults: .md files → 'markdown', .html/.htm → 'html', .json → 'json', .tex → 'latex', others → 'recursive'
 
-**maxSize** (`number`): Maximum size of each chunk. \*\*Note:\*\* Some strategy configurations (markdown with headers, HTML with headers) ignore this parameter. (Default: `4000`)
+**maxSize** (`number`): Maximum size of each chunk. Some strategy configurations (markdown with headers, HTML with headers) ignore this parameter. (Default: `4000`)
 
 **overlap** (`number`): Number of characters/tokens that overlap between chunks. (Default: `50`)
 
@@ -162,7 +162,7 @@ The options documented below are passed directly at the top level of the configu
 
 **returnEachLine** (`boolean`): Whether to return each line as a separate chunk
 
-**Important:** When using the HTML strategy, all general options are ignored. Use `headers` for header-based splitting or `sections` for section-based splitting. If used together, `sections` will be ignored.
+When using the HTML strategy, all general options are ignored. Use `headers` for header-based splitting or `sections` for section-based splitting. If used together, `sections` will be ignored.
 
 ### Markdown
 
@@ -172,7 +172,7 @@ The options documented below are passed directly at the top level of the configu
 
 **returnEachLine** (`boolean`): Whether to return each line as a separate chunk
 
-**Important:** When using the `headers` option, the markdown strategy ignores all general options and content is split based on the markdown header structure. To use size-based chunking with markdown, omit the `headers` parameter.
+When using the `headers` option, the markdown strategy ignores all general options and content is split based on the markdown header structure. To use size-based chunking with markdown, omit the `headers` parameter.
 
 ### Semantic Markdown
 

package/.docs/reference/rag/database-config.md

@@ -2,7 +2,7 @@
 
 # DatabaseConfig
 
-The `DatabaseConfig` type allows you to specify database-specific configurations when using vector query tools. These configurations enable you to leverage unique features and optimizations offered by different vector stores.
+The `DatabaseConfig` type allows you to specify database-specific configurations when using vector query tools. These configurations enable you to use features and optimizations offered by different vector stores.
 
 ## Type definition
 
@@ -252,7 +252,7 @@ const vectorTool = createVectorQueryTool({
 1. **Environment Configuration**: Use different namespaces or configurations for different environments
 2. **Performance Tuning**: Start with default values and adjust based on your specific needs
 3. **Quality Filtering**: Use minScore to filter out low-quality results
-4. **Runtime Flexibility**: Override configurations at runtime for dynamic scenarios
+4. **Runtime Flexibility**: Override configurations at runtime for runtime-defined scenarios
 5. **Documentation**: Document your specific configuration choices for team members
 
 ## Migration guide

package/.docs/reference/rag/metadata-filters.md

@@ -194,8 +194,8 @@ const results = await store.query({
 
 - Equality values must be primitives (string/number/boolean). `null`/`undefined`, arrays, objects, and Date aren't allowed for equality. Range operators accept numbers or Date (Dates are normalized to epoch ms).
 - `$in`/`$nin` require **non-empty arrays of primitives**; Date elements are allowed and normalized to epoch ms. **Array equality** isn't supported.
-- Implicit AND is canonicalized (`{a:1,b:2}` → `{$and:[{a:1},{b:2}]}`). Logical operators must contain field conditions, use non-empty arrays, and appear only at the root or within other logical operators (not inside field values).
-- Keys listed in `nonFilterableMetadataKeys` at index creation are stored but not filterable; this setting is immutable.
+- Implicit AND is canonicalized (`{a:1,b:2}` → `{$and:[{a:1},{b:2}]`). Logical operators must contain field conditions and use non-empty arrays. They may appear only at the root or within other logical operators (not inside field values).
+- Keys listed in `nonFilterableMetadataKeys` at index creation are stored but not filterable. This setting is immutable.
 - $exists requires a boolean value.
 - undefined/null/empty filters are treated as no filter.
 - Each metadata key name limited to 63 characters.

package/.docs/reference/rag/rerank.md

@@ -18,7 +18,7 @@ function rerank(
 ```typescript
 import { rerank } from '@mastra/rag'
 
-const model = 'openai/gpt-5.5'
+const model = 'openai/gpt-5.6-sol'
 
 const rerankedResults = await rerank(vectorSearchResults, 'How do I deploy to production?', model, {
   weights: {

package/.docs/reference/schedules/overview.md

@@ -150,7 +150,7 @@ const updated = await mastra.schedules.update('pinger', {
 })
 ```
 
-Agent schedule patches can update `cron`, `timezone`, `prompt`, `name`, `signalType`, `tagName`, `attributes`, `providerOptions`, `ifActive`, `ifIdle`, `metadata`, and `status`. `threadId` and `resourceId` aren't patchable; create a new schedule when the thread target needs to change.
+Agent schedule patches can update `cron`, `timezone`, `prompt`, `name`, `signalType`, `tagName`, `attributes`, `providerOptions`, `ifActive`, `ifIdle`, `metadata`, and `status`. `threadId` and `resourceId` aren't patchable. Create a new schedule when the thread target needs to change.
 
 Workflow schedule patches can update `cron`, `timezone`, `inputData`, `initialState`, `requestContext`, `metadata`, and `status`. Agent-only patch fields such as `prompt`, `signalType`, and `ifIdle` throw on workflow schedules.
 

package/.docs/reference/server/register-api-route.md

@@ -20,7 +20,7 @@ The URL path for the route. Supports path parameters using `:param` syntax.
 registerApiRoute("/items/:itemId", { ... })
 ```
 
-**Note:** Custom route paths can't start with the server's configured `apiPrefix` (default: `/api`), as that prefix is reserved for built-in Mastra routes. If you set a custom `apiPrefix`, only that prefix is reserved — for example, with `apiPrefix: '/mastra/api'`, paths like `/api/my-endpoint` are allowed.
+Custom route paths can't start with the server's configured `apiPrefix` (default: `/api`), as that prefix is reserved for built-in Mastra routes. If you set a custom `apiPrefix`, only that prefix is reserved. For example, with `apiPrefix: '/mastra/api'`, paths like `/api/my-endpoint` are allowed.
 
 ### options
 

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

@@ -25,17 +25,17 @@ Server adapters register these routes when you call `server.init()`. All routes
 
 `GET /api/agents/:agentId` accepts optional query parameters to control which stored config version is applied as overrides to code-defined agents:
 
-| Parameter   | Type                     | Default   | Description                                                                                                            |
-| ----------- | ------------------------ | --------- | ---------------------------------------------------------------------------------------------------------------------- |
-| `status`    | `'draft' \| 'published'` | `'draft'` | Which stored version to resolve. `draft` returns the latest version, `published` returns the active published version. |
-| `versionId` | `string`                 | —         | A specific version ID to resolve. Takes precedence over `status`.                                                      |
+| Parameter   | Type                     | Default       | Description                                                                                                      |
+| ----------- | ------------------------ | ------------- | ---------------------------------------------------------------------------------------------------------------- |
+| `status`    | `'draft' \| 'published'` | `'published'` | Which stored version to resolve. `draft` returns the latest version, and `published` returns the active version. |
+| `versionId` | `string`                 | None          | A specific version ID to resolve. Takes precedence over `status`.                                                |
 
 ```bash
-# Get agent with latest draft overrides (default)
+# Get agent with active published overrides (default)
 GET /api/agents/my-agent
 
-# Get agent with published overrides
-GET /api/agents/my-agent?status=published
+# Get agent with latest draft overrides
+GET /api/agents/my-agent?status=draft
 
 # Get agent with a specific version's overrides
 GET /api/agents/my-agent?versionId=abc123

package/.docs/reference/signals/create-notification-inbox-tool.md

@@ -22,7 +22,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'Support Agent',
   instructions: 'Help the user triage updates.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: {
     notificationInbox: createNotificationInboxTool({ storage: notificationsStorage }),
   },

package/.docs/reference/signals/signal-provider.md

@@ -51,7 +51,7 @@ const agent = new Agent({
 })
 ```
 
-The agent calls `connect(this)`, registers any processors or tools the provider returns, and starts polling.
+The agent calls `connect(this)` and registers any processors or tools the provider returns. It then starts polling.
 
 ## Constructor parameters
 
@@ -142,7 +142,7 @@ Returns: `Record<string, unknown>`
 
 #### `subscribe(target, externalResourceId, metadata?)`
 
-Subscribe a thread to an external resource. This is a protected method — call it from within your provider implementation.
+Subscribe a thread to an external resource. This is a protected method: call it from within your provider implementation.
 
 ```typescript
 const sub = this.subscribe(
@@ -152,7 +152,7 @@ const sub = this.subscribe(
 )
 ```
 
-Returns: `SignalSubscription` — the created subscription, or the existing one with merged metadata.
+Returns: `SignalSubscription`: the created subscription, or the existing one with merged metadata.
 
 **target** (`SignalProviderTarget`): The thread to subscribe. Must include threadId and resourceId.
 
@@ -171,7 +171,7 @@ const removed = this.unsubscribe(
 )
 ```
 
-Returns: `boolean` — `true` if removed, `false` if no matching subscription existed.
+Returns: `boolean`: `true` if removed, `false` if no matching subscription existed.
 
 #### `getSubscriptions()`
 
@@ -235,7 +235,7 @@ const removed = this.unsubscribeAll({
 })
 ```
 
-Returns: `number` — count of removed subscriptions.
+Returns: `number`: count of removed subscriptions.
 
 #### `subscriptionCount`
 
@@ -253,7 +253,7 @@ Returns: `number`
 
 #### `poll(subscriptions)`
 
-Called on each poll cycle with all active subscriptions. Override to check external sources and emit notifications. The framework prevents overlapping poll cycles — if a `poll()` call takes longer than `pollInterval`, the next cycle is skipped.
+Called on each poll cycle with all active subscriptions. Override to check external sources and emit notifications. The framework prevents overlapping poll cycles: if a `poll()` call takes longer than `pollInterval`, the next cycle is skipped.
 
 ```typescript
 async poll(subscriptions: SignalSubscription[]) {
@@ -271,7 +271,7 @@ async poll(subscriptions: SignalSubscription[]) {
 
 #### `startPolling()`
 
-Start the polling timer. Called by the Agent after `connect()`. Idempotent — calling multiple times has no effect.
+Start the polling timer. Called by the Agent after `connect()`. Idempotent: calling multiple times has no effect.
 
 ```typescript
 provider.startPolling()
@@ -289,7 +289,7 @@ provider.stopPolling()
 
 #### `handleWebhook(request)`
 
-Handle an incoming webhook request. Override to parse the payload, match it to subscriptions, and emit notification signals. See [`WebhookSignalProvider`](https://mastra.ai/reference/signals/webhook-signal-provider) for a ready-to-use implementation.
+Handle an incoming webhook request. Override to parse the payload and match it to subscriptions. Then emit notification signals. See [`WebhookSignalProvider`](https://mastra.ai/reference/signals/webhook-signal-provider) for a ready-to-use implementation.
 
 ```typescript
 async handleWebhook(request) {

package/.docs/reference/storage/clickhouse.md

@@ -129,7 +129,7 @@ yarn dlx mastra migrate
 bun x mastra migrate
 ```
 
-The migration copies span data from `mastra_ai_spans` into `mastra_span_events` in day-sized batches. It handles column mapping, deduplicates legacy rows, and preserves the original table as a backup. After migration, traces appear in Studio through the vNext adapter.
+The migration copies span data from `mastra_ai_spans` into `mastra_span_events` in day-sized batches. It handles column mapping and deduplicates legacy rows. The original table remains as a backup. After migration, traces appear in Studio through the vNext adapter.
 
 > **Note:** The legacy table isn't deleted. Drop it manually after verifying the migration.
 
@@ -261,7 +261,7 @@ Set `cluster` to add `ON CLUSTER` to Mastra-owned DDL such as table creation, ma
 
 Manual maintenance such as `optimizeTable()` and `materializeTtl()` runs on every replica when `cluster` is set. These operations can be expensive on a large cluster. Prefer running them outside peak hours, and let routine merges happen on the background merge queue rather than triggering them on every restart.
 
-If existing Mastra tables use local `MergeTree` or `ReplacingMergeTree` engines, initialization fails while `replication` is enabled. Mastra refuses to silently convert local tables because copy-and-swap is unsafe across replicas. To migrate, recreate the affected tables as `Replicated*` before enabling replication. The typical sequence is: rename the local table, run `CREATE TABLE ... ENGINE = ReplicatedMergeTree(...) ON CLUSTER ...`, run `INSERT INTO ... SELECT * FROM <renamed_local>`, then drop the renamed local table.
+If existing Mastra tables use local `MergeTree` or `ReplacingMergeTree` engines, initialization fails while `replication` is enabled. Mastra refuses to silently convert local tables because copy-and-swap is unsafe across replicas. To migrate, recreate the affected tables as `Replicated*` before enabling replication. To migrate safely, rename the local table, run `CREATE TABLE ... ENGINE = ReplicatedMergeTree(...) ON CLUSTER ...`, run `INSERT INTO ... SELECT * FROM <renamed_local>`, then drop `<renamed_local>`.
 
 Don't set `replication` on ClickHouse Cloud. Cloud rewrites `MergeTree` to `SharedMergeTree` server-side, and explicit `ReplicatedMergeTree` engines produce incorrect DDL. `replication` is only for self-managed multi-replica clusters.
 
@@ -271,7 +271,7 @@ Don't set `replication` on ClickHouse Cloud. Cloud rewrites `MergeTree` to `Shar
 
 ## Hosting options
 
-ClickHouse runs anywhere you can reach it over HTTP. Two common choices:
+ClickHouse runs anywhere you can reach it over HTTP. Common choices include:
 
 - **[ClickHouse Cloud](https://clickhouse.com/cloud)**: Managed service with a free trial tier. Provides connection details directly compatible with `url`, `username`, and `password`.
 - **Self-hosted**: Run the official [`clickhouse/clickhouse-server`](https://hub.docker.com/r/clickhouse/clickhouse-server) container or install from the [official packages](https://clickhouse.com/docs/en/install). Suitable for VPS, dedicated hardware, or Kubernetes.
@@ -333,7 +333,7 @@ export const mastra = new Mastra({
 })
 ```
 
-Two ways to provision the database:
+Provision the database with either option:
 
 - **Managed**: Use ClickHouse Cloud. Set `CLICKHOUSE_URL`, `CLICKHOUSE_USERNAME`, and `CLICKHOUSE_PASSWORD` as environment variables in your hosting platform.
 - **Self-hosted on Railway**: Add a ClickHouse service to your Railway project from the official Docker image, then reference it in the application service through Railway's private networking.

package/.docs/reference/storage/cloudflare-d1.md

@@ -61,11 +61,11 @@ export const mastra = new Mastra({
 })
 ```
 
-> **Note:** When using `import { env } from 'cloudflare:workers'`, `D1Store` must be initialized inline inside `new Mastra({...})` — not extracted to a module-level variable. Alternatively, initialize `D1Store` inside the `fetch` handler after `env` is available. See [CloudflareDeployer reference](https://mastra.ai/reference/deployer/cloudflare) for details.
+> **Note:** When using `import { env } from 'cloudflare:workers'`, `D1Store` must be initialized inline inside `new Mastra({...})`: not extracted to a module-level variable. Alternatively, initialize `D1Store` inside the `fetch` handler after `env` is available. See [CloudflareDeployer reference](https://mastra.ai/reference/deployer/cloudflare) for details.
 
 ### Using in a Cloudflare Worker without HTTP routes
 
-If you want to call Mastra directly in a Worker — for example, to run an agent or trigger a workflow — without serving HTTP routes, you don't need `CloudflareDeployer`. Access the D1 binding from the worker's `env` parameter and call Mastra programmatically.
+If you want to call Mastra directly in a Worker (for example, to run an agent or trigger a workflow) without serving HTTP routes, you don't need `CloudflareDeployer`. Access the D1 binding from the worker's `env` parameter and call Mastra programmatically.
 
 ```typescript
 import { D1Store } from '@mastra/cloudflare-d1'
@@ -213,8 +213,8 @@ export default {
 
 ### Transactions & Consistency
 
-Cloudflare D1 provides transactional guarantees for single-row operations. This means that multiple operations can be executed as a single, all-or-nothing unit of work.
+Cloudflare D1 provides transactional guarantees for single-row operations. Multiple operations can be executed as a single, all-or-nothing unit of work.
 
 ### Table Creation & Migrations
 
-Tables are created automatically when storage is initialized (and can be isolated per environment using the `tablePrefix` option), but advanced schema changes—such as adding columns, changing data types, or modifying indexes—require manual migration and careful planning to avoid data loss.
+Tables are created automatically when storage is initialized (and can be isolated per environment using the `tablePrefix` option), but advanced schema changes require manual migration and careful planning. Examples include adding columns or changing data types and indexes to avoid data loss.

package/.docs/reference/storage/convex.md

@@ -182,7 +182,7 @@ During batched cleanup, cache metadata can temporarily use an internal `deleted`
 
 `clear()` only removes rows whose stored `keyPrefix` exactly matches the configured `keyPrefix`. It doesn't clear nested prefixes by string prefix matching. Each `listPush()` refreshes the list TTL using the cache's configured `ttlMs`.
 
-Use a non-empty `keyPrefix` unless you intentionally want `clear()` to remove every cache key in the deployment. Expired list rows are reclaimed incrementally during reads and writes; `clear()` removes all rows for the prefix.
+Use a non-empty `keyPrefix` unless you intentionally want `clear()` to remove every cache key in the deployment. Expired list rows are reclaimed incrementally during reads and writes. `clear()` removes all rows for the prefix.
 
 `ConvexServerCache` works best for durable replay of moderate-frequency events. For high-frequency token streams, prefer batching events or using a lower-latency cache backend.
 
@@ -217,14 +217,14 @@ All typed tables include:
 - An `id` field for Mastra's record ID (distinct from Convex's auto-generated `_id`)
 - A `by_record_id` index for efficient lookups by Mastra ID
 
-This design ensures compatibility with Mastra's storage contract while leveraging Convex's automatic indexing and real-time capabilities.
+This design ensures compatibility with Mastra's storage contract while using Convex's automatic indexing and real-time capabilities.
 
 ### Environment variables
 
 Set these environment variables for your deployment:
 
-- `CONVEX_URL` – Your Convex deployment URL
-- `CONVEX_ADMIN_KEY` – Admin authentication token (get from Convex dashboard)
+- `CONVEX_URL`: Your Convex deployment URL
+- `CONVEX_ADMIN_KEY`: Admin authentication token (get from Convex dashboard)
 
 ## Related
 

package/.docs/reference/storage/dsql.md

@@ -183,7 +183,7 @@ storage.db // Database client for executing queries
 storage.pool // Underlying pg.Pool instance
 ```
 
-This enables direct queries and custom transaction management. When using these fields:
+It supports direct queries and custom transaction management. When using these fields:
 
 - You are responsible for proper connection and transaction handling.
 - Closing the store (`storage.close()`) will destroy the connection pool if it was created by the store.
@@ -199,7 +199,7 @@ Connections are authenticated with IAM. No database passwords are required. `@ma
 
 #### Single database, schema-based isolation
 
-Each cluster exposes a single database named `postgres`. Logical separation is done via schemas. The `schemaName` option controls where Mastra tables are created.
+Each cluster exposes a single database `postgres`. Logical separation is done via schemas. The `schemaName` option controls where Mastra tables are created.
 
 #### No PostgreSQL extensions
 
@@ -243,7 +243,7 @@ export const dsqlAgent = new Agent({
   name: 'DSQL Agent',
   instructions:
     'You are an AI agent with the ability to automatically recall memories from previous interactions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new DSQLStore({
       id: 'dsql-agent-storage',