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

package/.docs/reference/tools/submit-plan-tool.md

@@ -4,7 +4,7 @@
 
 A built-in, agent-agnostic tool that submits an implementation plan for user review. The agent writes a plan to a markdown file and passes the file path to this tool. The tool suspends the run until the user approves or rejects the plan.
 
-The tool pauses through the native [tool suspension](https://mastra.ai/docs/agents/agent-approval) primitive: it calls `suspend({ path })`, which makes the agent emit a `tool-call-suspended` event. The host reads the plan file, presents it to the user, and resumes with an approval or rejection.
+The tool pauses through the native [tool suspension](https://mastra.ai/docs/agents/agent-approval) primitive: it calls `suspend({ path })`, which makes the agent emit a `tool-call-suspended` event. The host reads the plan file and presents it to the user. It then resumes with an approval or rejection.
 
 When executed outside an agent run (no `suspend` available), the tool returns a readable fallback string containing the file path.
 

package/.docs/reference/tools/tavily.md

@@ -2,7 +2,7 @@
 
 # Tavily tools
 
-The `@mastra/tavily` package wraps the [Tavily](https://app.tavily.com) API as Mastra-compatible tools. It exposes factory functions for search, extract, crawl, and map — each returning a tool created with [`createTool()`](https://mastra.ai/reference/tools/create-tool) that includes full Zod input/output schemas.
+The `@mastra/tavily` package wraps the [Tavily](https://app.tavily.com) API as Mastra-compatible tools. It exposes factory functions for search, extract, crawl, and map. Each function returns a tool created with [`createTool()`](https://mastra.ai/reference/tools/create-tool) that includes full Zod input/output schemas.
 
 ## Installation
 

package/.docs/reference/tools/vector-query-tool.md

@@ -2,7 +2,7 @@
 
 # createVectorQueryTool()
 
-The `createVectorQueryTool()` function creates a tool for semantic search over vector stores. It supports filtering, reranking, database-specific configurations, and integrates with various vector store backends.
+The `createVectorQueryTool()` function creates a tool for semantic search over vector stores. It supports filtering, reranking, database-specific configurations, and integrates with vector store backends.
 
 ## Basic usage
 
@@ -69,7 +69,7 @@ const queryTool = createVectorQueryTool({
 
 **databaseConfig.chroma.whereDocument** (`Record<string, any>`): Document content filtering conditions
 
-**providerOptions** (`Record<string, Record<string, any>>`): Provider-specific options for the embedding model (e.g., outputDimensionality). \*\*Important\*\*: Only works with AI SDK EmbeddingModelV2 models. For V1 models, configure options when creating the model itself.
+**providerOptions** (`Record<string, Record<string, any>>`): Provider-specific options for the embedding model (e.g., outputDimensionality). Only works with AI SDK EmbeddingModelV2 models. For V1 models, configure options when creating the model itself.
 
 **vectorStore** (`MastraVector | VectorStoreResolver`): Direct vector store instance or a resolver function for dynamic selection. Use a function for multi-tenant applications where the vector store is selected based on request context. When provided, vectorStoreName becomes optional.
 
@@ -182,7 +182,7 @@ This example shows how to customize the tool description for a specific use case
 
 ## Database-specific configuration examples
 
-The `databaseConfig` parameter allows you to leverage unique features and optimizations specific to each vector database. These configurations are automatically applied during query execution.
+The `databaseConfig` parameter allows you to use features and optimizations specific to each vector database. These configurations are automatically applied during query execution.
 
 **Pinecone**:
 
@@ -475,7 +475,7 @@ const result = await vectorQueryTool.execute(
 )
 ```
 
-This pattern is similar to how `Agent.memory` supports dynamic configuration and enables:
+This pattern is similar to how `Agent.memory` supports runtime-defined configuration and enables:
 
 - **Schema isolation**: Each tenant's data in separate PostgreSQL schemas
 - **Database isolation**: Route to different database instances per tenant

package/.docs/reference/vectors/astra.md

@@ -2,7 +2,7 @@
 
 # Astra vector store
 
-The AstraVector class provides vector search using [DataStax Astra DB](https://www.datastax.com/products/datastax-astra), a cloud-native, serverless database built on Apache Cassandra. It provides vector search capabilities with enterprise-grade scalability and high availability.
+The AstraVector class provides vector search using [DataStax Astra DB](https://www.datastax.com/products/datastax-astra), a cloud-native, serverless database built on Apache Cassandra. It provides vector search capabilities with enterprise-grade capacity and high availability.
 
 ## Constructor options
 

package/.docs/reference/vectors/chroma.md

@@ -8,7 +8,7 @@ The ChromaVector class provides vector search using [Chroma](https://docs.trychr
 >
 > **Chroma Cloud**
 >
-> Chroma Cloud powers serverless vector and full-text search. It's extremely fast, cost-effective, scalable and painless. Create a DB and try it out in under 30 seconds with $5 of free credits.
+> Chroma Cloud powers serverless vector and full-text search. It's extremely fast, cost-effective, high-capacity, and painless. Create a DB and try it out in under 30 seconds with $5 of free credits.
 >
 > [Get started with Chroma Cloud](https://trychroma.com/signup)
 
@@ -197,7 +197,7 @@ await vectorStore.updateVector({
 
 ### `deleteVectors()`
 
-Delete multiple vectors by IDs or by metadata filter. This method enables bulk deletion and source-based vector management. Either `ids` or `filter` must be provided, but not both.
+Delete multiple vectors by IDs or by metadata filter. The method supports bulk deletion and source-based vector management. Either `ids` or `filter` must be provided, but not both.
 
 **indexName** (`string`): Name of the index containing the vectors to delete
 

package/.docs/reference/vectors/convex.md

@@ -351,7 +351,7 @@ interface QueryResult {
 
 ## Metadata filtering
 
-`ConvexVector` supports metadata filtering with various operators. These filters are applied by the adapter after vectors are loaded from Convex.
+`ConvexVector` supports metadata filtering with operators. These filters are applied by the adapter after vectors are loaded from Convex.
 
 ```typescript
 // Simple equality
@@ -415,7 +415,7 @@ Vector similarity search is performed with cosine similarity in the Mastra adapt
 - Filters must target fields listed in the Convex vector index `filterFields`.
 - Use one dedicated table per Mastra vector index to avoid cross-index results.
 
-Use an external vector database when you need dynamic index creation at runtime, metadata-only queries, complex filter operators, filter-based bulk updates or deletes, or result limits above Convex's native vector search cap.
+Use an external vector database when you need runtime-defined index creation at runtime, metadata-only queries, complex filter operators, filter-based bulk updates or deletes, or result limits above Convex's native vector search cap.
 
 ## Related
 

package/.docs/reference/vectors/couchbase.md

@@ -75,7 +75,7 @@ const store = new CouchbaseVector({
 
 Creates a new vector index in Couchbase.
 
-> **Note:** Index creation is asynchronous. After calling `createIndex`, allow time (typically 1–5 seconds for small datasets, longer for large ones) before querying. For production, implement polling to check index status rather than using fixed delays.
+> **Note:** Index creation is asynchronous. After calling `createIndex`, allow time (typically 1 to 5 seconds for small datasets, longer for large ones) before querying. For production, implement polling to check index status rather than using fixed delays.
 
 **indexName** (`string`): Name of the index to create
 
@@ -145,7 +145,7 @@ Returns: `Promise<string[]>`
 
 ### `updateVector()`
 
-Updates a specific vector entry by its ID with new vector data and/or metadata. **Note:** Filter-based updates aren't yet implemented for Couchbase.
+Updates a specific vector entry by its ID with new vector data and/or metadata. Filter-based updates aren't yet implemented for Couchbase.
 
 **indexName** (`string`): Name of the index containing the vector
 
@@ -163,7 +163,7 @@ Deletes a single vector by its ID from the index.
 
 ### `deleteVectors()`
 
-Deletes multiple vectors by their IDs. **Note:** Filter-based deletion isn't yet implemented for Couchbase.
+Deletes multiple vectors by their IDs. Filter-based deletion isn't yet implemented for Couchbase.
 
 **indexName** (`string`): Name of the index containing the vectors to delete
 
@@ -221,7 +221,7 @@ try {
 
 - Index creation delays may impact immediate querying after creation.
 - No hard enforcement of vector dimension at ingest time (dimension mismatches will error at query time).
-- Vector insertion and index updates are eventually consistent; strong consistency isn't guaranteed immediately after writes.
+- Vector insertion and index updates are eventually consistent. Strong consistency isn't guaranteed immediately after writes.
 
 ## Related
 

package/.docs/reference/vectors/libsql.md

@@ -85,7 +85,7 @@ const results = await store.query({
 
 ### `createIndex()`
 
-Creates a new vector collection. The index name must start with a letter or underscore and can only contain letters, numbers, and underscores. The dimension must be a positive integer.
+Creates a new vector collection. The index name must start with a letter or underscore and can only contain letters, numbers, and underscore characters. The dimension must be a positive integer.
 
 **indexName** (`string`): Name of the index to create
 

package/.docs/reference/vectors/mongodb.md

@@ -559,7 +559,7 @@ export const mongodbVoyageAgent = new Agent({
 })
 ```
 
-For comprehensive VoyageAI embedding examples including specialized models, multimodal embeddings, and retrieval optimization, see the [VoyageAI embeddings documentation](https://mastra.ai/models/embeddings).
+For detailed VoyageAI embedding examples including specialized models, multimodal embeddings, and retrieval optimization, see the [VoyageAI embeddings documentation](https://mastra.ai/models/embeddings).
 
 ## Related
 

package/.docs/reference/vectors/pg.md

@@ -2,7 +2,7 @@
 
 # PG vector store
 
-The PgVector class provides vector search using [PostgreSQL](https://www.postgresql.org/) with [pgvector](https://github.com/pgvector/pgvector) extension. It provides robust vector similarity search capabilities within your existing PostgreSQL database.
+The PgVector class provides vector search using [PostgreSQL](https://www.postgresql.org/) with [pgvector](https://github.com/pgvector/pgvector) extension. It provides reliable vector similarity search capabilities within your existing PostgreSQL database.
 
 ## Constructor options
 
@@ -110,13 +110,13 @@ const vectorStore = new PgVector({
 
 #### Memory Requirements
 
-HNSW indexes require significant shared memory during construction. For 100K vectors:
+HNSW indexes require substantial shared memory during construction. For 100K vectors:
 
 - Small dimensions (64d): \~60MB with default settings
 - Medium dimensions (256d): \~180MB with default settings
 - Large dimensions (384d+): \~250MB+ with default settings
 
-Higher M values or efConstruction values will increase memory requirements significantly. Adjust your system's shared memory limits if needed.
+Higher M values or efConstruction values will increase memory requirements substantially. Adjust your system's shared memory limits if needed.
 
 ### `upsert()`
 
@@ -340,7 +340,7 @@ The system automatically detects configuration changes and only rebuilds indexes
 - Regularly evaluate your index configuration to ensure optimal performance.
 - Adjust parameters like `lists` and `m` based on dataset size and query requirements.
 - **Monitor index performance** using `describeIndex()` to track usage
-- Rebuild indexes periodically to maintain efficiency, especially after significant data changes
+- Rebuild indexes periodically to maintain efficiency, especially after substantial data changes
 
 ## Direct pool access
 

package/.docs/reference/vectors/qdrant.md

@@ -86,7 +86,7 @@ await store.upsert({
 
 #### Named Vectors
 
-Qdrant supports [named vectors](https://qdrant.tech/documentation/concepts/vectors/#named-vectors), allowing multiple vector fields per collection. Use the `using` parameter to specify which named vector to query against:
+Qdrant supports [multiple vectors per collection](https://qdrant.tech/documentation/concepts/vectors/#named-vectors), with a name assigned to each vector field. Use the `using` parameter to select the vector field to query:
 
 ```typescript
 const results = await store.query({
@@ -131,7 +131,7 @@ Update a single vector by ID or by metadata filter. Either `id` or `filter` must
 
 **update** (`{ vector?: number[]; metadata?: Record<string, any>; }`): Object containing the vector and/or metadata to update
 
-Updates a vector and/or its metadata in the specified index. If both vector and metadata are provided, both will be updated. If only one is provided, only that will be updated.
+Updates a vector and/or its metadata in the specified index. If both vector and metadata are provided, both will be updated. Providing either value updates that value alone.
 
 ### `deleteVector()`
 

package/.docs/reference/vectors/s3vectors.md

@@ -205,8 +205,8 @@ S3 Vectors supports a strict subset of operators and value types. The Mastra fil
 
 - **Canonicalizes implicit AND**: `{a:1,b:2}` → `{ $and: [{a:1},{b:2}] }`.
 - **Normalizes Date values** to epoch ms for numeric comparisons and array elements.
-- **Disallows Date** in equality positions (`field: value` or `$eq/$ne`); equality values must be **string | number | boolean**.
-- **Rejects** null/undefined for equality; **array equality** isn't supported (use `$in`/`$nin`).
+- **Disallows Date** in equality positions (`field: value` or `$eq/$ne`). Equality values must be **string | number | boolean**.
+- **Rejects** null/undefined for equality. **array equality** isn't supported (use `$in`/`$nin`).
 - Only **`$and` / `$or`** are allowed as top-level logical operators.
 - Logical operators must contain **field conditions** (not direct operators).
 
@@ -268,10 +268,10 @@ Typical environment variables when wiring your app:
 
 ## Best practices
 
-- Choose the metric (`cosine` or `euclidean`) to match your embedding model; `dotproduct` isn't supported.
+- Choose the metric (`cosine` or `euclidean`) to match your embedding model. `dotproduct` isn't supported.
 - Keep **filterable** metadata small and structured (string/number/boolean). Store large text (e.g., `content`) as **non-filterable**.
 - Use **dotted paths** for nested metadata and explicit `$and`/`$or` for complex logic.
-- Avoid calling `describeIndex()` on hot paths—`count` is computed with paginated `ListVectors` (**O(n)**).
+- Avoid calling `describeIndex()` on hot paths. `count` is computed with paginated `ListVectors` (**O(n)**).
 - Use `includeVector: true` only when you need raw vectors.
 
 ## Related

package/.docs/reference/vectors/turbopuffer.md

@@ -20,7 +20,7 @@ The TurbopufferVector class provides vector search using [Turbopuffer](https://t
 
 **consistency** (`'strong' | 'eventual'`): The default consistency level for queries. Can be overridden per query. "strong" guarantees queries see all data written before the query started, at the cost of higher latency. "eventual" offers lower latency, but recently written data may not be visible yet. (Default: `strong`)
 
-**schemaConfigForIndex** (`function`): A callback function that takes an index name and returns a config object for that index. This allows you to define explicit schemas per index.
+**schemaConfigForIndex** (`function`): A callback function that takes an index name and returns a config object for that index. You can define explicit schemas per index.
 
 ## Methods
 

package/.docs/reference/voice/aws-nova-sonic.md

@@ -218,7 +218,7 @@ Registers and removes event listeners. See [Voice events](https://mastra.ai/refe
 
 ## Available voices
 
-Nova 2 Sonic ships voices in ten locales. Tiffany and Matthew are polyglot and can speak any supported language.
+Nova 2 Sonic provides voices in ten locales. Tiffany and Matthew are polyglot and can speak any supported language.
 
 | Voice ID   | Name     | Language   | Locale | Gender    | Polyglot |
 | ---------- | -------- | ---------- | ------ | --------- | -------- |

package/.docs/reference/voice/azure.md

@@ -83,7 +83,7 @@ Transcribes audio using Azure's speech-to-text service.
 
 Returns: `Promise<string>` - The recognized text from the audio
 
-**Note:** Language and recognition settings are configured in the `listeningModel` configuration during initialization, not passed as options to this method.
+Language and recognition settings are configured in the `listeningModel` configuration during initialization, not passed as options to this method.
 
 ### `getSpeakers()`
 

package/.docs/reference/voice/google-gemini-live.md

@@ -190,7 +190,7 @@ Returns: `Promise<void>`
 
 ### `updateSessionConfig()`
 
-Updates the session configuration dynamically. This can be used to modify voice settings, speaker selection, and other runtime configurations.
+Updates the session configuration at runtime. This can modify voice settings and speaker selection. It can also modify other runtime configurations.
 
 **config** (`Partial<GeminiLiveVoiceConfig>`): Configuration updates to apply.
 
@@ -284,14 +284,14 @@ The GeminiLiveVoice class emits the following events:
 
 ## Native-audio behavior
 
-Native-audio Gemini Live models — any model whose ID contains `native-audio`, such as `gemini-2.5-flash-native-audio-preview-12-2025` — split text output across two channels:
+Native-audio Gemini Live models (any model whose ID contains `native-audio`, such as `gemini-2.5-flash-native-audio-preview-12-2025`) split text output across two channels:
 
 - The model's spoken reply is delivered as audio plus an `output_audio_transcription` transcript and surfaced as `writing` with `role: 'assistant'`.
 - The model's internal reasoning is delivered as `modelTurn.parts.text` and surfaced as `thinking`.
 
-On non-native-audio models there is no `output_audio_transcription` channel, so `modelTurn.parts.text` is the spoken response itself and is emitted as `writing`; the `thinking` event doesn't fire.
+On non-native-audio models there is no `output_audio_transcription` channel, so `modelTurn.parts.text` is the spoken response itself and is emitted as `writing`. The `thinking` event doesn't fire.
 
-Input transcription, output transcription, and barge-in detection (`realtime_input_config.activity_handling = 'START_OF_ACTIVITY_INTERRUPTS'`) are enabled automatically in the setup payload — no extra configuration is required.
+Input transcription, output transcription, and barge-in detection (`realtime_input_config.activity_handling = 'START_OF_ACTIVITY_INTERRUPTS'`) are enabled automatically in the setup payload. You don't need extra configuration.
 
 ## Available models
 

package/.docs/reference/voice/inworld-realtime.md

@@ -56,7 +56,7 @@ await voice.send(microphoneStream)
 voice.close()
 ```
 
-> Inworld API keys ship pre-Basic-encoded. Paste them verbatim into `INWORLD_API_KEY`; the package doesn't re-encode them.
+> Inworld API keys are pre-Basic-encoded. Paste them verbatim into `INWORLD_API_KEY`. The package doesn't re-encode them.
 
 ## Constructor parameters
 
@@ -118,7 +118,7 @@ Use the typed `session` field for documented Inworld realtime options. Fields co
 
 ### `providerData` (Inworld extensions)
 
-`providerData` is a typed object for Inworld-specific realtime extensions. It's sent under `session.providerData` on every `session.update`, and composes with any `session.providerData` you set via the `session` field — the constructor `providerData` wins on key collisions.
+`providerData` is a typed object for Inworld-specific realtime extensions. It's sent under `session.providerData` on every `session.update`, and composes with any `session.providerData` you set via the `session` field: the constructor `providerData` wins on key collisions.
 
 It has five branches plus two session-level fields:
 
@@ -147,7 +147,7 @@ const voice = new InworldRealtimeVoice({
 
 Opens the WebSocket connection, sends the initial `session.update`, and resolves once the server acknowledges with `session.updated`. Must be called before `speak()`, `listen()`, or `send()`.
 
-A pre-open `error` or `close` on the WebSocket — or a handshake that exceeds `connectTimeoutMs` (15s default) — surfaces as a rejected promise instead of an uncaught socket error. On reject, the half-open socket is closed.
+A pre-open `error` or `close` on the WebSocket (or a handshake that exceeds `connectTimeoutMs` (15s default)) surfaces as a rejected promise instead of an uncaught socket error. On reject, the half-open socket is closed.
 
 ```typescript
 await voice.connect()
@@ -243,7 +243,7 @@ Returns: `void`
 
 #### `clearOutput()`
 
-Clears the server's entire output audio buffer, stopping playback. This also stops any in-flight back-channel audio. The default barge-in path (`response.cancel` on `interrupted`) is back-channel-safe; prefer it. Use `clearOutput()` only when you want to flush everything.
+Clears the server's entire output audio buffer, stopping playback. This also stops any in-flight back-channel audio. The default barge-in path (`response.cancel` on `interrupted`) is back-channel-safe. Prefer it. Use `clearOutput()` only when you want to flush everything.
 
 ```typescript
 voice.clearOutput()
@@ -327,7 +327,7 @@ The `InworldRealtimeVoice` class emits the following events:
 
 ## Voices
 
-The package ships with a curated set of voice IDs returned from `getSpeakers()`:
+The package includes a curated set of voice IDs returned from `getSpeakers()`:
 
 - `Dennis`
 - `Hades`
@@ -344,7 +344,7 @@ Any voice ID from [Inworld's voice catalog](https://docs.inworld.ai/quickstart-t
 
 ## Notes
 
-- API keys can be provided via constructor options or the `INWORLD_API_KEY` environment variable. Keys are pre-Basic-encoded; don't re-encode them.
+- API keys can be provided via constructor options or the `INWORLD_API_KEY` environment variable. Keys are pre-Basic-encoded. Don't re-encode them.
 - The WebSocket URL appends `?key=<sessionId>&protocol=realtime`. The model is configured via the initial `session.update`, not the URL.
 - Per-call `speak(input, { speaker })` scopes the voice override to a single response (via the flat `response.voice` field) and doesn't mutate the session.
 - Audio output defaults to PCM16 at 24 kHz. Telephony `audio/pcmu` and `audio/pcma` at 8 kHz, and `audio/float32`, are also supported via `session.audio.output.format`.
@@ -352,4 +352,4 @@ Any voice ID from [Inworld's voice catalog](https://docs.inworld.ai/quickstart-t
 - The voice instance must be closed with `close()` or `disconnect()` to release the WebSocket.
 - `audio.input.turn_detection` defaults to semantic VAD when `session` doesn't supply it. Override with your own object, or pass `null` to disable turn detection entirely.
 - `audio.input.transcription` defaults to `{ model: 'inworld/inworld-stt-1' }`, so user-side `writing` events fire out of the box. Override with your own object, or pass `null` to disable user-side transcription.
-- `on()` and `off()` are typed against `InworldVoiceEventMap` — known event names yield a typed callback payload, unknown names fall back to `unknown`.
+- `on()` and `off()` are typed against `InworldVoiceEventMap`. Known event names yield a typed callback payload. Unknown names fall back to `unknown`.

package/.docs/reference/voice/livekit.md

@@ -8,9 +8,9 @@ See [Realtime voice](https://mastra.ai/docs/voice/realtime-voice) for setup and
 
 The package has three entry points:
 
-- `@mastra/livekit`: server-side APIs — [`liveKitConnectionRoute()`](#livekitconnectionroute), [`dispatchVoiceSession()`](#dispatchvoicesession), [`pipeAgentReplyToWriter()`](#pipeagentreplytowriter), [`serializeSessionMetadata()`](#livekitsessionmetadata), and [`createEndCallTool()`](#createendcalltool). Import these from Mastra server code. This entry never loads the LiveKit agents runtime.
-- `@mastra/livekit/worker`: the worker runtime — [`createLiveKitWorker()`](#createlivekitworker), [`runLiveKitWorker()`](#runlivekitworker), [`chatContextToMessages()`](#chatcontexttomessages), and the session helpers [`speakGreeting()`](#speakgreeting), [`waitForAgentDoneSpeaking()`](#waitforagentdonespeaking), and [`runEndCall()`](#runendcall). Import it only from the worker entry file.
-- `@mastra/livekit/plugin`: the LLM-component plugin — [`MastraLLM`](#mastrallm) and [`createRemoteAgentReplyGenerator()`](#createremoteagentreplygenerator). Import it in workers that build their own `voice.AgentSession`. `createRemoteAgentReplyGenerator()` is also exported from `@mastra/livekit/worker` because it plugs into `createLiveKitWorker()`'s `generate` option; `MastraLLM` is plugin-only.
+- `@mastra/livekit`: server-side APIs, [`liveKitConnectionRoute()`](#livekitconnectionroute), [`dispatchVoiceSession()`](#dispatchvoicesession), [`pipeAgentReplyToWriter()`](#pipeagentreplytowriter), [`serializeSessionMetadata()`](#livekitsessionmetadata), and [`createEndCallTool()`](#createendcalltool). Import these from Mastra server code. This entry never loads the LiveKit agents runtime.
+- `@mastra/livekit/worker`: the worker runtime, [`createLiveKitWorker()`](#createlivekitworker), [`runLiveKitWorker()`](#runlivekitworker), [`chatContextToMessages()`](#chatcontexttomessages), and the session helpers [`speakGreeting()`](#speakgreeting), [`waitForAgentDoneSpeaking()`](#waitforagentdonespeaking), and [`runEndCall()`](#runendcall). Import it only from the worker entry file.
+- `@mastra/livekit/plugin`: the LLM-component plugin, [`MastraLLM`](#mastrallm) and [`createRemoteAgentReplyGenerator()`](#createremoteagentreplygenerator). Import it in workers that build their own `voice.AgentSession`. `createRemoteAgentReplyGenerator()` is also exported from `@mastra/livekit/worker` because it plugs into `createLiveKitWorker()`'s `generate` option. `MastraLLM` is plugin-only.
 
 ## `createLiveKitWorker()`
 
@@ -148,7 +148,7 @@ Returns: `VoiceTurnMessage[]`, where each entry is `{ role: 'system' | 'user' |
 
 ## `MastraLLM`
 
-A standard LiveKit LLM plugin (`llm.LLM`) backed by a Mastra agent. Use it when you build the `voice.AgentSession` yourself and want Mastra in the `llm` slot; [`createLiveKitWorker()`](#createlivekitworker) is the managed alternative. See [Use Mastra as the LLM component](https://mastra.ai/docs/voice/realtime-voice) for how to choose.
+A standard LiveKit LLM plugin (`llm.LLM`) backed by a Mastra agent. Use it when you build the `voice.AgentSession` yourself and want Mastra in the `llm` slot. [`createLiveKitWorker()`](#createlivekitworker) is the managed alternative. See [Use Mastra as the LLM component](https://mastra.ai/docs/voice/realtime-voice) for how to choose.
 
 With `remote`, the plugin streams each turn from your Mastra server over HTTP using Server-Sent Events (SSE). The agent loop, tools, and memory run server-side, and interrupting the agent aborts the server-side generation.
 
@@ -194,13 +194,13 @@ Provide exactly one reply source: `remote`, `agent`, or `generate`.
 
 ### Tools run on the Mastra agent
 
-Tools are defined and executed server-side on the Mastra agent. The plugin never forwards LiveKit tool definitions: if the session passes a non-empty `toolCtx`, it logs a one-time warning naming the ignored tools. Every tool must complete server-side — a tool that requires approval or client-side execution fails the turn with a descriptive error instead of hanging the call.
+Tools are defined and executed server-side on the Mastra agent. The plugin never forwards LiveKit tool definitions: if the session passes a non-empty `toolCtx`, it logs a one-time warning naming the ignored tools. Every tool must complete server-side: a tool that requires approval or client-side execution fails the turn with a descriptive error instead of hanging the call.
 
 Tool activity reaches the worker through `toolFeedback`, `onToolCall`, and `onTurnComplete`.
 
 ### Instructions
 
-LiveKit injects your `voice.Agent`'s `instructions` into the chat context of every request. The plugin drops them: the server-side Mastra agent's own instructions are authoritative. To change the prompt, change the Mastra agent.
+LiveKit injects your `voice.Agent`'s `instructions` into the chat context of every request. The plugin drops them because the server-side Mastra agent's own instructions are authoritative. To change the prompt, change the Mastra agent.
 
 ### Interrupted turns
 
@@ -243,7 +243,7 @@ When the server reports token usage for a turn, the plugin feeds it to LiveKit,
 
 ### Errors and timeouts
 
-The transport throws LiveKit's `APIError` types (`APIStatusError`, `APIConnectionError`, `APITimeoutError`), so the session's retry policy (`connOptions.maxRetry`) and `FallbackAdapter` failover work unchanged. A turn is never retried after its first token — a voice reply is better failed fast than replayed half-heard.
+The transport throws LiveKit's `APIError` types (`APIStatusError`, `APIConnectionError`, `APITimeoutError`), so the session's retry policy (`connOptions.maxRetry`) and `FallbackAdapter` failover work unchanged. A turn is never retried after its first token: a voice reply is better failed fast than replayed half-heard.
 
 A connect and first-token watchdog uses the session's `connOptions.timeoutMs` (10 seconds by default), so a server that accepts the connection but never streams can't cause indefinite dead air.
 
@@ -275,7 +275,7 @@ export default createLiveKitWorker({
 
 On the `generate` path the worker-level `toolFeedback` and `onTurnComplete` options don't apply, and the worker's end-call detection doesn't fire; pass the hooks to the generator instead.
 
-Cancelling a turn (barge-in) tears down the HTTP request, which aborts generation on the server. Errors are thrown as LiveKit `APIError` types; `retries` applies to the initial connection only — a turn is never retried after its first chunk.
+Cancelling a turn (barge-in) tears down the HTTP request, which aborts generation on the server. Errors are thrown as LiveKit `APIError` types. The `retries` option applies only to initial connection attempts. A turn is never retried after its first chunk.
 
 Returns: `VoiceReplyGenerator`.
 
@@ -325,7 +325,7 @@ await speakGreeting(session, {
 
 ## `waitForAgentDoneSpeaking()`
 
-Resolves once the agent is no longer producing or playing a reply — its state has left `thinking` and `speaking`. Resolves immediately when the agent is already idle, and always resolves within `maxWaitMs` (30 seconds by default) as a safety cap. Use it before tearing a session down so closing words play out instead of being cut off.
+Resolves once the agent is no longer producing or playing a reply: its state has left `thinking` and `speaking`. Resolves immediately when the agent is already idle, and always resolves within `maxWaitMs` (30 seconds by default) as a safety cap. Use it before tearing a session down so closing words play out instead of being cut off.
 
 ```typescript
 import { waitForAgentDoneSpeaking } from '@mastra/livekit/worker'
@@ -335,7 +335,7 @@ await waitForAgentDoneSpeaking(session)
 
 ## `runEndCall()`
 
-Ends the call after the agent asked to: waits for the agent's closing words to finish, speaks an optional final `message` non-interruptibly, then deletes the room (hanging up the caller, SIP included) and shuts the job down, which runs registered shutdown callbacks.
+Ends the call after the agent asks to hang up. It waits for the agent's closing words and speaks an optional final `message` without interruption. It then deletes the room and hangs up the caller, including SIP callers. The job shuts down with its registered callbacks.
 
 Pair it with [`MastraLLM`](#mastrallm)'s `onToolCall` and an [end-call tool](#createendcalltool) on the server-side agent to rebuild agent-initiated hang-up on a session you own:
 
@@ -369,7 +369,7 @@ The exported constants `DEFAULT_END_CALL_TOOL` (`'endCall'`), `DEFAULT_END_CALL_
 
 ## `createEndCallTool()`
 
-Builds the Mastra tool an agent calls to end the call itself: say goodbye, then hang up. The tool only signals intent (and runs optional bookkeeping) — the worker owns the actual hang-up. It lives on the server-safe root entry, so add it to agents defined in server code.
+Builds the Mastra tool an agent calls when it wants to end the call. The tool signals intent and can run optional bookkeeping. The worker performs the actual hang-up. The tool lives on the server-safe root entry. Add it to agents defined in server code.
 
 ```typescript
 import { Agent } from '@mastra/core/agent'
@@ -436,7 +436,7 @@ The route accepts a JSON body with optional `agentId`, `threadId`, and `resource
 
 ## `dispatchVoiceSession()`
 
-Dispatches a Mastra voice agent into a LiveKit room programmatically — for server-initiated sessions such as outbound calls.
+Dispatches a Mastra voice agent into a LiveKit room programmatically: for server-initiated sessions such as outbound calls.
 
 ```typescript
 import { dispatchVoiceSession } from '@mastra/livekit'
@@ -474,7 +474,7 @@ The metadata passed from the Mastra server to the worker through LiveKit job dis
 
 **requestContext** (`Record<string, unknown>`): Plain-object entries restored into a RequestContext for agent execution.
 
-The metadata travels as a JSON string. `liveKitConnectionRoute()` and `dispatchVoiceSession()` serialize it for you; use `serializeSessionMetadata(metadata)` when dispatching through your own code, or write the JSON directly in LiveKit-side configuration such as a SIP dispatch rule. Entries in `requestContext` reach the agent's dynamic instructions, tools, and input processors on every turn of the call.
+The metadata travels as a JSON string. `liveKitConnectionRoute()` and `dispatchVoiceSession()` serialize it for you; use `serializeSessionMetadata(metadata)` when dispatching through your own code, or write the JSON directly in LiveKit-side configuration such as a SIP dispatch rule. Entries in `requestContext` reach the agent's runtime-defined instructions, tools, and input processors on every turn of the call.
 
 ## Related
 

package/.docs/reference/voice/mistral.md

@@ -82,7 +82,7 @@ Returns: `Promise<NodeJS.ReadableStream>`
 
 ### `listen(audioStream, options?)`
 
-Transcribes audio using Mistral's Voxtral transcription model. Supports diarization, context biasing, and timestamp granularity.
+Transcribes audio using Mistral's Voxtral transcription model. Supports diarization, context biasing, and timestamp level of detail.
 
 **audioStream** (`NodeJS.ReadableStream`): Audio stream to transcribe.
 

package/.docs/reference/voice/openai-realtime.md

@@ -113,7 +113,7 @@ Returns: `Promise<void>`
 
 ### `updateConfig()`
 
-Updates the session configuration for the voice instance. This can be used to modify voice settings, turn detection, and other parameters.
+Updates the session configuration for the voice instance. This can modify voice settings and turn detection. It can also modify other parameters.
 
 **sessionConfig** (`Realtime.SessionConfig`): New session configuration to apply.
 

package/.docs/reference/voice/sarvam.md

@@ -129,4 +129,4 @@ Returns: `Promise<Array<{voiceId: SarvamVoiceId}>>`
 - Audio is returned as a stream containing binary audio data
 - Speech recognition supports mp3 and wav audio formats
 - `bulbul:v1`, `saarika:v1`, `saarika:v2`, and `saarika:flash` have been deprecated by Sarvam and are no longer supported. Use `bulbul:v3` (or `bulbul:v2`) for TTS and `saarika:v2.5` (or `saaras:v3`) for STT.
-- Speaker names aren't interchangeable between `bulbul:v2` and `bulbul:v3` — each model version has its own speaker catalog.
+- Speaker names aren't interchangeable between `bulbul:v2` and `bulbul:v3`. Each model version has its own speaker catalog.

package/.docs/reference/voice/voice.addTools.md

@@ -2,7 +2,7 @@
 
 # voice.addTools()
 
-The `addTools()` method equips a voice provider with tools (functions) that can be called by the model during real-time interactions. This enables voice assistants to perform actions like searching for information, making calculations, or interacting with external systems.
+The `addTools()` method equips a voice provider with tools (functions) that the model can call during real-time interactions. Voice assistants can use these tools to search for information or make calculations. They can also interact with external systems.
 
 ## Usage example
 

package/.docs/reference/voice/voice.events.md

@@ -2,7 +2,7 @@
 
 # Voice events
 
-Voice providers emit various events during real-time voice interactions. These events can be listened to using the [voice.on()](https://mastra.ai/reference/voice/voice.on) method and are particularly important for building interactive voice applications.
+Voice providers emit events during real-time voice interactions. These events can be listened to using the [voice.on()](https://mastra.ai/reference/voice/voice.on) method and are particularly important for building interactive voice applications.
 
 ## Common events
 

package/.docs/reference/voice/voice.getSpeakers.md

@@ -2,7 +2,7 @@
 
 # voice.getSpeakers()
 
-The `getSpeakers()` method retrieves a list of available voice options (speakers) from the voice provider. This allows applications to present users with voice choices or programmatically select the most appropriate voice for different contexts.
+The `getSpeakers()` method retrieves a list of available voice options (speakers) from the voice provider. Applications can present users with voice choices or programmatically select the most appropriate voice for different contexts.
 
 ## Usage example
 
@@ -124,7 +124,7 @@ Different voice providers return different metadata for their voices:
 
 ## Notes
 
-- The available voices vary significantly between providers
+- The available voices vary substantially between providers
 - Some providers may require authentication to retrieve the full list of voices
 - The default implementation returns an empty array if the provider doesn't support this method
 - For performance reasons, consider caching the results if you need to display the list frequently

package/.docs/reference/voice/voice.on.md

@@ -2,7 +2,7 @@
 
 # voice.on()
 
-The `on()` method registers event listeners for various voice events. This is particularly important for real-time voice providers, where events are used to communicate transcribed text, audio responses, and other state changes.
+The `on()` method registers event listeners for voice events. This is particularly important for real-time voice providers, where events are used to communicate transcribed text, audio responses, and other state changes.
 
 ## Usage example
 
@@ -60,7 +60,7 @@ This method doesn't return a value.
 
 ## Events
 
-For a comprehensive list of events and their payload structures, see the [Voice Events](https://mastra.ai/reference/voice/voice.events) documentation.
+For a detailed list of events and their payload structures, see the [Voice Events](https://mastra.ai/reference/voice/voice.events) documentation.
 
 Common events include:
 

package/.docs/reference/voice/xai-realtime.md

@@ -111,7 +111,7 @@ Returns: `void`
 
 ### `addInstructions()`
 
-Sets session instructions. If the WebSocket is open, the provider sends a `session.update`; passing `undefined` stores an empty string and clears the active instructions on the current session or the next connection.
+Sets session instructions. If the WebSocket is open, the provider sends a `session.update`. Passing `undefined` stores an empty string and clears the active instructions on the current session or the next connection.
 
 **instructions** (`string`): System instructions to send to xAI.
 
@@ -199,7 +199,7 @@ Returns: `Promise<void>`
 - `speaking`: emits assistant audio deltas.
 - `speaking.done`: emits when an assistant audio response completes.
 - `writing`: emits assistant text deltas and user input transcriptions.
-- `error`: emits xAI errors, provider execution errors, tool execution errors, and malformed function-call arguments. Tool errors include `details.call_id` and `details.name`.
+- `error`: emits xAI and provider execution errors. It also emits tool execution errors, and malformed function-call arguments. Tool errors include `details.call_id` and `details.name`.
 - `close`: emits when the WebSocket closes.
 - `tool-call-start`: emits before a Mastra function tool is executed.
 - `tool-call-result`: emits after a Mastra function tool returns.

package/.docs/reference/workflows/run-methods/cancel.md

@@ -38,7 +38,7 @@ Steps that check the `abortSignal` parameter can respond to cancellation:
 - Steps can check if already aborted: `if (abortSignal.aborted) { ... }`
 - Useful for cancelling timeouts, network requests, or long-running operations
 
-**Note:** Steps must actively check the abort signal to be canceled mid-execution. Steps that don't check the signal will run to completion, but subsequent steps won't execute.
+Steps must actively check the abort signal to be canceled mid-execution; otherwise, the current step runs to completion and subsequent steps don't execute.
 
 ## Extended usage examples
 

package/.docs/reference/workflows/run-methods/startAsync.md

@@ -2,7 +2,7 @@
 
 # Run.startAsync()
 
-The `.startAsync()` method starts a workflow run without waiting for completion. It returns immediately with the `runId`, allowing the workflow to execute in the background. This is useful for long-running workflows, scheduled tasks, or when you want to avoid blocking on workflow completion.
+The `.startAsync()` method starts a workflow run without waiting for completion. It returns immediately with the `runId`, allowing the workflow to execute in the background. This is useful for long-running workflows or scheduled tasks. It also avoids blocking on workflow completion.
 
 ## Usage example
 

package/.docs/reference/workflows/run-methods/timeTravel.md

@@ -2,7 +2,7 @@
 
 # Run.timeTravel()
 
-The `.timeTravel()` method re-executes a workflow starting from any specific step, using either stored snapshot data or custom context you provide. This is useful for debugging failed workflows, testing individual steps with different inputs, or recovering from errors without re-running the entire workflow.
+The `.timeTravel()` method re-executes a workflow starting from any specific step, using either stored snapshot data or custom context you provide. Use it to debug failed workflows and test individual steps with different inputs. It can also recover from errors without re-running the entire workflow.
 
 ## Usage example
 

package/.docs/reference/workflows/workflow-methods/foreach.md

@@ -40,7 +40,7 @@ If you need to run multiple operations per item, use a nested workflow as the st
 
 ### Using `.then()` after `.foreach()`
 
-When you chain `.then()` after `.foreach()`, the next step receives the entire output array as its input. This allows you to aggregate or process all results together.
+When you chain `.then()` after `.foreach()`, the next step receives the entire output array as its input. You can aggregate or process all results together.
 
 ```typescript
 workflow