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

package/.docs/docs/memory/observational-memory.md

@@ -4,7 +4,7 @@
 
 **Added in:** `@mastra/memory@1.1.0`
 
-Observational Memory (OM) is Mastra's memory system for long-context agentic memory. Two background agents — an **Observer** and a **Reflector** — watch your agent's conversations and maintain a dense observation log that replaces raw message history as it grows.
+Observational Memory (OM) is Mastra's memory system for long-context agentic memory. Background agents, an **Observer** and a **Reflector**, watch your agent's conversations and maintain a dense observation log that replaces raw message history as it grows.
 
 ## Quickstart
 
@@ -98,7 +98,7 @@ See [configuration options](https://mastra.ai/reference/memory/observational-mem
 
 ## Temporal gap markers
 
-Temporal gap markers insert a short reminder before a new user message when enough time has passed since the previous message in the thread. They help the agent and the UI see that the conversation resumed after a meaningful pause.
+Temporal gap markers insert a short reminder before a new user message when enough time has passed since the previous message in the thread. They help the agent and the UI see that the conversation resumed after a useful pause.
 
 Temporal gap markers are off by default. Enable them with `temporalMarkers: true` in the `observationalMemory` config:
 
@@ -191,15 +191,15 @@ See [the API reference](https://mastra.ai/reference/memory/observational-memory)
 
 ## Benefits
 
-- **Prompt caching**: OM's context is stable and observations append over time rather than being dynamically retrieved each turn. This keeps the prompt prefix cacheable, which reduces costs.
+- **Prompt caching**: OM's context is stable and observations append over time rather than being retrieved at runtime each turn. This keeps the prompt prefix cacheable, which reduces costs.
 - **Compression**: Raw message history and tool results get compressed into a dense observation log. Smaller context means faster responses and longer coherent conversations.
 - **Zero context rot**: The agent sees relevant information instead of noisy tool calls and irrelevant tokens, so the agent stays on task over long sessions.
 
 ## How it works
 
-You don't remember every word of every conversation you've ever had. You observe what happened subconsciously, then your brain reflects — reorganizing, combining, and condensing into long-term memory. OM works the same way.
+You don't remember every word of every conversation you've ever had. You observe what happened subconsciously, then your brain reflects, reorganizing, combining, and condensing into long-term memory. OM works the same way.
 
-Every time an agent responds, it sees a context window containing its system prompt, recent message history, and any injected context. The context window is finite; even models with large token limits perform worse when the window is full. This causes two problems:
+Every time an agent responds, it sees a context window containing its system prompt, recent message history, and any injected context. The context window is finite. Even models with large token limits perform worse when the window is full. This causes two problems:
 
 - **Context rot**: the more raw message history an agent carries, the worse it performs.
 - **Context waste**: most of that history contains tokens no longer needed to keep the agent on task.
@@ -274,7 +274,7 @@ new Extractor({
 })
 ```
 
-Use dynamic `instructions` or `schema` functions when an extractor needs runtime context, such as the active memory instance or request context:
+Use runtime `instructions` or `schema` functions when an extractor needs runtime context, such as the active memory instance or request context:
 
 ```typescript
 new Extractor({
@@ -389,7 +389,7 @@ Date: 2026-01-15
   - 🔴 12:15 User stated the app name is "Acme Dashboard"
 ```
 
-The compression is typically 5–40×. The Observer also tracks a **current task** and **suggested response** so the agent picks up where it left off.
+The compression is typically between 5x and 40x. The Observer also tracks a **current task** and **suggested response** so the agent picks up where it left off.
 
 If you enable `observation.threadTitle`, the Observer can also suggest a short thread title when the conversation topic meaningfully changes. Thread title generation is opt-in and updates the thread metadata, so apps like Mastra Code can show the latest title in thread lists and status UI.
 
@@ -397,7 +397,7 @@ Example: An agent using Playwright MCP might see 50,000+ tokens per page snapsho
 
 ### Reflections
 
-When observations exceed their threshold (default: 40,000 tokens), the Reflector condenses them, combines related items, and reflects on patterns.
+When observations exceed their threshold (default: 40,000 tokens), the Reflector condenses them and combines related items, plus reflects on patterns.
 
 The result is a three-tier system:
 
@@ -446,7 +446,7 @@ When vector search is configured, new observation groups are automatically index
 
 #### Restricting to the current thread
 
-By default, the recall tool scope is `'resource'` — the agent can list threads, browse other threads, and search across all conversations. Set `scope: 'thread'` to restrict the agent to only the current thread:
+By default, the recall tool scope is `'resource'`, the agent can list threads and browse other threads, plus search across all conversations. Set `scope: 'thread'` to restrict the agent to only the current thread:
 
 ```typescript
 const memory = new Memory({
@@ -481,7 +481,9 @@ See the [recall tool reference](https://mastra.ai/reference/memory/observational
 To see how it works in practice, open [Studio](https://mastra.ai/docs/studio/overview) and navigate to an agent with OM enabled. The **Memory** tab displays:
 
 - **Token progress bars**: Current token counts for messages and observations, showing how close each is to its threshold. Hover over the info icon to see the model and threshold for the Observer and Reflector.
-- **Active observations**: The current observation log, rendered inline. When previous observation or reflection records exist, expand "Previous observations" to browse them.
+
+- **Active observations**: The current observation log is shown inline. If earlier observation or reflection records exist, expand "Previous observations" to browse them.
+
 - **Background processing**: During a conversation, buffered observation chunks and reflection status appear as the agent processes in the background.
 
 The progress bars update live while the agent is observing or reflecting, showing elapsed time and a status badge.
@@ -490,7 +492,7 @@ The progress bars update live while the agent is observing or reflecting, showin
 
 The Observer and Reflector run in the background. Any model that works with Mastra's [model routing](https://mastra.ai/models) (`provider/model`) can be used. When no model is set, the default model is `google/gemini-2.5-flash`.
 
-Generally speaking, we recommend using a model that has a large context window (128K+ tokens) and is fast enough to run in the background without slowing down your actions.
+Mastra recommends using a model that has a large context window (128K+ tokens) and is fast enough to run in the background without slowing down your actions.
 
 If you're unsure which model to use, start with the default `google/gemini-2.5-flash`. We've also successfully tested `openai/gpt-5-mini`, `anthropic/claude-haiku-4-5`, `deepseek/deepseek-reasoner`, `deepseek/deepseek-v4-pro`, `deepseek/deepseek-v4-flash`, `xai/grok-4-1-fast`, `qwen3`, and `glm-4.7`.
 
@@ -508,7 +510,7 @@ See [model configuration](https://mastra.ai/reference/memory/observational-memor
 
 > **Note:** `google/gemini-2.5-flash` is unusually good at preserving detail in long output. As a result, the Reflector can produce reflections that stay above the configured `reflection.observationTokens` threshold even after the maximum compression retry. When this happens, the Reflector returns the smallest non-degenerate candidate produced during retries so the loop terminates instead of running forever.
 >
-> If you'd rather have more aggressive compression on the Reflector, swap to a model that condenses more readily, such as `xai/grok-4-1-fast`, `deepseek/deepseek-v4-pro`, or `deepseek/deepseek-v4-flash`. You can keep `google/gemini-2.5-flash` for the Observer and use a different model for the Reflector — see [different models per agent](https://mastra.ai/reference/memory/observational-memory).
+> If you'd rather have more aggressive compression on the Reflector, swap to a model that condenses more readily, such as `xai/grok-4-1-fast`, `deepseek/deepseek-v4-pro`, or `deepseek/deepseek-v4-flash`. You can keep `google/gemini-2.5-flash` for the Observer and use a different model for the Reflector. See [different models per agent](https://mastra.ai/reference/memory/observational-memory).
 
 ### Token-tiered model selection
 
@@ -546,9 +548,9 @@ const memory = new Memory({
 })
 ```
 
-The `upTo` keys are inclusive upper bounds. OM computes the actual input token count for the Observer or Reflector call, resolves the matching tier directly, and uses that concrete model for the run.
+The `upTo` keys are inclusive upper bounds. OM computes the actual input token count for the Observer or Reflector call and resolves the matching tier directly, plus uses that concrete model for the run.
 
-If the input exceeds the largest configured threshold, an error is thrown — ensure your thresholds cover the full range of possible input sizes, or use a model with a sufficiently large context window at the highest tier.
+If the input exceeds the largest configured threshold, an error is thrown, ensure your thresholds cover the full range of possible input sizes, or use a model with a sufficiently large context window at the highest tier.
 
 ## Scopes
 
@@ -651,10 +653,10 @@ const filePart = {
 
 The `tokenEstimate` object follows the same shape the Token Counter uses internally for cached estimates:
 
-- `v` — cache schema version. Set to `0`. Caller-supplied entries are exempt from the framework's version check, so the value isn't read.
-- `source` — cache lineage marker. Must be `'client'`. This is what tells the Token Counter the entry is authoritative and should be honored verbatim instead of being recomputed or overwritten.
-- `key` — content fingerprint slot. Set to `'client'`. Framework entries use a content hash here so they invalidate when the payload changes; the `'client'` sentinel keeps caller estimates stable across writes.
-- `tokens` — the token count to use. Must be a finite non-negative number.
+- `v`: cache schema version. Set to `0`. Caller-supplied entries are exempt from the framework's version check, so the value isn't read.
+- `source`: cache lineage marker. Must be `'client'`. This is what tells the Token Counter the entry is authoritative and should be honored verbatim instead of being recomputed or overwritten.
+- `key`: content fingerprint slot. Set to `'client'`. Framework entries use a content hash here so they invalidate when the payload changes. The `'client'` sentinel keeps caller estimates stable across writes.
+- `tokens`: the token count to use. Must be a finite non-negative number.
 
 Additional notes:
 
@@ -662,7 +664,7 @@ Additional notes:
 
 ## Async buffering
 
-Without async buffering, the Observer runs synchronously when the message threshold is reached — the agent pauses mid-conversation while the Observer LLM call completes. With async buffering (enabled by default), observations are pre-computed in the background as the conversation grows. When the threshold is hit, buffered observations activate instantly with no pause.
+Without async buffering, the Observer runs synchronously when the message threshold is reached, the agent pauses mid-conversation while the Observer LLM call completes. With async buffering (enabled by default), observations are pre-computed in the background as the conversation grows. When the threshold is hit, buffered observations activate instantly with no pause.
 
 ### How it works
 
@@ -670,17 +672,17 @@ As the agent converses, message tokens accumulate. At regular intervals (`buffer
 
 When message tokens reach the `messageTokens` threshold, buffered chunks activate: their observations move into the active observation log, and the corresponding raw messages are removed from the context window. The agent never pauses.
 
-Buffered observations also include continuation hints — a suggested next response and the current task — so the main agent maintains conversational continuity after activation shrinks the context window.
+Buffered observations also include continuation hints, a suggested next response and the current task, so the main agent maintains conversational continuity after activation shrinks the context window.
 
 If the agent produces messages faster than the Observer can process them, a `blockAfter` safety threshold forces a synchronous observation as a last resort. Buffered activation still preserves a minimum remaining context (the smaller of \~1k tokens or the configured retention floor).
 
-Reflection works similarly — the Reflector runs in the background when observations reach a fraction of the reflection threshold.
+Reflection works similarly, the Reflector runs in the background when observations reach a fraction of the reflection threshold.
 
 ### Settings
 
 | Setting                               | Default | What it controls                                                                                                                                                                                                                                                              |
 | ------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `observation.bufferTokens`            | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens` — with the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).                                                                                            |
+| `observation.bufferTokens`            | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens`. With the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).                                                                                             |
 | `observation.bufferActivation`        | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history.                                                                                         |
 | `observation.blockAfter`              | `1.2`   | Safety threshold as a multiplier of `messageTokens`. At `1.2`, synchronous observation is forced at 36k tokens (1.2 × 30k). Only matters if buffering can't keep up.                                                                                                          |
 | `activateAfterIdle`                   | none    | Forces buffered observations to activate after a period of inactivity, even before `observation.messageTokens` is reached. Accepts a numeric millisecond value such as `300_000`, duration strings like `"5m"` or `"1hr"`, or `"auto"` for a provider-aware prompt cache TTL. |
@@ -761,7 +763,7 @@ const memory = new Memory({
 })
 ```
 
-- `previousObserverTokens: 2000` → default; keeps \~2k tokens of recent observations.
+- `previousObserverTokens: 2000` → default. Keeps \~2k tokens of recent observations.
 - `previousObserverTokens: 0` → omit previous observations completely.
 - `previousObserverTokens: false` → disable truncation and keep full previous observations.
 
@@ -770,7 +772,7 @@ const memory = new Memory({
 No manual migration needed. OM reads existing messages and observes them lazily when thresholds are exceeded.
 
 - **Thread scope**: The first time a thread exceeds `observation.messageTokens`, the Observer processes the backlog.
-- **Resource scope**: All unobserved messages across all threads for a resource are processed together. For users with many existing threads, this could take significant time.
+- **Resource scope**: All unobserved messages across all threads for a resource are processed together. For users with many existing threads, this could take substantial time.
 
 ## Comparing OM with other memory features
 
@@ -779,7 +781,7 @@ No manual migration needed. OM reads existing messages and observes them lazily
 - **[Semantic Recall](https://mastra.ai/docs/memory/semantic-recall)**: RAG-based retrieval of relevant past messages
 - **[Multi-user threads](https://mastra.ai/docs/memory/multi-user-threads)**: How OM attributes facts to individual users when several people share a single thread
 
-If you're using working memory to store conversation summaries or ongoing state that grows over time, OM is a better fit. Working memory is for small, structured data; OM is for long-running event logs. OM also manages message history automatically—the `messageTokens` setting controls how much raw history remains before observation runs.
+If you're using working memory to store conversation summaries or ongoing state that grows over time, OM is a better fit. Working memory is for small, structured data. OM is for long-running event logs. OM also manages message history automatically, the `messageTokens` setting controls how much raw history remains before observation runs.
 
 In practical terms, OM replaces both working memory and message history, and has greater accuracy (and lower cost) than Semantic Recall.
 

package/.docs/docs/memory/overview.md

@@ -2,7 +2,7 @@
 
 # Memory
 
-Memory enables your agent to remember user messages, agent replies, and tool results across interactions, giving it the context it needs to stay consistent, maintain conversation flow, and produce better answers over time.
+Memory enables your agent to remember user messages and agent replies, and tool results across interactions, giving it the context it needs to stay consistent, maintain conversation flow, plus produce better answers over time.
 
 Mastra agents can be configured to store [message history](https://mastra.ai/docs/memory/message-history). Additionally, you can enable:
 
@@ -19,7 +19,7 @@ Memory results will be stored in one or more of your configured [storage provide
 
 ## When to use memory
 
-Use memory when your agent needs to maintain multi-turn conversations that reference prior exchanges, recall user preferences or facts from earlier in a session, or build context over time within a conversation thread. Skip memory for single-turn requests where each interaction is independent.
+Use memory when your agent needs to maintain multi-turn conversations that reference prior exchanges or recall user preferences or facts from earlier in a session, or alternatively build context over time within a conversation thread. Skip memory for single-turn requests where each interaction is independent.
 
 ## Quickstart
 
@@ -182,21 +182,21 @@ Each delegation creates a fresh `threadId` and a deterministic `resourceId` for
 
 - **Thread ID**: Unique per delegation. The subagent starts with a clean message history every time it's called.
 - **Resource ID**: Derived as `{parentResourceId}-{agentName}`. Because the resource ID is stable across delegations, resource-scoped memory persists between calls. A subagent remembers facts from previous delegations by the same user.
-- **Memory instance**: If a subagent has no memory configured, it inherits the supervisor's `Memory` instance, including all of its options. If the subagent defines its own, that takes precedence.
+- **Memory instance**: A subagent without its own memory inherits the supervisor's `Memory` instance and all configured options. If the subagent defines its own, that takes precedence.
 
 > **Note:** Title generation (`generateTitle`) is a top-level thread concern and **isn't** applied to inherited subagent threads. Because each delegation creates an ephemeral thread that no one sees, running title generation for it would waste an LLM call per delegation. To generate titles for a subagent's own threads, give that subagent its own memory configuration.
 
-The supervisor forwards its conversation context to the subagent so it has enough background to complete the task. Only the delegation prompt and the subagent's response are saved — the full parent conversation isn't stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/agents/supervisor-agents) callback.
+The supervisor forwards its conversation context to the subagent so it has enough background to complete the task. Only the delegation prompt and the subagent's response are saved, the full parent conversation isn't stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/agents/supervisor-agents) callback.
 
-> **Note:** Subagent resource IDs are always suffixed with the agent name (`{parentResourceId}-{agentName}`). Two different subagents under the same supervisor never share a resource ID through delegation.
+> **Note:** Subagent resource IDs are always suffixed with the agent name (`{parentResourceId}-{agentName}`). Different subagents under the same supervisor never share a resource ID through delegation.
 
 To go beyond this default isolation, you can share memory between agents by passing matching identifiers when you call them directly.
 
 ### Share memory between agents
 
-When you call agents directly (outside the delegation flow), memory sharing is controlled by two identifiers: `resourceId` and `threadId`. Agents that use the same values read and write to the same data. This is useful when agents collaborate on a shared context — for example, a researcher that saves notes and a writer that reads them.
+When you call agents directly (outside the delegation flow), memory sharing is controlled by two identifiers: `resourceId` and `threadId`. Agents that use the same values read and write to the same data. This is useful when agents collaborate on a shared context, for example, a researcher that saves notes and a writer that reads them.
 
-**Resource-scoped sharing** is the most common pattern. [Working memory](https://mastra.ai/docs/memory/working-memory) and [semantic recall](https://mastra.ai/docs/memory/semantic-recall) default to `scope: 'resource'`. If two agents share a `resourceId`, they share observations, working memory, and embeddings — even across different threads:
+**Resource-scoped sharing** is the most common pattern. [Working memory](https://mastra.ai/docs/memory/working-memory) and [semantic recall](https://mastra.ai/docs/memory/semantic-recall) default to `scope: 'resource'`. If two agents share a `resourceId`, they share observations, working memory, and embeddings, even across different threads:
 
 ```typescript
 // Both agents share the same resource-scoped memory
@@ -209,15 +209,15 @@ await writer.generate('Write a summary from the research notes.', {
 })
 ```
 
-Because both calls use `resource: 'project-42'`, the writer can access the researcher's observations, working memory, and semantic embeddings. Each agent still has its own thread, so message histories stay separate.
+Because both calls use `resource: 'project-42'`, the writer can access the researcher's observations and working memory. Semantic embeddings are also shared through the resource. Each agent still has its own thread, so message histories stay separate.
 
-**Thread-scoped sharing** gives tighter coupling. [Observational Memory](https://mastra.ai/docs/memory/observational-memory) uses `scope: 'thread'` by default. If two agents use the same `resource` _and_ `thread`, they share the full message history. Each agent sees every message the other has written. This is useful when agents need to build on each other's exact outputs.
+**Thread-scoped sharing** gives tighter coupling. [Observational Memory](https://mastra.ai/docs/memory/observational-memory) uses `scope: 'thread'` by default. If two agents use the same `resource` and `thread`, they share the full message history. Each agent sees every message the other has written. This is useful when agents need to build on each other's exact outputs.
 
 ## Observability
 
 Enable [Tracing](https://mastra.ai/docs/observability/tracing/overview) to monitor and debug memory in action. Traces show you exactly which messages and observations the agent included in its context for each request, helping you understand agent behavior and verify that memory retrieval is working as expected.
 
-Open [Studio](https://mastra.ai/docs/studio/overview) and select the **Observability** tab in the sidebar. Open the trace of a recent agent request, then look for spans of LLMs calls.
+Open [Studio](https://mastra.ai/docs/studio/overview) and select the **Observability** tab in the sidebar. Open the trace of a recent agent request and look for its LLM call spans.
 
 ## Switch memory per request
 

package/.docs/docs/memory/semantic-recall.md

@@ -10,7 +10,7 @@ If you ask your friend what they did last weekend, they will search in their mem
 
 Semantic recall is RAG-based search that helps agents maintain context across longer interactions when messages are no longer within [recent message history](https://mastra.ai/docs/memory/message-history).
 
-It uses vector embeddings of messages for similarity search, integrates with various vector stores, and has configurable context windows around retrieved messages.
+It uses vector embeddings of messages for similarity search and integrates with vector stores, plus has configurable context windows around retrieved messages.
 
 ![Diagram showing Mastra Memory semantic recall](/assets/images/semantic-recall-fd7b9336a6d0d18019216cb6d3dbe710.png)
 
@@ -34,7 +34,7 @@ const agent = new Agent({
   id: 'support-agent',
   name: 'SupportAgent',
   instructions: 'You are a helpful support agent.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({
       id: 'agent-storage',
@@ -64,7 +64,7 @@ const agent = new Agent({
   id: 'support-agent',
   name: 'SupportAgent',
   instructions: 'You are a helpful support agent.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new MongoDBStore({
       id: 'agent-storage',

package/.docs/docs/memory/working-memory.md

@@ -4,7 +4,7 @@
 
 While [message history](https://mastra.ai/docs/memory/message-history) and [semantic recall](https://mastra.ai/docs/memory/semantic-recall) help agents remember conversations, working memory allows them to maintain persistent information about users across interactions.
 
-Think of it as the agent's active thoughts or scratchpad – the key information they keep available about the user or task. It's similar to how a person would naturally remember someone's name, preferences, or important details during a conversation.
+Working memory is the agent's active scratchpad: key information it keeps available about the user or task. It can retain a person's name, preferences, or other important details during a conversation.
 
 This is useful for maintaining ongoing state that's always relevant and should always be available to the agent.
 
@@ -17,7 +17,7 @@ Working memory can persist at two different scopes:
 - **Resource-scoped** (default): Memory persists across all conversation threads for the same user
 - **Thread-scoped**: Memory is isolated per conversation thread
 
-**Important:** Switching between scopes means the agent won't see memory from the other scope - thread-scoped memory is completely separate from resource-scoped memory.
+**Requirement:** Switching between scopes means the agent won't see memory from the other scope - thread-scoped memory is completely separate from resource-scoped memory.
 
 ## Quickstart
 
@@ -32,7 +32,7 @@ const agent = new Agent({
   id: 'personal-assistant',
   name: 'PersonalAssistant',
   instructions: 'You are a helpful personal assistant.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     options: {
       workingMemory: {
@@ -45,7 +45,7 @@ const agent = new Agent({
 
 ## How it works
 
-Working memory is a block of Markdown text that the agent is able to update over time to store continuously relevant information.
+Working memory is a block of Markdown text that the agent can update over time to store continuously relevant information.
 
 ## Memory persistence scopes
 
@@ -134,7 +134,7 @@ Resource-scoped working memory requires specific storage adapters that support t
 
 ## Custom templates
 
-Templates guide the agent on what information to track and update in working memory. While a default template is used if none is provided, you'll typically want to define a custom template tailored to your agent's specific use case to ensure it remembers the most relevant information. For threads shared by multiple users, see [Multi-user threads](https://mastra.ai/docs/memory/multi-user-threads).
+Templates guide the agent on what information to track and update in working memory. Mastra uses a default template when you don't provide one. Define a custom template for your agent's use case so it remembers the most relevant information. For threads shared by multiple users, see [Multi-user threads](https://mastra.ai/docs/memory/multi-user-threads).
 
 Here's an example of a custom template. In this example the agent will store the users name, location, timezone, etc as soon as the user sends a message containing any of the info:
 
@@ -214,7 +214,7 @@ const paragraphMemory = new Memory({
 
 Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.). When using a schema, the agent will see and update working memory as a JSON object matching your schema.
 
-**Important:** You must specify either `template` or `schema`, but not both.
+**Requirement:** You must specify either `template` or `schema`, but not both.
 
 ### Example: Schema-Based Working Memory
 
@@ -271,8 +271,8 @@ Schema-based working memory uses **merge semantics**, meaning the agent only nee
 
 ## Choosing between template and schema
 
-- Use a **template** (Markdown) if you want the agent to maintain memory as a free-form text block, such as a user profile or scratchpad. Templates use **replace semantics** — the agent must provide the complete memory content on each update.
-- Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. The `workingMemory.schema` field accepts any `PublicSchema`-compatible schema (including Zod v3, Zod v4, JSON Schema, or already-standard schemas). Schemas use **merge semantics** — the agent only provides fields to update, and existing fields are preserved.
+- Use a **template** (Markdown) if you want the agent to maintain memory as a free-form text block, such as a user profile or scratchpad. Templates use **replace semantics**: the agent must provide the complete memory content on each update.
+- Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. The `workingMemory.schema` field accepts any `PublicSchema`-compatible schema (including Zod v3, Zod v4, JSON Schema, or already-standard schemas). Schemas use **merge semantics**: the agent only provides fields to update, and existing fields are preserved.
 - Only one mode can be active at a time: setting both `template` and `schema` isn't supported.
 
 ## Example: Multi-step retention

package/.docs/docs/observability/integrations/bridges/datadog.md

@@ -6,7 +6,7 @@
 
 The Datadog Bridge enables bidirectional integration between Mastra's tracing system and Datadog. Unlike exporters that send trace data after execution completes, the bridge creates native dd-trace spans in real time so that auto-instrumented APM operations (HTTP calls, database queries, etc.) inside your tools and processors are correctly nested under their parent Mastra spans.
 
-> **Not using dd-trace APM?:** If you only need to send LLM Observability data and don't use `dd-trace` APM auto-instrumentation, the [Datadog Exporter](https://mastra.ai/docs/observability/integrations/exporters/datadog) is simpler — it supports agentless mode and sends spans directly to Datadog without a local agent.
+> **Not using dd-trace APM?:** If you only need to send LLM Observability data and don't use `dd-trace` APM auto-instrumentation, the [Datadog Exporter](https://mastra.ai/docs/observability/integrations/exporters/datadog) is simpler, it supports agentless mode and sends spans directly to Datadog without a local agent.
 
 ## When to use the bridge
 
@@ -34,9 +34,9 @@ The DatadogBridge participates in two parts of the dd-trace pipeline:
 - Maintains parent-child relationships in Datadog LLM Observability using nested `llmobs.trace()` calls
 - Reuses the same data shape and span-kind mapping as the [Datadog Exporter](https://mastra.ai/docs/observability/integrations/exporters/datadog)
 
-## Why this matters
+## Trace and log correlation
 
-Without the bridge, the Datadog Exporter only creates LLM Observability spans after a trace completes. During execution, no `dd-trace` span is active in scope, so any HTTP or database call made by a tool falls back to whatever `dd-trace` span is active at the time — typically the incoming request handler. The result is that service calls from MCP tools or output processors appear as children of the request span instead of the agent or processor span that actually made them.
+Without the bridge, the Datadog Exporter only creates LLM Observability spans after a trace completes. During execution, no `dd-trace` span is active in scope, so any HTTP or database call made by a tool falls back to whatever `dd-trace` span is active at the time, typically the incoming request handler. The result is that service calls from MCP tools or output processors appear as children of the request span instead of the agent or processor span that actually made them.
 
 The bridge fixes this by creating real dd-trace spans up front, so the scope is correct when auto-instrumentation runs.
 
@@ -134,7 +134,7 @@ DD_LLMOBS_ML_APP=my-llm-app
 
 When `dd-trace` is initialized, it routes APM data to your local Datadog Agent on `localhost:8126`. The bridge enables LLM Observability on top of the same tracer, so both sets of data appear under the same service in Datadog.
 
-No Mastra exporters are required when using the bridge — both APM and LLM Observability data flow through `dd-trace`. You can still add Mastra exporters if you want to send traces to additional destinations.
+No Mastra exporters are required when using the bridge, both APM and LLM Observability data flow through `dd-trace`. You can still add Mastra exporters if you want to send traces to additional destinations.
 
 ## Agent vs. agentless mode
 
@@ -184,7 +184,7 @@ const result = await agent.generate('Hello', {
 })
 ```
 
-Tags formatted as `key:value` (e.g., `instance_name:career-scout-api`) are split into structured tag entries; tags without a colon are set with a `true` value.
+Tags formatted as `key:value` (e.g., `instance_name:career-scout-api`) are split into structured tag entries. Tags without a colon are set with a `true` value.
 
 ## Promoting context keys to flat tags
 
@@ -206,7 +206,7 @@ If APM spans aren't connecting to Mastra spans as expected:
 - Verify `dd-trace` is initialized **before** any other imports (it patches libraries at load time)
 - Verify a local Datadog Agent is running and reachable at `localhost:8126`
 - Ensure the DatadogBridge is set as `bridge` (not as an entry in `exporters`) in your observability config
-- Confirm you haven't also added the `DatadogExporter` to `exporters` — using both will double-emit LLM Observability data
+- Confirm you haven't also added the `DatadogExporter` to `exporters`: using both will double-emit LLM Observability data
 
 For native-module compatibility issues with `dd-trace` and bundler externals, see the [Datadog exporter troubleshooting](https://mastra.ai/docs/observability/integrations/exporters/datadog) section.
 

package/.docs/docs/observability/integrations/bridges/otel.md

@@ -6,7 +6,7 @@
 
 The OpenTelemetry (OTEL) Bridge enables bidirectional integration between Mastra's tracing system and existing OpenTelemetry infrastructure. Unlike exporters that send trace data to external platforms, the bridge creates native OTEL spans that participate in your distributed tracing context.
 
-> **Looking to send traces without existing OTEL infrastructure?:** If you don't have existing OpenTelemetry instrumentation, the [OpenTelemetry Exporter](https://mastra.ai/docs/observability/integrations/exporters/otel) may be simpler — it sends traces directly without requiring an OTEL SDK setup.
+> **Looking to send traces without existing OTEL infrastructure?:** If you don't have existing OpenTelemetry instrumentation, the [OpenTelemetry Exporter](https://mastra.ai/docs/observability/integrations/exporters/otel) may be simpler, it sends traces directly without requiring an OTEL SDK setup.
 
 ## When to use the bridge
 
@@ -25,7 +25,7 @@ The OtelBridge provides two-way integration:
 
 - Reads from OTEL ambient context (AsyncLocalStorage) automatically
 - Inherits trace ID and parent span ID from active OTEL spans
-- Respects OTEL sampling decisions — if a trace isn't sampled, Mastra won't create spans for it
+- Respects OTEL sampling decisions: if a trace isn't sampled, Mastra won't create spans for it
 - No manual trace ID passing required when OTEL auto-instrumentation is active
 
 **From Mastra to OTEL:**
@@ -130,7 +130,7 @@ export const mastra = new Mastra({
 })
 ```
 
-No Mastra exporters are required when using the bridge — traces are sent via your OTEL SDK configuration. You can optionally add Mastra exporters if you want to send traces to additional destinations.
+No Mastra exporters are required when using the bridge, traces are sent via your OTEL SDK configuration. You can optionally add Mastra exporters if you want to send traces to additional destinations.
 
 ### Forwarding logs (optional)
 
@@ -151,9 +151,9 @@ const sdk = new NodeSDK({
 })
 ```
 
-Logs that originate inside a Mastra span are emitted under that span's OTEL context, so backends like Datadog, Grafana, and Honeycomb correlate them with the surrounding trace automatically. Logs without trace context fall through to the currently active OTEL context.
+Logs that originate inside a Mastra span are emitted under that span's OTEL context, so backends like Datadog, Grafana, and Honeycomb correlate them with the surrounding trace automatically. Logs without trace context use the currently active OTEL context.
 
-If you don't register a `LoggerProvider`, log emission is a silent no-op — traces continue to work as configured.
+If you don't register a `LoggerProvider`, log emission is a silent no-op, traces continue to work as configured.
 
 ### Running Your Application
 

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

@@ -2,7 +2,7 @@
 
 # Datadog exporter
 
-[Datadog](https://datadoghq.com/) is a comprehensive monitoring platform with dedicated LLM Observability features. The Datadog exporter sends your traces to Datadog's LLM Observability product, providing insights into model performance, token usage, and conversation flows.
+[Datadog](https://datadoghq.com/) is a complete monitoring platform with dedicated LLM Observability features. The Datadog exporter sends your traces to Datadog's LLM Observability product, providing insights into model performance and token usage, plus conversation flows.
 
 > **Also using dd-trace APM?:** If you also use `dd-trace` APM auto-instrumentation, consider the [Datadog Bridge](https://mastra.ai/docs/observability/integrations/bridges/datadog) instead. The bridge creates `dd-trace` spans in real time so HTTP and database calls inside tools and processors are correctly nested under their parent Mastra span. The exporter on its own sends LLM Observability data after execution completes, which means auto-instrumented APM spans fall back to the request handler.
 

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

@@ -102,7 +102,7 @@ export const mastra = new Mastra({
 
 > **Note:** For advanced usage, including the full `MastraExporter` options and multi-agent trace examples, see [Laminar's Mastra integration guide](https://laminar.sh/docs/tracing/integrations/mastra).
 
-Mastra also ships a standalone [`LaminarExporter`](https://mastra.ai/reference/observability/tracing/exporters/laminar) in `@mastra/laminar` that sends spans over OTLP/HTTP. It can't inherit an active OTel context and doesn't fully map Mastra spans to Laminar's native format, so use the `@lmnr-ai/lmnr` integration above for `observe()` wrappers, multi-agent root spans, and accurate Laminar rendering.
+Mastra also includes a standalone [`LaminarExporter`](https://mastra.ai/reference/observability/tracing/exporters/laminar) in `@mastra/laminar` that sends spans over OTLP/HTTP. It can't inherit an active OTel context and doesn't fully map Mastra spans to Laminar's native format, so use the `@lmnr-ai/lmnr` integration above for `observe()` wrappers, multi-agent root spans, and accurate Laminar rendering.
 
 ## Related
 

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

@@ -2,7 +2,7 @@
 
 # Langfuse exporter
 
-[Langfuse](https://langfuse.com/) is an open-source observability platform specifically designed for LLM applications. The Langfuse exporter sends your traces to Langfuse, providing detailed insights into model performance, token usage, and conversation flows.
+[Langfuse](https://langfuse.com/) is an open-source observability platform specifically designed for LLM applications. The Langfuse exporter sends your traces to Langfuse, providing detailed insights into model performance and token usage, plus conversation flows.
 
 ## Installation
 
@@ -222,7 +222,7 @@ Notes:
 
 ## Prompt linking
 
-You can link LLM generations to prompts stored in [Langfuse Prompt Management](https://langfuse.com/docs/prompt-management). This enables version tracking and metrics for your prompts.
+You can link LLM generations to prompts stored in [Langfuse Prompt Management](https://langfuse.com/docs/prompt-management). It enables version tracking and metrics for your prompts.
 
 ### Using the Helper (Recommended)
 
@@ -242,7 +242,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'support-agent',
   instructions: prompt.compile(), // Use the prompt text from Langfuse
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   defaultGenerateOptions: {
     tracingOptions: buildTracingOptions(
       withLangfusePrompt({ name: prompt.name, version: prompt.version }),

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

@@ -2,7 +2,7 @@
 
 # LangSmith exporter
 
-[LangSmith](https://smith.langchain.com/) is LangChain's platform for monitoring and evaluating LLM applications. The LangSmith exporter sends your traces to LangSmith, providing insights into model performance, debugging capabilities, and evaluation workflows.
+[LangSmith](https://smith.langchain.com/) is LangChain's platform for monitoring and evaluating LLM applications. The LangSmith exporter sends your traces to LangSmith, providing insights into model performance and debugging capabilities, plus evaluation workflows.
 
 ## Installation
 
@@ -130,7 +130,7 @@ The `projectName` config option takes precedence over the `LANGCHAIN_PROJECT` en
 
 ## Dynamic configuration
 
-You can dynamically override LangSmith settings per-span using `withLangsmithMetadata`. This is useful for routing traces to different projects based on runtime conditions (e.g., customer, environment, or feature).
+You can override at runtime LangSmith settings per-span using `withLangsmithMetadata`. This is useful for routing traces to different projects based on runtime conditions (e.g., customer, environment, or feature).
 
 ### Using the Helper
 
@@ -145,7 +145,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'support-agent',
   instructions: 'You are a helpful support agent.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   defaultOptions: {
     tracingOptions: buildTracingOptions(withLangsmithMetadata({ projectName: 'customer-support' })),
   },
@@ -165,7 +165,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'support-agent',
   instructions: 'You are a helpful support agent.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   defaultOptions: ({ requestContext }) => {
     const userTier = requestContext?.get('user-tier') as string
     const userId = requestContext?.get('user-id') as string

package/.docs/docs/observability/integrations/exporters/mastra-platform.md

@@ -14,7 +14,7 @@ The `MastraPlatformExporter` sends traces, logs, metrics, scores, and feedback t
 
 ## Version compatibility
 
-- `MastraPlatformExporter` is available starting in `@mastra/observability@1.12.0`. In `1.8.0` through `1.11.x` the same exporter ships only as `CloudExporter`; the constructor signature and environment variables are identical.
+- `MastraPlatformExporter` is available starting in `@mastra/observability@1.12.0`. In `1.8.0` through `1.11.x` the same exporter includes only as `CloudExporter`. The constructor signature and environment variables are identical.
 - In `@mastra/observability@1.8.0` through `1.9.1`, set `MASTRA_PLATFORM_OBSERVABILITY_ENDPOINT=https://observability.mastra.ai` in addition to `MASTRA_PLATFORM_ACCESS_TOKEN` and `MASTRA_PROJECT_ID`.
 - Starting in `@mastra/observability@1.9.2`, the exporter defaults to `https://observability.mastra.ai`, so `MASTRA_PLATFORM_OBSERVABILITY_ENDPOINT` is only required when you want to send telemetry to a different collector.
 

package/.docs/docs/observability/integrations/exporters/mastra-storage.md

@@ -171,7 +171,7 @@ For both batch strategies (`batch-with-updates` and `insert-only`), traces are f
 
 ### Error handling
 
-The MastraStorageExporter includes robust error handling for production use:
+The MastraStorageExporter includes reliable error handling for production use:
 
 - **Retry Logic**: Exponential backoff (500ms, 1s, 2s, 4s)
 - **Transient Failures**: Automatic retry with backoff

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

@@ -2,7 +2,7 @@
 
 # OpenTelemetry exporter
 
-The OpenTelemetry (OTEL) exporter sends your traces and logs to any OTEL-compatible observability platform using standardized [OpenTelemetry Semantic Conventions for GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/). This ensures broad compatibility with platforms like Datadog, New Relic, SigNoz, MLflow, Latitude, Dash0, Traceloop, Laminar, and more.
+The OpenTelemetry (OTEL) exporter sends your traces and logs to any OTEL-compatible observability platform using standardized [OpenTelemetry Semantic Conventions for GenAI](https://opentelemetry.io/docs/specs/semconv/gen-ai/). This ensures broad compatibility with platforms like Datadog, New Relic, SigNoz, MLflow, Latitude, Dash0, Traceloop, Laminar, telemetry.dev, and more.
 
 > **Looking for bidirectional OTEL integration?:** If you have existing OpenTelemetry instrumentation and want Mastra traces to inherit context from active OTEL spans, see the [OpenTelemetry Bridge](https://mastra.ai/docs/observability/integrations/bridges/otel) instead.
 
@@ -10,7 +10,7 @@ The OpenTelemetry (OTEL) exporter sends your traces and logs to any OTEL-compati
 
 Each provider requires specific protocol packages. Install the base exporter plus the protocol package for your provider:
 
-### For HTTP/Protobuf Providers (SigNoz, New Relic, Laminar, MLflow, Latitude)
+### For HTTP/Protobuf Providers (SigNoz, New Relic, Laminar, MLflow, Latitude, telemetry.dev)
 
 **npm**:
 
@@ -104,7 +104,7 @@ All providers support zero-config setup via environment variables. Set the appro
 
 ### MLflow
 
-[MLflow](https://mlflow.org/docs/latest/genai/tracing/integrations/listing/mastra) supports native Mastra tracing through its OTLP endpoint at `/v1/traces`. Use the `custom` provider with HTTP/Protobuf and include the experiment header so traces land in the correct MLflow experiment:
+[MLflow](https://mlflow.org/docs/latest/genai/tracing/integrations/listing/mastra) supports native Mastra tracing through its OTLP endpoint at `/v1/traces`. Use the `custom` provider with HTTP/Protobuf and include the experiment header so traces are routed to the correct MLflow experiment:
 
 ```typescript
 new OtelExporter({
@@ -141,6 +141,28 @@ new OtelExporter({
 
 Sign up at [console.latitude.so](https://console.latitude.so/login), or self-host and point the endpoint at your own ingestion host.
 
+### telemetry.dev
+
+[telemetry.dev](https://telemetry.dev) ingests OTLP/HTTP protobuf traces and normalizes OpenTelemetry GenAI semantic conventions into model, provider, token, latency, and cost fields. Use the `custom` provider with your project API key:
+
+```bash
+TELEMETRY_DEV_API_KEY=td_live_...
+```
+
+```typescript
+new OtelExporter({
+  provider: {
+    custom: {
+      endpoint: 'https://ingest.telemetry.dev/v1/traces',
+      protocol: 'http/protobuf',
+      headers: {
+        Authorization: `Bearer ${process.env.TELEMETRY_DEV_API_KEY}`,
+      },
+    },
+  },
+})
+```
+
 ### Dash0
 
 [Dash0](https://www.dash0.com/) provides real-time observability with automatic insights.
@@ -245,7 +267,7 @@ new OtelExporter({
 
 ### New Relic
 
-[New Relic](https://newrelic.com/) provides comprehensive observability with AI monitoring capabilities.
+[New Relic](https://newrelic.com/) provides complete observability with AI monitoring capabilities.
 
 #### Zero-Config Setup