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

package/.docs/reference/memory/recall.md

@@ -59,9 +59,9 @@ const { messages } = await memory.recall({
 })
 ```
 
-All metadata entries are combined with AND semantics. A message must match every key and value with exact type equality. `null` matches metadata that is explicitly set to `null`; it doesn't match a missing key.
+All metadata entries are combined with AND semantics. A message must match every key and value with exact type equality. `null` matches metadata that's explicitly set to `null`. It doesn't match a missing key.
 
-Metadata filters only support shallow scalar values: `string`, finite `number`, `boolean`, and `null`. Nested objects, arrays, `NaN`, and infinities are not supported. 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. Arbitrary metadata filters may require scanning candidate messages, so narrow the query with `threadId`, `resourceId`, or `dateRange` when possible.
+Metadata filters only support shallow scalar values: `string`, finite `number`, `boolean`, and `null`. Nested objects, arrays, `NaN`, and infinities aren't supported. Metadata keys must start with a letter or underscore and contain only alphanumeric or underscore characters. The limit is 128 characters. Reserved prototype keys such as `__proto__`, `constructor`, and `prototype` aren't allowed. Performance depends on the storage backend. Arbitrary metadata filters may require scanning candidate messages, so narrow the query with `threadId`, `resourceId`, or `dateRange` when possible.
 
 ## Returns
 

package/.docs/reference/memory/serialized-memory-config.md

@@ -68,7 +68,7 @@ new MastraEditor({
 
 ## Related
 
-- [Memory class](https://mastra.ai/reference/memory/memory-class) — the runtime type this config hydrates into.
-- [Observational memory](https://mastra.ai/reference/memory/observational-memory) — full observational memory reference.
-- [BuilderAgentDefaults](https://mastra.ai/reference/editor/agent-builder/builder-agent-defaults) — where this type is pinned as the Builder default.
-- [Agent Builder: Memory](https://mastra.ai/docs/agent-builder/memory) — concept and worked examples.
+- [Memory class](https://mastra.ai/reference/memory/memory-class): The runtime type this config hydrates into.
+- [Observational memory](https://mastra.ai/reference/memory/observational-memory): Full observational memory reference.
+- [BuilderAgentDefaults](https://mastra.ai/reference/editor/agent-builder/builder-agent-defaults): Where this type is pinned as the Builder default.
+- [Agent Builder: Memory](https://mastra.ai/docs/agent-builder/memory): Concept and worked examples.

package/.docs/reference/memory/summarizeConversation.md

@@ -2,11 +2,11 @@
 
 # summarizeConversation()
 
-The standalone `summarizeConversation()` function summarizes a conversation in one shot. It distills the messages you pass in with the same Observer plumbing that powers [Observational Memory](https://mastra.ai/reference/memory/observational-memory) — without Observational Memory attached to an agent, and without reading from or writing to storage.
+The standalone `summarizeConversation()` function summarizes a conversation in one shot. It distills the messages you pass in with the same Observer plumbing that powers [Observational Memory](https://mastra.ai/reference/memory/observational-memory): without Observational Memory attached to an agent, and without reading from or writing to storage.
 
-Nothing is written back to memory. The summary and extracted values are returned to you (and to each extractor's `onExtracted` hook), so you decide where they go — for example your own database.
+Nothing is written back to memory. The summary and extracted values are returned to you (and to each extractor's `onExtracted` hook), so you decide where they go: for example your own database.
 
-Use this when you already have the messages in hand and want explicit control over what gets summarized. To summarize a stored thread by ID instead, use [`Memory.summarizeThread()`](https://mastra.ai/reference/memory/summarizeThread), which loads the messages for you.
+Use this when you already have the messages in hand and want explicit control over what gets summarized. For a stored thread identified by ID, use [`Memory.summarizeThread()`](https://mastra.ai/reference/memory/summarizeThread), which loads the messages for you.
 
 ## Usage example
 

package/.docs/reference/memory/summarizeThread.md

@@ -2,13 +2,13 @@
 
 # Memory.summarizeThread()
 
-The `.summarizeThread()` method summarizes a thread's conversation in one shot. It loads the thread's messages from storage and distills them with the same Observer plumbing that powers [Observational Memory](https://mastra.ai/reference/memory/observational-memory) — as a standalone call, without Observational Memory attached to an agent.
+The `.summarizeThread()` method summarizes a thread's conversation in one shot. It loads the thread's messages from storage and distills them with the same Observer plumbing that powers [Observational Memory](https://mastra.ai/reference/memory/observational-memory): as a standalone call, without Observational Memory attached to an agent.
 
 Messages load page-by-page starting from the newest, bounded by `lastMessages` and `maxInputTokens`, so summarizing a long thread doesn't read its entire history from storage.
 
-Nothing is written back to memory. The summary and extracted values are returned to you (and to each extractor's `onExtracted` hook), so you decide where they go — for example your own database.
+Nothing is written back to memory. The summary and extracted values are returned to you (and to each extractor's `onExtracted` hook), so you decide where they go: for example your own database.
 
-Use this when a session ends and you want a summary or structured extraction of the whole conversation, such as a voice call at hang-up. To summarize messages you already have in hand (without loading them from a thread), use the standalone [`summarizeConversation()`](https://mastra.ai/reference/memory/summarizeConversation) function instead — it takes the same options with `messages` in place of `threadId`.
+Use this when a session ends and you want a summary or structured extraction of the whole conversation, such as a voice call at hang-up. For messages you already have in hand (without loading them from a thread), use the standalone [`summarizeConversation()`](https://mastra.ai/reference/memory/summarizeConversation) function instead. It takes the same options with `messages` in place of `threadId`.
 
 ## Usage example
 

package/.docs/reference/observability/feedback.md

@@ -73,7 +73,7 @@ await observability.createFeedback({
 })
 ```
 
