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

package/.docs/docs/observability/integrations/exporters/sentry.md

@@ -2,7 +2,7 @@
 
 # Sentry exporter
 
-[Sentry](https://sentry.io/) is an application monitoring platform with AI-specific tracing capabilities. The Sentry exporter sends your traces to Sentry using OpenTelemetry semantic conventions, providing insights into model performance, token usage, and tool executions.
+[Sentry](https://sentry.io/) is an application monitoring platform with AI-specific tracing capabilities. The Sentry exporter sends your traces to Sentry using OpenTelemetry semantic conventions, providing insights into model performance and token usage, plus tool executions.
 
 ## Installation
 

package/.docs/docs/observability/integrations/overview.md

@@ -31,7 +31,7 @@ Exporters send observability data to a destination:
 Bridges connect Mastra to an existing distributed tracing context:
 
 - [OpenTelemetry bridge](https://mastra.ai/docs/observability/integrations/bridges/otel): Integrate Mastra with an existing OpenTelemetry trace.
-- [Datadog bridge](https://mastra.ai/docs/observability/integrations/bridges/datadog): Integrate Mastra with Datadog tracing and LLM Observability flows.
+- [Datadog bridge](https://mastra.ai/docs/observability/integrations/bridges/datadog): Send Mastra traces to Datadog and its LLM Observability product.
 
 ## Processors
 

package/.docs/docs/observability/integrations/processors/sensitive-data-filter.md

@@ -295,7 +295,7 @@ If the filter encounters an error while processing a field, it replaces the fiel
 }
 ```
 
-This ensures that processing errors don't prevent traces from being exported or cause application crashes.
+As a result, processing errors don't prevent traces from being exported or cause application crashes.
 
 ## Related
 

package/.docs/docs/observability/logging.md

@@ -89,7 +89,7 @@ Mastra provides access to a logger instance via the `mastra.getLogger()` method,
 
 ### Logging from workflow steps
 
-Within a workflow step, access the logger via the `mastra` parameter inside the `execute` function. This allows you to log messages relevant to the step's execution.
+Within a workflow step, access the logger via the `mastra` parameter inside the `execute` function. You can log messages relevant to the step's execution.
 
 ```typescript
 import { createWorkflow, createStep } from "@mastra/core/workflows";

package/.docs/docs/observability/metrics/overview.md

@@ -4,7 +4,7 @@
 
 Mastra automatically emits performance and usage metrics from traced execution. There's no manual instrumentation needed. Metrics are derived from spans as they complete.
 
-Three categories of metrics are emitted automatically:
+These categories of metrics are emitted automatically:
 
 - **Duration metrics**: Execution time for agents, workflows, tools, model calls, and processors.
 - **Token usage metrics**: Input and output token counts broken down by type (text, cache, audio, image, reasoning).

package/.docs/docs/observability/metrics/querying.md

@@ -91,7 +91,7 @@ By default the CLI targets hosted Mastra observability (`https://observability.m
 
 ### `getMetricAggregate`
 
-Returns a single scalar — the building block for KPI cards.
+Returns a single scalar, the building block for KPI cards.
 
 Inputs:
 
@@ -119,7 +119,7 @@ console.log(cost.value, cost.estimatedCost, cost.costUnit, cost.changePercent)
 
 ### `getMetricBreakdown`
 
-Groups rows by one or more dimensions and aggregates each group — the building block for top-N tables (e.g. "tokens by agent").
+Groups rows by one or more dimensions and aggregates each group, the building block for top-N tables (e.g. "tokens by agent").
 
 Inputs:
 
@@ -144,14 +144,14 @@ const byAgent = await observability!.getMetricBreakdown({
 
 ### `getMetricTimeSeries`
 
-Buckets values by a fixed interval — the building block for line and bar charts.
+Buckets values by a fixed interval, the building block for line and bar charts.
 
 Inputs:
 
 - `name`: Array of metric names.
 - `interval`: One of `'1m' | '5m' | '15m' | '1h' | '1d'`.
 - `aggregation`: Same enum.
-- `groupBy`: Optional. When omitted, multiple metric names are summed into one series; use one call per metric to keep them separate.
+- `groupBy`: Optional. When omitted, multiple metric names are summed into one series. Use one call per metric to keep them separate.
 - `filters`: Optional.
 
 Response: `series[]`, each with `name`, `costUnit`, and `points[]` of `{ timestamp, value, estimatedCost }`.
@@ -169,7 +169,7 @@ const inputTokens = await observability!.getMetricTimeSeries({
 
 ### `getMetricPercentiles`
 
-Returns percentile values bucketed by time — the building block for latency charts.
+Returns percentile values bucketed by time, the building block for latency charts.
 
 Inputs:
 
@@ -214,8 +214,8 @@ Use these endpoints to populate dropdowns or to give an agent the menu of values
 
 Every query accepts the same `filters` object. The most useful fields:
 
-- `name`: Restrict to specific metric names. (Top-level `name` already does this for aggregate/breakdown/timeseries; use `filters.name` when you want to mix multiple metrics under a single query.)
-- `timestamp`: `{ start, end, startExclusive, endExclusive }`. Both bounds are optional; omit `end` for "until now".
+- `name`: Restrict to specific metric names. (Top-level `name` already does this for aggregate/breakdown/timeseries. Use `filters.name` when you want to mix multiple metrics under a single query.)
+- `timestamp`: `{ start, end, startExclusive, endExclusive }`. Both bounds are optional. Omit `end` for "until now".
 - `provider`, `model`, `costUnit`: For token and cost metrics.
 - `labels`: Exact key-value match on metric labels, for example `{ status: 'error' }` for duration metrics.
 - Correlation fields: `entityType`, `entityName`, `parentEntityName`, `rootEntityName`, `userId`, `organizationId`, `resourceId`, `runId`, `sessionId`, `threadId`, `requestId`, `executionSource`, `environment`, `serviceName`, `experimentId`, `tags`.
@@ -247,7 +247,7 @@ curl -sS -X POST http://localhost:4111/api/observability/metrics/aggregate \
 
 ### Always provide a time range
 
-`filters.timestamp` is optional, but you should treat it as required for any query that runs against a production store. Observability tables are typically partitioned (or chunked, for TimescaleDB) by event time. When you supply `timestamp.start` (and ideally `end`), the backend can prune to the partitions that overlap the range — usually one or two. Without a time range, the planner has to scan every partition, which can be hundreds of segments over a year of retention and is the most common cause of slow OLAP queries on Postgres-backed stores.
+`filters.timestamp` is optional, but you should treat it as required for any query that runs against a production store. Observability tables are typically partitioned (or chunked, for TimescaleDB) by event time. When you supply `timestamp.start` (and ideally `end`), the backend can prune to the partitions that overlap the range, usually one or two. Without a time range, the planner has to scan every partition, which can be hundreds of segments over a year of retention and is the most common cause of slow OLAP queries on Postgres-backed stores.
 
 A safe default for ad-hoc queries is the last 24 hours; alerts and dashboards should match their actual evaluation window:
 

package/.docs/docs/observability/overview.md

@@ -8,7 +8,7 @@ Mastra's observability system gives you visibility into every agent run, workflo
 - [**Storage**](https://mastra.ai/docs/observability/storage): Choose storage backends for persisted traces, logs, metrics aggregation, and feedback queries.
 - [**Tracing**](https://mastra.ai/docs/observability/tracing/overview): Records every operation as a hierarchical timeline of spans, capturing inputs, outputs, token usage, and timing.
 - [**Logging**](https://mastra.ai/docs/observability/logging): Forwards structured log entries from your application and Mastra internals to observability storage, correlated to traces automatically.
-- [**Metrics**](https://mastra.ai/docs/observability/metrics/overview): Extracts duration, token usage, and cost data from traces automatically, with no additional instrumentation required.
+- [**Metrics**](https://mastra.ai/docs/observability/metrics/overview): Extracts trace usage and cost data. No additional instrumentation is required.
 - [**Feedback**](https://mastra.ai/docs/observability/feedback): Stores ratings, comments, corrections, and other review signals linked to traces and spans.
 - [**Integrations**](https://mastra.ai/docs/observability/integrations/overview): Choose exporters, bridges, and span processors for Studio, hosted, or external observability workflows.
 
@@ -26,11 +26,11 @@ Tracing is the foundation. When observability is configured, every agent run, wo
 
 Metrics are derived from traces automatically. When a span ends, Mastra extracts duration, token counts, and cost estimates without any extra code. These metrics power the dashboards in [Studio](https://mastra.ai/docs/studio/observability).
 
-Logs are correlated to traces automatically. Every `logger.info()`, `logger.warn()`, or `logger.error()` call within a traced context is tagged with the current trace and span IDs. You can navigate from a log entry directly to the trace that produced it.
+Logs are correlated to traces automatically. Every `logger.info()`, `logger.warn()`, or `logger.error()` call within a traced context is tagged with the current trace and span IDs. You can move through from a log entry directly to the trace that produced it.
 
 Feedback records human review signals such as ratings, comments, and corrections. Feedback can be linked to traces and spans, then queried with the same observability store used for metrics.
 
-These signals share correlation IDs (trace ID, span ID, entity type, entity name), so you can jump between a metric spike, the traces behind it, logs within those traces, and related feedback.
+These signals share correlation IDs such as trace ID, span ID, entity type, and entity name. You can use them to move from a metric spike to its traces, logs, and related feedback.
 
 ## Quickstart
 
@@ -102,7 +102,7 @@ export const mastra = new Mastra({
 })
 ```
 
-This enables tracing, log forwarding, and metrics. Mastra also supports external tracing providers like Langfuse, Datadog, and any OpenTelemetry-compatible platform. Use [Configuration](https://mastra.ai/docs/observability/config), [Storage](https://mastra.ai/docs/observability/storage), and [Integrations overview](https://mastra.ai/docs/observability/integrations/overview) to set up observability.
+It enables tracing, log forwarding, and metrics. Mastra also supports external tracing providers like Langfuse, Datadog, and any OpenTelemetry-compatible platform. Use [Configuration](https://mastra.ai/docs/observability/config), [Storage](https://mastra.ai/docs/observability/storage), and [Integrations overview](https://mastra.ai/docs/observability/integrations/overview) to set up observability.
 
 ## Mastra platform
 

package/.docs/docs/observability/tracing/overview.md

@@ -19,13 +19,17 @@ This page focuses on trace-specific concepts: span hierarchy, sampling, metadata
 
 To get started with tracing, configure observability in your Mastra instance and run an agent or workflow. You can configure behavior through the following features:
 
-- [Configuration](https://mastra.ai/docs/observability/config): Base observability config, multiple configs, and serverless flushing
+- [Configuration](https://mastra.ai/docs/observability/config): Base observability config and multiple configs, plus serverless flushing
 - [Storage](https://mastra.ai/docs/observability/storage): Storage routing for traces, logs, and metrics
 - [Integrations overview](https://mastra.ai/docs/observability/integrations/overview): Exporters, bridges, and processors
 
 ## Sampling strategies
 
-Sampling allows you to control which traces are collected, helping you balance between observability needs and resource costs. In production environments with high traffic, collecting every trace can be expensive and unnecessary. Sampling strategies let you capture a representative subset of traces while ensuring you don't miss critical information about errors or important operations.
+Sampling allows you to control which traces are collected, helping you balance between observability needs and resource costs.
+
+In production environments with high traffic, collecting every trace can be expensive and unnecessary.
+
+Sampling strategies let you capture a representative subset of traces while ensuring you don't miss critical information about errors or important operations.
 
 You can configure sampling at the observability config level:
 
@@ -93,7 +97,9 @@ The `sampling` option allows you to control which traces are collected, helping
 
 ## Adding custom metadata
 
-Custom metadata allows you to attach additional context to your traces, making it easier to debug issues and understand system behavior in production. Metadata can include business logic details, performance metrics, user context, or any information that helps you understand what happened during execution.
+Custom metadata allows you to attach additional context to your traces, making it easier to debug issues and understand system behavior in production.
+
+Metadata can include business logic and performance metrics. It can also carry user context or any other information that explains what happened during execution.
 
 You can add metadata to any span using the tracing context:
 
@@ -312,7 +318,7 @@ const result = await agent.generate([{ role: 'user', content: 'Handle confidenti
 
 #### How it works
 
-- **Trace-wide effect**: When set on the root span, these options apply to all child spans in the trace (tool calls, model generations, etc.)
+- **Trace-wide effect**: When set on the root span and these options apply to all child spans in the trace (tool calls, plus model generations, etc.)
 - **Export-time filtering**: The data remains available internally during execution but is excluded when spans are exported to observability platforms
 - **Combinable with other options**: You can use `hideInput`/`hideOutput` alongside `tags`, `metadata`, and other `tracingOptions`
 
@@ -327,7 +333,7 @@ const result = await agent.generate([{ role: 'user', content: 'Sensitive operati
 })
 ```
 
-For more granular control over sensitive data, consider using the [Sensitive Data Filter](https://mastra.ai/docs/observability/integrations/processors/sensitive-data-filter) processor, which can redact specific fields (like passwords, tokens, and keys) while preserving the rest of the input/output.
+For more fine-grained control over sensitive data, consider using the [Sensitive Data Filter](https://mastra.ai/docs/observability/integrations/processors/sensitive-data-filter) processor, which can redact specific fields (like passwords, tokens, and keys) while preserving the rest of the input/output.
 
 #### Child spans and metadata extraction
 
@@ -356,7 +362,7 @@ execute: async (inputData, context) => {
 }
 ```
 
-This gives you fine-grained control over which child spans include RequestContext metadata. Root spans (agent/workflow executions) always extract metadata automatically, while child spans only extract when you explicitly pass `requestContext`.
+You get fine-grained control over which child spans include RequestContext metadata. Root spans (agent/workflow executions) always extract metadata automatically, while child spans only extract when you explicitly pass `requestContext`.
 
 ## Creating child spans
 
@@ -699,11 +705,11 @@ serializationOptions: {
 }
 ```
 
-All options are optional — if not specified, they fall back to the defaults shown above.
+All options are optional, if not specified, they fall back to the defaults shown above.
 
 ## Retrieving trace IDs
 
-When you execute agents or workflows with tracing enabled, the response includes a `traceId` that you can use to look up the full trace in your observability platform. This is useful for debugging, customer support, or correlating traces with other events in your system.
+When you execute agents or workflows with tracing enabled, the response includes a `traceId` that you can use to look up the full trace in your observability platform. This is useful for debugging or customer support, or alternatively correlating traces with other events in your system.
 
 ### Agent trace IDs
 
@@ -783,7 +789,7 @@ const result = await agent.generate('Analyze this data', {
 
 ### OpenTelemetry integration
 
-Integration with OpenTelemetry allows Mastra traces to appear seamlessly in your existing observability platform:
+Integration with OpenTelemetry allows Mastra traces to appear directly in your existing observability platform:
 
 ```ts
 import { trace } from '@opentelemetry/api'
@@ -826,12 +832,12 @@ Mastra validates trace and span IDs to ensure compatibility:
 - **Trace IDs**: 1-32 hexadecimal characters (OpenTelemetry uses 32)
 - **Span IDs**: 1-16 hexadecimal characters (OpenTelemetry uses 16)
 
-Invalid IDs are handled gracefully — Mastra logs an error and continues:
+Invalid IDs are handled gracefully, Mastra logs an error and continues:
 
 - Invalid trace ID → generates a new trace ID
 - Invalid parent span ID → ignores the parent relationship
 
-This ensures tracing never crashes your application, even with malformed input.
+As a result, tracing never crashes your application, even with malformed input.
 
 ### Example: Express middleware
 
@@ -889,4 +895,4 @@ Mastra automatically creates spans for:
 - [Tracing Classes](https://mastra.ai/reference/observability/tracing/instances): Core classes and methods
 - [Span Interfaces](https://mastra.ai/reference/observability/tracing/spans): Span types and lifecycle
 - [Type Definitions](https://mastra.ai/reference/observability/tracing/interfaces): Complete interface reference
-- [Span filtering](https://mastra.ai/reference/observability/tracing/span-filtering): Filtering behavior, span types, and examples
+- [Span filtering](https://mastra.ai/reference/observability/tracing/span-filtering): Filtering behavior and span types, plus examples

package/.docs/docs/rag/chunking-and-embedding.md

@@ -2,7 +2,7 @@
 
 # Chunking and embedding documents
 
-Before processing, create a MDocument instance from your content. You can initialize it from various formats:
+Before processing, create a MDocument instance from your content. You can initialize it from different formats:
 
 ```ts
 const docFromText = MDocument.fromText('Your plain text content...')

package/.docs/docs/rag/graph-rag.md

@@ -49,7 +49,7 @@ const graphQueryTool = createGraphRAGTool({
 
 The `graphOptions` parameter controls how the knowledge graph is built and traversed:
 
-- `threshold`: Similarity threshold (0-1) for determining which chunks are related. Higher values create sparser graphs with stronger connections; lower values create denser graphs with more potential relationships.
+- `threshold`: Similarity threshold (0-1) for determining which chunks are related. Higher values create sparser graphs with stronger connections. Lower values create denser graphs with more potential relationships.
 - `dimension`: Vector embedding dimension. Must match the embedding model's output dimension (e.g., 1536 for OpenAI's text-embedding-3-small).
 
 ```ts
@@ -77,7 +77,7 @@ const ragAgent = new Agent({
   instructions: `You are a helpful assistant that answers questions based on the provided context.
 When answering questions, use the graph query tool to find relevant information and relationships.
 Base your answers on the context provided by the tool, and clearly state if the context doesn't contain enough information.`,
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: {
     graphQueryTool,
   },
@@ -138,15 +138,15 @@ The agent uses the graph query tool to:
 2. Find semantically similar chunks in the vector store
 3. Build a knowledge graph from related chunks
 4. Traverse the graph to find connected information
-5. Return comprehensive context for generating the response
+5. Return complete context for generating the response
 
 ## Choosing the right threshold
 
-The threshold parameter significantly impacts retrieval quality:
+The threshold parameter substantially impacts retrieval quality:
 
-- **High threshold (0.8-0.9)**: Strict connections, fewer relationships, more precise but potentially incomplete results
+- **High threshold (0.8-0.9)**: Strict connections and fewer relationships, plus more precise but potentially incomplete results
 - **Medium threshold (0.6-0.8)**: Balanced approach, good for most use cases
-- **Low threshold (0.4-0.6)**: More connections, broader context, risk of including less relevant information
+- **Low threshold (0.4-0.6)**: More connections and broader context, plus risk of including less relevant information
 
 Start with 0.7 and adjust based on your specific use case:
 
@@ -199,7 +199,7 @@ const agent = new Agent({
   name: 'RAG Agent',
   instructions: `Use vector search for simple fact-finding queries.
 Use graph search when you need to understand relationships or find connected information.`,
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   tools: {
     vectorQueryTool,
     graphQueryTool,

package/.docs/docs/rag/overview.md

@@ -59,11 +59,11 @@ const results = await pgVector.query({
 console.log('Similar chunks:', results)
 ```
 
-This example shows the essentials: initialize a document, create chunks, generate embeddings, store them, and query for similar content.
+This example shows the essentials. Initialize a document and create chunks, then generate and store embeddings before querying for similar content.
 
 ## Document processing
 
-The basic building block of RAG is document processing. Documents can be chunked using various strategies (recursive, sliding window, etc.) and enriched with metadata. See the [chunking and embedding doc](https://mastra.ai/docs/rag/chunking-and-embedding).
+The basic building block of RAG is document processing. Documents can be chunked using strategies (recursive, sliding window, etc.) and enriched with metadata. See the [chunking and embedding doc](https://mastra.ai/docs/rag/chunking-and-embedding).
 
 ## Vector storage
 

package/.docs/docs/rag/retrieval.md

@@ -160,15 +160,15 @@ When creating the tool, pay special attention to the tool's name and description
 
 This is particularly useful when:
 
-- Your agent needs to dynamically decide what information to retrieve
+- Your agent needs to decide at runtime what information to retrieve
 - The retrieval process requires complex decision-making
 - You want the agent to combine multiple retrieval strategies based on context
 
 #### Database-Specific Configurations
 
-The Vector Query Tool supports database-specific configurations that enable you to leverage unique features and optimizations of different vector stores.
+The Vector Query Tool supports database-specific configurations that enable you to use unique features and optimizations of different vector stores.
 
-> **Note:** These configurations are for **query-time options** like namespaces, performance tuning, and filtering—not for database connection setup.
+> **Note:** These configurations are for **query-time options** like namespaces, performance tuning, and filtering, not for database connection setup.
 >
 > Connection credentials (URLs, auth tokens) are configured when you instantiate the vector store class (e.g., `new LibSQLVector({ url: '...' })`).
 
@@ -235,7 +235,7 @@ const lanceQueryTool = createVectorQueryTool({
 - **pgVector optimization**: Control search accuracy and speed with ef/probes parameters
 - **Quality filtering**: Set minimum similarity thresholds to improve result relevance
 - **LanceDB tables**: Separate data into tables for better organization and performance
-- **Runtime flexibility**: Override configurations dynamically based on context
+- **Runtime flexibility**: Override configurations at runtime based on context
 
 **Common Use Cases:**
 
@@ -274,7 +274,7 @@ import { PGVECTOR_PROMPT } from '@mastra/pg'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${PGVECTOR_PROMPT}
@@ -291,7 +291,7 @@ import { PINECONE_PROMPT } from '@mastra/pinecone'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${PINECONE_PROMPT}
@@ -308,7 +308,7 @@ import { QDRANT_PROMPT } from '@mastra/qdrant'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${QDRANT_PROMPT}
@@ -325,7 +325,7 @@ import { CHROMA_PROMPT } from '@mastra/chroma'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${CHROMA_PROMPT}
@@ -342,7 +342,7 @@ import { ASTRA_PROMPT } from '@mastra/astra'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${ASTRA_PROMPT}
@@ -359,7 +359,7 @@ import { LIBSQL_PROMPT } from '@mastra/libsql'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${LIBSQL_PROMPT}
@@ -376,7 +376,7 @@ import { UPSTASH_PROMPT } from '@mastra/upstash'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${UPSTASH_PROMPT}
@@ -393,7 +393,7 @@ import { VECTORIZE_PROMPT } from '@mastra/vectorize'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${VECTORIZE_PROMPT}
@@ -410,7 +410,7 @@ import { MONGODB_PROMPT } from '@mastra/mongodb'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${MONGODB_PROMPT}
@@ -427,7 +427,7 @@ import { OPENSEARCH_PROMPT } from '@mastra/opensearch'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${OPENSEARCH_PROMPT}
@@ -444,7 +444,7 @@ import { S3VECTORS_PROMPT } from '@mastra/s3vectors'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${S3VECTORS_PROMPT}
@@ -455,10 +455,10 @@ export const ragAgent = new Agent({
 
 ### Re-ranking
 
-Initial vector similarity search can sometimes miss nuanced relevance. Re-ranking is a more computationally expensive process, but more accurate algorithm that improves results by:
+Initial vector similarity search can sometimes miss detailed relevance. Re-ranking is a more computationally expensive process, but more accurate algorithm that improves results by:
 
 - Considering word order and exact matches
-- Applying more sophisticated relevance scoring
+- Applying more advanced relevance scoring
 - Using a method called cross-attention between query and documents
 
 Here's how to use re-ranking:
@@ -476,7 +476,7 @@ const initialResults = await pgVector.query({
 // Create a relevance scorer
 const relevanceProvider = new MastraAgentRelevanceScorer(
   'relevance-scorer',
-  'openai/gpt-5.5',
+  'openai/gpt-5.6-sol',
 )
 
 // Re-rank the results

package/.docs/docs/rag/vector-databases.md

@@ -2,7 +2,7 @@
 
 # Storing embeddings in a vector database
 
-After generating embeddings, you need to store them in a database that supports vector similarity search. Mastra provides a consistent interface for storing and querying embeddings across various vector databases.
+After generating embeddings, you need to store them in a database that supports vector similarity search. Mastra provides a consistent interface for storing and querying embeddings across vector databases.
 
 ## Supported databases
 
@@ -571,7 +571,7 @@ The upsert operation:
 
 Vector stores support rich metadata (any JSON-serializable fields) for filtering and organization. Since metadata is stored with no fixed schema, use consistent field naming to avoid unexpected query results.
 
-> **Warning:** Metadata is crucial for vector storage - without it, you'd only have numerical embeddings with no way to return the original text or filter results. Always store at least the source text as metadata.
+> **Warning:** Metadata is important for vector storage. Without it, you'd only have numerical embeddings with no way to return the original text or filter results. Always store at least the source text as metadata.
 
 ```ts
 // Store embeddings with rich metadata for better organization and filtering

package/.docs/docs/server/auth/composite-auth.md

@@ -13,7 +13,7 @@ The `CompositeAuth` class allows you to combine multiple authentication provider
 
 ## Installation
 
-CompositeAuth is included in `@mastra/core`, no additional packages required.
+CompositeAuth is included in `@mastra/core` and requires no additional packages.
 
 ```typescript
 import { CompositeAuth } from '@mastra/core/server'
@@ -83,7 +83,7 @@ async authenticateToken(token, request) {
 
 ## Provider order
 
-The order of providers matters. Place the most common authentication method first for better performance:
+Place the most common authentication method first because provider order affects performance:
 
 ```typescript
 // If most requests use Clerk, put it first

package/.docs/docs/server/auth/fga.md

@@ -74,10 +74,10 @@ resourceMapping: {
 
 `deriveId()` receives:
 
-- `user` — the authenticated user
-- `resourceId` — the owning Mastra resource ID when available (for example, a thread's `resourceId`)
-- `requestContext` — the current request context for advanced tenant resolution
-- `metadata` — provider-specific metadata for the attempted action
+- `user`: the authenticated user
+- `resourceId`: the owning Mastra resource ID when available (for example, a thread's `resourceId`)
+- `requestContext`: the current request context for advanced tenant resolution
+- `metadata`: provider-specific metadata for the attempted action
 
 Return `undefined` from `deriveId()` to fall back to the original Mastra resource ID.
 
@@ -263,7 +263,7 @@ Autonomous and scheduled agents run without an end user. Mark these calls with a
 - `true` or `{ actorKind: 'system' }` identifies an anonymous system actor.
 - The object form can also carry `agentId`, `permissions`, and `scope` to identify and constrain the acting agent.
 
-By default, a trusted actor skips the user-centric `require()` check after a tenant-scope check. To enforce per-agent least privilege, implement the optional `requireActor` method on your provider. It receives the actor and the same `FGACheckParams` as `require`, and throws `FGADeniedError` to deny. When your provider doesn't implement `requireActor`, the trusted-actor bypass is preserved, so adding it is backward compatible.
+By default, a trusted actor skips the user-centric `require()` check after a tenant-scope check. To enforce per-agent least privilege, implement the optional `requireActor` method on your provider. It receives the actor and the same `FGACheckParams` as `require`, and throws `FGADeniedError` to deny. When your provider doesn't implement `requireActor`, the trusted-actor bypass is preserved, so adding it's backward compatible.
 
 ```typescript
 import { FGADeniedError } from '@mastra/core/auth/ee'
@@ -293,7 +293,7 @@ The actor signal is trusted input, so construct it server-side:
 - Establish tenant scope server-side. Built-in agent HTTP routes ignore a client-supplied `organizationId` in the request context, and the trusted-actor path requires an `organizationId` to be set.
 - Durable resume keeps its existing request-context recovery and merge behavior. This doesn't make a persisted actor trusted for a later workflow segment.
 - The tenant-scope check confirms that a trusted `organizationId` exists. It doesn't verify that `actor.agentId` belongs to that organization. When that relationship matters, verify it in `requireActor` using authoritative provider data.
-- Treat `actor.permissions` as a claim, not a grant. A provider that enforces least privilege resolves the agent's authoritative permissions from a trusted source, for example a manifest or your FGA backend keyed by `agentId`, rather than trusting the inline values.
+- Treat `actor.permissions` as an unverified claim. Resolve authoritative grants from a trusted source. A provider that enforces least privilege resolves the agent's authoritative permissions from a trusted source, for example a manifest or your FGA backend keyed by `agentId`, rather than trusting the inline values.
 - Once a provider implements `requireActor`, errors from that method stop execution. Mastra doesn't fall back to organization-only authorization.
 
 ## Related

package/.docs/docs/server/auth/firebase.md

@@ -93,11 +93,11 @@ The `MastraAuthFirebase` class can be configured through constructor options or
 - `FIREBASE_SERVICE_ACCOUNT`: Path to Firebase service account JSON file
 - `FIRESTORE_DATABASE_ID` or `FIREBASE_DATABASE_ID`: Firestore database ID
 
-> **Note:** When constructor options aren't provided, the class automatically reads these environment variables. This means you can call `new MastraAuthFirebase()` without any arguments if your environment variables are properly configured.
+> **Note:** When constructor options aren't provided, the class automatically reads these environment variables. As a result, you can call `new MastraAuthFirebase()` without any arguments if your environment variables are properly configured.
 
 ### User Authorization
 
-By default, `MastraAuthFirebase` uses Firestore to manage user access. It expects a collection named `user_access` with documents keyed by user UIDs. The presence of a document in this collection determines whether a user is authorized.
+By default, `MastraAuthFirebase` uses Firestore to manage user access. It expects a `user_access` collection with documents keyed by user UIDs. The presence of a document in this collection determines whether a user is authorized.
 
 ```text
 user_access/

package/.docs/docs/server/auth/simple-auth.md

@@ -13,7 +13,7 @@ The `SimpleAuth` class provides token-based authentication using a basic token-t
 
 ## Installation
 
-`SimpleAuth` is included in `@mastra/core`, no additional packages required.
+`SimpleAuth` is included in `@mastra/core` and requires no additional packages.
 
 ```typescript
 import { SimpleAuth } from '@mastra/core/server'