-The HTTP and client SDK create route accepts `CreateFeedbackBody`, sets `timestamp` server-side, and generates `feedbackId` when omitted:
+The HTTP and client SDK create route accepts `CreateFeedbackBody` and sets `timestamp` server-side. It generates `feedbackId` when omitted:
 
 ```typescript
 await mastraClient.createFeedback({

package/.docs/reference/observability/metrics/automatic-metrics.md

@@ -12,7 +12,7 @@ Metrics are extracted from spans when they end. The observability layer inspects
 
 ### What affects whether a metric is available
 
-Two conditions must be true for a metric to reach storage:
+A metric reaches storage when:
 
 1. `MastraStorageExporter` is configured as an exporter.
 2. The storage backend supports metrics (ClickHouse, DuckDB, or Postgres v-next with the observability domain enabled).
@@ -33,7 +33,7 @@ Duration metrics record execution time in milliseconds, calculated from the span
 
 ## Token usage metrics
 
-Token metrics are emitted only from `MODEL_GENERATION` spans that include `usage` data. If the provider doesn't report usage, no token metrics are emitted for that span.
+Token metrics are emitted only from `MODEL_GENERATION` spans that include `usage` data. Token metrics require usage data from the provider.
 
 ### Input token metrics
 
@@ -64,7 +64,7 @@ The detailed breakdown metrics (everything except `total_input` and `total_outpu
 
 ### When cost context is attached
 
-Cost context is attached to token metrics when the embedded pricing registry has a matching entry for the provider and model. The registry ships with Mastra and covers common providers and models. If no match is found, token metrics are still emitted but without cost fields.
+Cost context is attached to token metrics when the embedded pricing registry has a matching entry for the provider and model. Mastra includes the registry and covers common providers and models. If no match is found, token metrics are still emitted but without cost fields.
 
 ### What cost fields may be included
 
@@ -80,9 +80,9 @@ Cost context is attached to token metrics when the embedded pricing registry has
 
 ### How metrics relate to spans and trace context
 
-Each metric carries a `CorrelationContext` snapshot from the span that produced it. This context is stored alongside the metric value and lets you navigate from a metric to the exact span and trace.
+Each metric carries a `CorrelationContext` snapshot from the span that produced it. This context is stored alongside the metric value and links a metric to the exact span and trace.
 
-The correlation fields are grouped into four categories:
+Correlation fields use these categories:
 
 **Trace correlation**
 
@@ -110,7 +110,7 @@ The correlation fields are grouped into four categories:
 
 ### Why correlation helps with debugging
 
-When you spot a spike in latency or token usage on the Metrics dashboard, correlation context lets you drill directly into the trace that produced the metric. From there you can inspect the individual span to find the root cause: a slow tool call, a large prompt, or an unexpected error.
+When you spot a spike in latency or token usage on the Metrics dashboard, correlation context lets you drill directly into the trace that produced the metric. From there you can inspect the individual span. The root cause might be a slow tool call or a large prompt. It might also be an unexpected error.
 
 ## Troubleshooting
 
@@ -129,7 +129,7 @@ When you spot a spike in latency or token usage on the Metrics dashboard, correl
 ### Token metrics are missing
 
 - **Span is a model generation**: Token metrics are only emitted from `MODEL_GENERATION` spans.
-- **Provider reports usage**: The model provider must include `usage` data in its response. If usage is absent, no token metrics are emitted.
+- **Provider reports usage**: The model provider must include `usage` data in its response. Usage data is required to emit token metrics.
 
 ## Related
 

package/.docs/reference/observability/tracing/bridges/datadog.md

@@ -40,7 +40,7 @@ Extends `BaseExporterConfig`, which includes:
 createSpan(options: CreateSpanOptions<SpanType>): SpanIds | undefined
 ```
 
-Called by the Mastra observability instance during span construction. Creates a dd-trace APM span eagerly via `tracer.startSpan()` and returns Mastra-compatible identifiers. The returned IDs are used by Mastra throughout the span's lifetime; the dd-trace span object is stored internally and used for scope activation.
+Called by the Mastra observability instance during span construction. Creates a dd-trace APM span eagerly via `tracer.startSpan()` and returns Mastra-compatible identifiers. The returned IDs are used by Mastra throughout the span's lifetime. The dd-trace span object is stored internally and used for scope activation.
 
 **Returns:** `SpanIds | undefined` - `{ spanId, traceId, parentSpanId }`, or `undefined` if the bridge is disabled.
 
@@ -151,7 +151,7 @@ const mastra = new Mastra({
 })
 ```
 
-> **Note:** Don't combine `DatadogBridge` with `DatadogExporter` in the same configuration — both emit to LLM Observability and would double-write the same data.
+> **Note:** Don't combine `DatadogBridge` with `DatadogExporter` in the same configuration. Both emit to LLM Observability and would double-write the same data.
 
 ## Setup requirements
 

package/.docs/reference/observability/tracing/exporters/cloud-exporter.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/observability@1.8.0`. **Deprecated in `1.12.0`** in favor of [`MastraPlatformExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-platform-exporter).
 
-> **Deprecated:** `CloudExporter` is retained for backward compatibility and will be removed in a future major version. Use [`MastraPlatformExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-platform-exporter) for new projects. The two classes share the same constructor, environment variables, and runtime behavior; `CloudExporter` keeps its original `mastra-cloud-observability-exporter` exporter `name` and `CLOUD_EXPORTER_*` error IDs so monitoring rules built against it keep working.
+> **Deprecated:** `CloudExporter` is retained for backward compatibility and will be removed in a future major version. Use [`MastraPlatformExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-platform-exporter) for new projects. Both classes share the same constructor, environment variables, and runtime behavior; `CloudExporter` keeps its original `mastra-cloud-observability-exporter` exporter `name` and `CLOUD_EXPORTER_*` error IDs so monitoring rules built against it keep working.
 
 Sends tracing spans, logs, metrics, scores, and feedback to the Mastra platform for online visualization and monitoring.
 
@@ -106,7 +106,7 @@ async onMetricEvent(event: MetricEvent): Promise<void>
 
 Processes metric signals for Cloud export.
 
-Every `MetricEvent` passed to this handler is buffered and exported to the Cloud metrics endpoint derived from the configured base endpoint. Additional filtering by metric subtype or status inside `CloudExporter` isn't performed; the exporter forwards every metric event it receives unless it's disabled.
+Every `MetricEvent` passed to this handler is buffered and exported to the Cloud metrics endpoint derived from the configured base endpoint. Additional filtering by metric subtype or status inside `CloudExporter` isn't performed. The exporter forwards every metric event it receives unless it's disabled.
 
 **Returns:** `Promise<void>` after the metric event has been accepted for buffering.
 
@@ -130,7 +130,7 @@ async onFeedbackEvent(event: FeedbackEvent): Promise<void>
 
 Processes feedback signals for Cloud export.
 
-Every `FeedbackEvent` passed to this handler is buffered and exported to the Cloud feedback endpoint derived from the configured base endpoint. No feedback-type filtering inside `CloudExporter` is performed; all feedback events received here are forwarded unless the exporter is disabled.
+Every `FeedbackEvent` passed to this handler is buffered and exported to the Cloud feedback endpoint derived from the configured base endpoint. No feedback-type filtering inside `CloudExporter` is performed. All feedback events received here are forwarded unless the exporter is disabled.
 
 **Returns:** `Promise<void>` after the feedback event has been accepted for buffering.
 

package/.docs/reference/observability/tracing/exporters/default-exporter.md

@@ -4,7 +4,7 @@
 
 **Deprecated in `@mastra/observability@1.12.0`** in favor of [`MastraStorageExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-storage-exporter).
 
-> **Deprecated:** `DefaultExporter` is retained for backward compatibility and will be removed in a future major version. Use [`MastraStorageExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-storage-exporter) for new projects. The two classes share the same constructor, configuration, and runtime behavior; `DefaultExporter` keeps its original `mastra-default-observability-exporter` exporter `name` so monitoring rules built against it keep working.
+> **Deprecated:** `DefaultExporter` is retained for backward compatibility and will be removed in a future major version. Use [`MastraStorageExporter`](https://mastra.ai/reference/observability/tracing/exporters/mastra-storage-exporter) for new projects. Both classes share the same constructor, configuration, and runtime behavior. `DefaultExporter` keeps its original `mastra-default-observability-exporter` exporter `name` so monitoring rules built against it keep working.
 
 Persists observability events to Mastra Storage with automatic batching and retry logic.
 

package/.docs/reference/observability/tracing/exporters/langfuse.md

@@ -107,7 +107,7 @@ const agent = new Agent({
   id: 'support-agent',
   name: 'support-agent',
   instructions: prompt.compile(),
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   defaultGenerateOptions: {
     tracingOptions: buildTracingOptions(
       withLangfusePrompt({ name: prompt.name, version: prompt.version }),

package/.docs/reference/observability/tracing/exporters/mastra-platform-exporter.md

@@ -108,7 +108,7 @@ async onMetricEvent(event: MetricEvent): Promise<void>
 
 Processes metric signals for export.
 
-Every `MetricEvent` passed to this handler is buffered and exported to the metrics endpoint derived from the configured base endpoint. No additional filtering by metric subtype or status inside `MastraPlatformExporter` is performed; the exporter forwards every metric event it receives unless it's disabled.
+Every `MetricEvent` passed to this handler is buffered and exported to the metrics endpoint derived from the configured base endpoint. No additional filtering by metric subtype or status inside `MastraPlatformExporter` is performed. The exporter forwards every metric event it receives unless it's disabled.
 
 **Returns:** `Promise<void>` after the metric event has been accepted for buffering.
 
@@ -132,7 +132,7 @@ async onFeedbackEvent(event: FeedbackEvent): Promise<void>
 
 Processes feedback signals for export.
 
-Every `FeedbackEvent` passed to this handler is buffered and exported to the feedback endpoint derived from the configured base endpoint. No feedback-type filtering inside `MastraPlatformExporter` is performed; all feedback events received here are forwarded unless the exporter is disabled.
+Every `FeedbackEvent` passed to this handler is buffered and exported to the feedback endpoint derived from the configured base endpoint. No feedback-type filtering inside `MastraPlatformExporter` is performed. All feedback events received here are forwarded unless the exporter is disabled.
 
 **Returns:** `Promise<void>` after the feedback event has been accepted for buffering.
 
@@ -192,7 +192,7 @@ Errors raised by `MastraPlatformExporter` use the `MASTRA_PLATFORM_EXPORTER_*` `
 
 ## Span wire format
 
-The shape of each span sent to Mastra platform is documented here for reference only — it's not exported from `@mastra/observability` and shouldn't be imported. The exporter spreads the original `AnyExportedSpan` (so the source field names are preserved) and layers a small set of platform-friendly aliases on top:
+The shape of each span sent to Mastra platform is documented here for reference only: it's not exported from `@mastra/observability` and shouldn't be imported. The exporter spreads the original `AnyExportedSpan` (so the source field names are preserved) and layers a small set of platform-friendly aliases on top:
 
 ```typescript
 type MastraPlatformSpanRecord = AnyExportedSpan & {
@@ -231,7 +231,7 @@ const customExporter = new MastraPlatformExporter({
 
 ## Migrating from `CloudExporter`
 
-The two classes share the same constructor signature, environment variables, and behavior. To migrate, replace the import and constructor:
+Both classes share the same constructor signature, environment variables, and behavior. To migrate, replace the import and constructor:
 
 ```typescript
 // Before

package/.docs/reference/observability/tracing/exporters/mastra-storage-exporter.md

@@ -162,7 +162,7 @@ const customExporter = new MastraStorageExporter({
 
 ## Migrating from `DefaultExporter`
 
-The two classes share the same constructor signature and behavior. To migrate, replace the import and constructor:
+Both classes share the same constructor signature and behavior. To migrate, replace the import and constructor:
 
 ```typescript
 // Before

package/.docs/reference/observability/tracing/interfaces.md

@@ -803,7 +803,7 @@ interface CustomSamplerOptions {
 
 ### `ConfigSelector`
 
-Function to select which observability instance to use for a given span.
+Function to select which observability instance to use for a span.
 
 ```typescript
 type ConfigSelector = (

package/.docs/reference/observability/tracing/processors/sensitive-data-filter.md

@@ -22,7 +22,7 @@ new Observability({
 })
 ```
 
-If a config already includes a `SensitiveDataFilter` in `spanOutputProcessors`, the auto-applied filter is skipped to avoid double redaction. Pre-instantiated `ObservabilityInstance` values aren't modified — add a `SensitiveDataFilter` to their processors yourself if needed.
+If a config already includes a `SensitiveDataFilter` in `spanOutputProcessors`, the auto-applied filter is skipped to avoid double redaction. Pre-instantiated `ObservabilityInstance` values aren't modified. Add a `SensitiveDataFilter` to their processors yourself if needed.
 
 ## Constructor
 

package/.docs/reference/observability/tracing/span-filtering.md

@@ -2,7 +2,7 @@
 
 # Span filtering
 
-Span filtering controls which spans are exported from an observability config. Use it to reduce noise, lower per-span costs, or keep only the spans that matter for a specific exporter or environment.
+Span filtering controls which spans are exported from an observability config. Use it to reduce noise or lower per-span costs. It can also keep only the spans that matter for a specific exporter or environment.
 
 For a shorter overview of tracing configuration, see [Tracing](https://mastra.ai/docs/observability/tracing/overview).
 

package/.docs/reference/processors/batch-parts-processor.md

@@ -46,7 +46,7 @@ export const agent = new Agent({
   id: 'batched-agent',
   name: 'batched-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   outputProcessors: [
     new BatchPartsProcessor({
       batchSize: 5,

package/.docs/reference/processors/cost-guard-processor.md

@@ -14,7 +14,7 @@ Supports three scoping modes:
 - **Resource scope** (default): Tracks cumulative cost per `resourceId` across runs
 - **Thread scope**: Tracks cumulative cost per `threadId` across runs
 
-> **Approximate cost guard.** Cost data is persisted asynchronously via buffered exporters in the observability pipeline. Fast-running agents may exceed the configured limit before metrics are available for query. Treat `maxCost` as a best-effort threshold, not a hard ceiling.
+> **Approximate cost guard.** Cost data is persisted asynchronously via buffered exporters in the observability pipeline. Fast-running agents may exceed the configured limit before metrics are available for query. Treat `maxCost` as an approximate threshold that fast-running agents may exceed.
 
 ## Usage example
 

package/.docs/reference/processors/language-detector.md

@@ -62,7 +62,7 @@ export const agent = new Agent({
   id: 'multilingual-agent',
   name: 'multilingual-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new LanguageDetector({
       model: 'openrouter/openai/gpt-oss-safeguard-20b',

package/.docs/reference/processors/message-history-processor.md

@@ -48,7 +48,7 @@ export const agent = new Agent({
   id: 'memory-agent',
   name: 'memory-agent',
   instructions: 'You are a helpful assistant with conversation memory',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new MessageHistory({
       storage,

package/.docs/reference/processors/moderation-processor.md

@@ -62,7 +62,7 @@ export const agent = new Agent({
   id: 'moderated-agent',
   name: 'moderated-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new ModerationProcessor({
       model: 'openrouter/openai/gpt-oss-safeguard-20b',
@@ -88,7 +88,7 @@ export const agent = new Agent({
   id: 'output-moderated-agent',
   name: 'output-moderated-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   outputProcessors: [
     // Batch stream parts first to reduce LLM calls
     new BatchPartsProcessor({

package/.docs/reference/processors/pii-detector.md

@@ -2,7 +2,7 @@
 
 # PIIDetector
 
-The `PIIDetector` is a **hybrid processor** that can be used for both input and output processing to detect and redact personally identifiable information (PII) for privacy compliance. This processor helps maintain privacy by identifying various types of PII and providing flexible strategies for handling them, including multiple redaction methods to ensure compliance with GDPR, CCPA, HIPAA, and other privacy regulations.
+The `PIIDetector` is a **hybrid processor** that can be used for both input and output processing to detect and redact personally identifiable information (PII) for privacy compliance. This processor helps maintain privacy by identifying types of PII and providing flexible strategies for handling them, including multiple redaction methods to ensure compliance with GDPR, CCPA, HIPAA, and other privacy regulations.
 
 ## Usage example
 
@@ -64,7 +64,7 @@ export const agent = new Agent({
   id: 'private-agent',
   name: 'private-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new PIIDetector({
       model: 'openrouter/openai/gpt-oss-safeguard-20b',
@@ -93,7 +93,7 @@ export const agent = new Agent({
   id: 'output-pii-agent',
   name: 'output-pii-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   outputProcessors: [
     // Batch stream parts first to reduce LLM calls
     new BatchPartsProcessor({

package/.docs/reference/processors/processor-interface.md

@@ -6,7 +6,7 @@ The `Processor` interface defines the contract for all processors in Mastra. Pro
 
 ## When processor methods run
 
-The eight processor methods run at different points in the agent execution lifecycle:
+Processor methods run at different points in the agent execution lifecycle:
 
 ```text
 ┌────────────────────────────────────────────────────────────────────┐
@@ -168,16 +168,16 @@ Use `messages` when you only need to read, map over, or lightly edit fields on t
 
 ### Persistence
 
-When memory is enabled, only what ends up in `messageList` after all processors finish is persisted to storage. The two return styles are equivalent for persistence:
+When memory is enabled, only what ends up in `messageList` after all processors finish is persisted to storage. Both return styles are equivalent for persistence:
 
-- Mutating `messageList` directly (or returning the same `MessageList` instance) — recorded mutations are applied in place, so the saved conversation reflects your changes.
-- Returning a `MastraDBMessage[]` or `{ messages, systemMessages }` — Mastra reconciles the returned array against `messageList` for the current stage, removing missing messages and replacing system messages.
+- When you mutate `messageList` directly (or return the same `MessageList` instance), recorded mutations are applied in place, so the saved conversation reflects your changes.
+- When you return a `MastraDBMessage[]` or `{ messages, systemMessages }`, Mastra reconciles the returned array against `messageList` for the current stage, removing missing messages and replacing system messages.
 
-Returning a different `MessageList` instance is an error; always mutate the one passed to your processor.
+Returning a different `MessageList` instance is an error. Always mutate the one passed to your processor.
 
 ### Reading text from a message
 
-`MastraDBMessage.content` is a structured object, not a string. The canonical way to read user or assistant text is `content.parts`:
+`MastraDBMessage.content` uses a structured object. Strings aren't supported. The canonical way to read user or assistant text is `content.parts`:
 
 ```typescript
 import type { MastraDBMessage } from '@mastra/core/memory'
@@ -313,10 +313,10 @@ processInputStep?<TTripwireMetadata = unknown>(
 
 `processInputStep` can return several shapes:
 
-- **`ProcessInputStepResult` object** — override any combination of the properties below for this step (described next).
-- **`MessageList`** — return the same `messageList` instance to signal you mutated messages in place.
-- **`MastraDBMessage[]`** — return a transformed messages array; replaces the step's messages.
-- **`void` or `undefined`** — return nothing to leave the step unchanged.
+- **`ProcessInputStepResult` object**: Override any combination of the properties below for this step (described next).
+- **`MessageList`**: Return the same `messageList` instance to signal you mutated messages in place.
+- **`MastraDBMessage[]`**: Return a transformed messages array. Replaces the step's messages.
+- **`void` or `undefined`**: Return nothing to leave the step unchanged.
 
 The object form can return any combination of these properties:
 
@@ -480,7 +480,7 @@ Handles LLM API rejection errors before they surface as final errors. This runs
 
 Add processors that implement `processAPIError` to an agent's `errorProcessors` array.
 
-Processors can inspect the error, modify the request (for example, by appending messages to the `messageList`), and return `{ retry: true }` to signal a retry with the modified state.
+Processors can inspect the error and modify the request, for example by appending messages to the `messageList`. Return `{ retry: true }` to retry with the modified state.
 
 ```typescript
 processAPIError?(args: ProcessAPIErrorArgs): Promise<ProcessAPIErrorResult | void> | ProcessAPIErrorResult | void;
@@ -782,7 +782,7 @@ export class DynamicModelProcessor implements Processor {
 
     // Switch to powerful model after tool calls
     if (steps.length > 0 && steps[steps.length - 1].toolCalls?.length) {
-      return { model: 'openai/gpt-5.5' }
+      return { model: 'openai/gpt-5.6-sol' }
     }
 
     // Disable tools after 5 steps to force completion
@@ -896,7 +896,7 @@ export class WordCounter implements Processor {
 
 Every processor receives a `state` object in `processLLMRequest`, `processLLMResponse`, `processOutputStream`, `processOutputStep`, `processOutputResult`, and `processAPIError`. State has three important properties:
 
-- **Per-processor**: Each processor gets its own `state` object, keyed by the processor's `id`. Two processors with different ids can't read or overwrite each other's state.
+- **Per-processor**: Each processor gets its own `state` object, keyed by the processor's `id`. Processors with different ids can't read or overwrite each other's state.
 - **Per-request**: A fresh state object is created at the start of every `agent.generate()` or `agent.stream()` call. State doesn't leak between requests or between users.
 - **Shared across methods**: Within one request, the same `state` object is passed to `processLLMRequest` (before the provider call), `processLLMResponse` (after the step completes), `processOutputStream` (for every chunk), `processOutputStep` (after every LLM step), `processOutputResult` (once at the end), and `processAPIError` (when an LLM call fails). For example, `processLLMRequest` can stash a cache key and `processLLMResponse` can read it back to write the response.
 

package/.docs/reference/processors/prompt-injection-detector.md

@@ -2,7 +2,7 @@
 
 # PromptInjectionDetector
 
-The `PromptInjectionDetector` is an **input processor** that detects and prevents prompt injection attacks, jailbreaks, and system manipulation attempts before messages are sent to the language model. This processor helps maintain security by identifying various types of injection attempts and providing flexible strategies for handling them, including content rewriting to neutralize attacks while preserving legitimate user intent.
+The `PromptInjectionDetector` is an **input processor** that detects and prevents prompt injection attacks, jailbreaks, and system manipulation attempts before messages are sent to the language model. This processor helps maintain security by identifying types of injection attempts and providing flexible strategies for handling them, including content rewriting to neutralize attacks while preserving legitimate user intent.
 
 ## Usage example
 
@@ -56,7 +56,7 @@ export const agent = new Agent({
   id: 'secure-agent',
   name: 'secure-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new PromptInjectionDetector({
       model: 'openrouter/openai/gpt-oss-safeguard-20b',

package/.docs/reference/processors/provider-history-compat.md

@@ -4,7 +4,7 @@
 
 The `ProviderHistoryCompat` processor handles provider-specific history incompatibilities. It can rewrite the outbound language model prompt before a provider call, or react to API errors and retry with repaired message history.
 
-Use it when an agent may switch between model providers, reuse message history across providers, or call a provider that rejects fields emitted by another provider.
+Use it when an agent may switch between model providers or reuse message history across providers. It also handles providers that reject fields emitted by another provider.
 
 ## Usage example
 

package/.docs/reference/processors/regex-filter-processor.md

@@ -2,7 +2,7 @@
 
 # RegexFilterProcessor
 
-The `RegexFilterProcessor` applies zero-cost regex pattern matching to filter, redact, or block content in agent messages. No LLM calls are made — all detection is regex-based.
+The `RegexFilterProcessor` applies zero-cost regex pattern matching to filter, redact, or block content in agent messages. No LLM calls are made. All detection is regex-based.
 
 Supports built-in presets for common patterns (PII, secrets, URLs) and custom regex rules. Can be applied to input, output, or both phases.
 

package/.docs/reference/processors/response-cache.md

@@ -2,11 +2,11 @@
 
 # ResponseCache
 
-`ResponseCache` is an input processor that caches LLM responses on the request/response boundary inside the agentic loop. It hooks into `processLLMRequest` (cache lookup; short-circuits on hit) and `processLLMResponse` (cache write on completion).
+`ResponseCache` is an input processor that caches LLM responses on the request/response boundary inside the agentic loop. It hooks into `processLLMRequest` for cache lookup and short-circuits on a hit. It uses `processLLMResponse` to write the completed response.
 
-The cache key is derived from the resolved `LanguageModelV2Prompt` Mastra is about to send to the model — i.e. _after_ memory has loaded and earlier input processors have transformed the prompt — so two users with different memory contexts produce different cache keys. Each step in an agentic tool loop is independently cached.
+The cache key is derived from the resolved `LanguageModelV2Prompt` Mastra is about to send to the model (i.e. _after_ memory has loaded and earlier input processors have transformed the prompt) so two users with different memory contexts produce different cache keys. Each step in an agentic tool loop is independently cached.
 
-No agent-level option for response caching exists; register `ResponseCache` explicitly on `inputProcessors`. Per-call overrides flow through `RequestContext` via [`ResponseCache.context()`](#static-helpers) and [`ResponseCache.applyContext()`](#static-helpers).
+No agent-level option for response caching exists. Register `ResponseCache` explicitly on `inputProcessors`. Per-call overrides flow through `RequestContext` via [`ResponseCache.context()`](#static-helpers) and [`ResponseCache.applyContext()`](#static-helpers).
 
 ## Usage example
 
@@ -55,7 +55,7 @@ See [Response caching](https://mastra.ai/docs/agents/processors) for the concept
 
 ## Static helpers
 
-`ResponseCache` exposes two static helpers for setting per-call overrides on a `RequestContext`. The helpers keep the underlying context key a private implementation detail — prefer them over reading/writing the raw key.
+`ResponseCache` exposes two static helpers for setting per-call overrides on a `RequestContext`. The helpers keep the underlying context key a private implementation detail: prefer them over reading/writing the raw key.
 
 ### `ResponseCache.context(options)`
 
@@ -88,7 +88,7 @@ The shape passed to `ResponseCache.context()` / `ResponseCache.applyContext()`.
 
 **bust** (`boolean`): Skip the cache read but still write on completion.
 
-`cache`, `ttl`, and `agentId` are intentionally not overridable per call — they're instance-level concerns that shouldn't vary per request.
+`cache`, `ttl`, and `agentId` are intentionally not overridable per call: they're instance-level concerns that shouldn't vary per request.
 
 ## ResponseCacheKeyInputs
 
@@ -106,9 +106,9 @@ The argument passed to a `key` function (constructor or per-call). All fields co
 
 ## Helper exports
 
-- `buildResponseCacheKey(inputs)` — the deterministic hash used by default. Re-export it to override individual fields while preserving the rest of the standard key shape.
-- `DEFAULT_RESPONSE_CACHE_TTL_SECONDS` — the default `ttl` (`300`).
-- `RESPONSE_CACHE_CONTEXT_KEY` — the `RequestContext` key the static helpers write to. Exposed for advanced cases (e.g. clearing the override mid-pipeline); prefer the helpers.
+- `buildResponseCacheKey(inputs)`: The deterministic hash used by default. Re-export it to override individual fields while preserving the rest of the standard key shape.
+- `DEFAULT_RESPONSE_CACHE_TTL_SECONDS`: The default `ttl` (`300`).
+- `RESPONSE_CACHE_CONTEXT_KEY`: The `RequestContext` key the static helpers write to. Exposed for advanced cases (e.g. clearing the override mid-pipeline). Prefer the helpers.
 
 ## Related
 

package/.docs/reference/processors/semantic-recall-processor.md

@@ -85,7 +85,7 @@ export const agent = new Agent({
   id: 'semantic-memory-agent',
   name: 'semantic-memory-agent',
   instructions: 'You are a helpful assistant with semantic memory recall',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [semanticRecall, new MessageHistory({ storage, lastMessages: 50 })],
   outputProcessors: [semanticRecall, new MessageHistory({ storage })],
 })

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

@@ -77,7 +77,7 @@ const agent = new Agent({
   name: 'skill-agent',
   instructions:
     'You are a helpful assistant. Use search_skills to find relevant skills, then load_skill to load their instructions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   workspace,
   inputProcessors: [skillSearch],
 })

package/.docs/reference/processors/system-prompt-scrubber.md

@@ -2,7 +2,7 @@
 
 # SystemPromptScrubber
 
-The `SystemPromptScrubber` is an **output processor** that detects and handles system prompts, instructions, and other revealing information that could introduce security vulnerabilities. This processor helps maintain security by identifying various types of system prompts and providing flexible strategies for handling them, including multiple redaction methods to ensure sensitive information is properly sanitized.
+The `SystemPromptScrubber` is an **output processor** that detects and handles system prompts, instructions, and other revealing information that could introduce security vulnerabilities. This processor helps maintain security by identifying types of system prompts and providing flexible strategies for handling them, including multiple redaction methods to ensure sensitive information is properly sanitized.
 
 ## Usage example
 
@@ -60,7 +60,7 @@ export const agent = new Agent({
   id: 'scrubbed-agent',
   name: 'scrubbed-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   outputProcessors: [
     // Batch stream parts first to reduce LLM calls
     new BatchPartsProcessor({

package/.docs/reference/processors/token-limiter-processor.md

@@ -84,7 +84,7 @@ export const agent = new Agent({
   id: 'context-limited-agent',
   name: 'context-limited-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({/* ... */}),
   inputProcessors: [
     new TokenLimiterProcessor({ limit: 4000 }), // Limits historical messages to ~4000 tokens
@@ -94,7 +94,7 @@ export const agent = new Agent({
 
 ### As a per-step input processor (limit multi-step token growth)
 
-When an agent uses tools across multiple steps (e.g. `maxSteps > 1`), each step accumulates conversation history from all previous steps. Use `inputProcessors` to also limit tokens at each step of the agentic loop — the `TokenLimiterProcessor` automatically applies to both the initial input and every subsequent step:
+When an agent uses tools across multiple steps (e.g. `maxSteps > 1`), each step accumulates conversation history from all previous steps. Use `inputProcessors` to also limit tokens at each step of the agentic loop. The `TokenLimiterProcessor` automatically applies to both the initial input and every subsequent step:
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -104,7 +104,7 @@ export const agent = new Agent({
   id: 'multi-step-agent',
   name: 'multi-step-agent',
   instructions: 'You are a helpful research assistant with access to tools',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   inputProcessors: [
     new TokenLimiterProcessor({ limit: 8000 }), // Applied at every step
   ],
@@ -128,7 +128,7 @@ export const agent = new Agent({
   id: 'response-limited-agent',
   name: 'response-limited-agent',
   instructions: 'You are a helpful assistant',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   outputProcessors: [
     new TokenLimiterProcessor({
       limit: 1000,