@mastra/mcp-docs-server 1.0.0-beta.9 → 1.0.1

package/.docs/raw/memory/semantic-recall.mdx

@@ -1,26 +1,31 @@
 ---
 title: "Semantic Recall | Memory"
 description: "Learn how to use semantic recall in Mastra to retrieve relevant messages from past conversations using vector search and embeddings."
+packages:
+  - "@mastra/core"
+  - "@mastra/fastembed"
+  - "@mastra/libsql"
+  - "@mastra/memory"
+  - "@mastra/pg"
 ---
 
 # Semantic Recall
 
 If you ask your friend what they did last weekend, they will search in their memory for events associated with "last weekend" and then tell you what they did. That's sort of like how semantic recall works in Mastra.
 
-> **📹 Watch**: What semantic recall is, how it works, and how to configure it in Mastra → [YouTube (5 minutes)](https://youtu.be/UVZtK8cK8xQ)
+:::tip[Watch 📹]
+
+What semantic recall is, how it works, and how to configure it in Mastra → [YouTube (5 minutes)](https://youtu.be/UVZtK8cK8xQ)
+
+:::
 
 ## How Semantic Recall Works
 
-Semantic recall is RAG-based search that helps agents maintain context across longer interactions when messages are no longer within [recent conversation history](./conversation-history).
+Semantic recall is RAG-based search that helps agents maintain context across longer interactions when messages are no longer within [recent message history](./message-history).
 
 It uses vector embeddings of messages for similarity search, integrates with various vector stores, and has configurable context windows around retrieved messages.
 
-<br />
-<img
-  src="/img/semantic-recall.png"
-  alt="Diagram showing Mastra Memory semantic recall"
-  width={800}
-/>
+![Diagram showing Mastra Memory semantic recall](/img/semantic-recall.png)
 
 When it's enabled, new messages are used to query a vector DB for semantically similar messages.
 
@@ -30,7 +35,7 @@ After getting a response from the LLM, all new messages (user, assistant, and to
 
 Semantic recall is enabled by default, so if you give your agent memory it will be included:
 
-```typescript {8}
+```typescript {9}
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
 
@@ -43,33 +48,11 @@ const agent = new Agent({
 });
 ```
 
-## Recall configuration
-
-The three main parameters that control semantic recall behavior are:
-
-1. **topK**: How many semantically similar messages to retrieve
-2. **messageRange**: How much surrounding context to include with each match
-3. **scope**: Whether to search within the current thread or across all threads owned by a resource (the default is resource scope).
-
-```typescript {5-7}
-const agent = new Agent({
-  memory: new Memory({
-    options: {
-      semanticRecall: {
-        topK: 3, // Retrieve 3 most similar messages
-        messageRange: 2, // Include 2 messages before and after each match
-        scope: "resource", // Search across all threads for this user (default setting if omitted)
-      },
-    },
-  }),
-});
-```
-
-### Storage configuration
+## Storage configuration
 
 Semantic recall relies on a [storage and vector db](/reference/v1/memory/memory-class) to store messages and their embeddings.
 
-```ts {8-17}
+```ts {8-16}
 import { Memory } from "@mastra/memory";
 import { Agent } from "@mastra/core/agent";
 import { LibSQLStore, LibSQLVector } from "@mastra/libsql";
@@ -84,20 +67,55 @@ const agent = new Agent({
     // this is the default vector db if omitted
     vector: new LibSQLVector({
       id: 'agent-vector',
-      connectionUrl: "file:./local.db",
+      url: "file:./local.db",
     }),
   }),
 });
 ```
 
-**Storage/vector code Examples**:
+Each vector store page below includes installation instructions, configuration parameters, and usage examples:
+
+- [Astra](/reference/v1/vectors/astra)
+- [Chroma](/reference/v1/vectors/chroma)
+- [Cloudflare Vectorize](/reference/v1/vectors/vectorize)
+- [Convex](/reference/v1/vectors/convex)
+- [Couchbase](/reference/v1/vectors/couchbase)
+- [DuckDB](/reference/v1/vectors/duckdb)
+- [Elasticsearch](/reference/v1/vectors/elasticsearch)
+- [LanceDB](/reference/v1/vectors/lance)
+- [libSQL](/reference/v1/vectors/libsql)
+- [MongoDB](/reference/v1/vectors/mongodb)
+- [OpenSearch](/reference/v1/vectors/opensearch)
+- [Pinecone](/reference/v1/vectors/pinecone)
+- [PostgreSQL](/reference/v1/vectors/pg)
+- [Qdrant](/reference/v1/vectors/qdrant)
+- [S3 Vectors](/reference/v1/vectors/s3vectors)
+- [Turbopuffer](/reference/v1/vectors/turbopuffer)
+- [Upstash](/reference/v1/vectors/upstash)
+
+## Recall configuration
 
-- [LibSQL](/docs/v1/memory/storage/memory-with-libsql)
-- [MongoDB](/docs/v1/memory/storage/memory-with-mongodb)
-- [Postgres](/docs/v1/memory/storage/memory-with-pg)
-- [Upstash](/docs/v1/memory/storage/memory-with-upstash)
+The three main parameters that control semantic recall behavior are:
 
-### Embedder configuration
+1. **topK**: How many semantically similar messages to retrieve
+2. **messageRange**: How much surrounding context to include with each match
+3. **scope**: Whether to search within the current thread or across all threads owned by a resource (the default is resource scope).
+
+```typescript {5-7}
+const agent = new Agent({
+  memory: new Memory({
+    options: {
+      semanticRecall: {
+        topK: 3, // Retrieve 3 most similar messages
+        messageRange: 2, // Include 2 messages before and after each match
+        scope: "resource", // Search across all threads for this user (default setting if omitted)
+      },
+    },
+  }),
+});
+```
+
+## Embedder configuration
 
 Semantic recall relies on an [embedding model](/reference/v1/memory/memory-class) to convert messages into embeddings. Mastra supports embedding models through the model router using `provider/model` strings, or you can use any [embedding model](https://sdk.vercel.ai/docs/ai-sdk-core/embeddings) compatible with the AI SDK.
 
@@ -112,7 +130,6 @@ import { ModelRouterEmbeddingModel } from "@mastra/core/llm";
 
 const agent = new Agent({
   memory: new Memory({
-    // ... other memory options
     embedder: new ModelRouterEmbeddingModel("openai/text-embedding-3-small"),
   }),
 });
@@ -136,7 +153,6 @@ import { ModelRouterEmbeddingModel } from "@mastra/core/llm";
 
 const agent = new Agent({
   memory: new Memory({
-    // ... other memory options
     embedder: new ModelRouterEmbeddingModel("openai/text-embedding-3-small"),
   }),
 });
@@ -146,32 +162,31 @@ const agent = new Agent({
 
 To use FastEmbed (a local embedding model), install `@mastra/fastembed`:
 
-```bash npm2yarn copy
+```bash npm2yarn
 npm install @mastra/fastembed@beta
 ```
 
 Then configure it in your memory:
 
-```ts {3,8}
+```ts {3,7}
 import { Memory } from "@mastra/memory";
 import { Agent } from "@mastra/core/agent";
 import { fastembed } from "@mastra/fastembed";
 
 const agent = new Agent({
   memory: new Memory({
-    // ... other memory options
     embedder: fastembed,
   }),
 });
 ```
 
-### PostgreSQL Index Optimization
+## PostgreSQL Index Optimization
 
 When using PostgreSQL as your vector store, you can optimize semantic recall performance by configuring the vector index. This is particularly important for large-scale deployments with thousands of messages.
 
 PostgreSQL supports both IVFFlat and HNSW indexes. By default, Mastra creates an IVFFlat index, but HNSW indexes typically provide better performance, especially with OpenAI embeddings which use inner product distance.
 
-```typescript {9-18}
+```typescript {18-23}
 import { Memory } from "@mastra/memory";
 import { PgStore, PgVector } from "@mastra/pg";
 
@@ -203,7 +218,7 @@ const agent = new Agent({
 
 For detailed information about index configuration options and performance tuning, see the [PgVector configuration guide](/reference/v1/vectors/pg#index-configuration-guide).
 
-### Disabling
+## Disabling
 
 There is a performance impact to using semantic recall. New messages are converted into embeddings and used to query a vector database before new messages are sent to the LLM.
 
@@ -221,11 +236,9 @@ const agent = new Agent({
 
 You might want to disable semantic recall in scenarios like:
 
-- When conversation history provide sufficient context for the current conversation.
+- When message history provides sufficient context for the current conversation.
 - In performance-sensitive applications, like realtime two-way audio, where the added latency of creating embeddings and running vector queries is noticeable.
 
 ## Viewing Recalled Messages
 
-When tracing is enabled, any messages retrieved via semantic recall will appear in the agent’s trace output, alongside recent conversation history (if configured).
-
-For more info on viewing message traces, see [Viewing Retrieved Messages](./overview#viewing-retrieved-messages).
+When tracing is enabled, any messages retrieved via semantic recall will appear in the agent's trace output, alongside recent message history (if configured).

package/.docs/raw/memory/storage.mdx

@@ -0,0 +1,248 @@
+---
+title: "Storage | Memory"
+description: Configure storage for Mastra's memory system to persist conversations, workflows, and traces.
+packages:
+  - "@mastra/core"
+  - "@mastra/libsql"
+  - "@mastra/memory"
+  - "@mastra/pg"
+  - "@mastra/pinecone"
+---
+
+# Storage
+
+For Mastra to remember previous interactions, you must configure a storage adapter. Mastra is designed to work with your preferred database provider - choose from the [supported providers](#supported-providers) and pass it to your Mastra instance.
+
+
+```typescript title="src/mastra/index.ts"
+import { Mastra } from "@mastra/core";
+import { LibSQLStore } from "@mastra/libsql";
+
+export const mastra = new Mastra({
+  storage: new LibSQLStore({
+    id: 'mastra-storage',
+    url: "file:./mastra.db",
+  }),
+});
+```
+On first interaction, Mastra automatically creates the necessary tables following the [core schema](/reference/v1/storage/overview#core-schema). This includes tables for messages, threads, resources, workflows, traces, and evaluation datasets.
+
+## Supported providers
+
+Each provider page includes installation instructions, configuration parameters, and usage examples:
+
+- [libSQL Storage](/reference/v1/storage/libsql)
+- [PostgreSQL Storage](/reference/v1/storage/postgresql)
+- [MongoDB Storage](/reference/v1/storage/mongodb)
+- [Upstash Storage](/reference/v1/storage/upstash)
+- [Cloudflare D1](/reference/v1/storage/cloudflare-d1)
+- [Cloudflare Durable Objects](/reference/v1/storage/cloudflare)
+- [Convex](/reference/v1/storage/convex)
+- [DynamoDB](/reference/v1/storage/dynamodb)
+- [LanceDB](/reference/v1/storage/lance)
+- [Microsoft SQL Server](/reference/v1/storage/mssql)
+
+:::tip
+libSQL is the easiest way to get started because it doesn’t require running a separate database server
+:::
+
+## Configuration scope
+
+You can configure storage at two different scopes:
+
+### Instance-level storage
+
+Add storage to your Mastra instance so all agents, workflows, observability traces and scores share the same memory provider:
+
+```typescript
+import { Mastra } from "@mastra/core";
+import { PostgresStore } from "@mastra/pg";
+
+export const mastra = new Mastra({
+  storage: new PostgresStore({
+    id: 'mastra-storage',
+    connectionString: process.env.DATABASE_URL,
+  }),
+});
+
+// All agents automatically use this storage
+const agent1 = new Agent({ id: "agent-1", memory: new Memory() });
+const agent2 = new Agent({ id: "agent-2", memory: new Memory() });
+```
+
+This is useful when all primitives share the same storage backend and have similar performance, scaling, and operational requirements.
+
+#### Composite storage
+
+Add storage to your Mastra instance using `MastraCompositeStore` and configure individual storage domains to use different storage providers.
+
+```typescript title="src/mastra/index.ts"
+import { Mastra } from "@mastra/core";
+import { MastraCompositeStore } from "@mastra/core/storage";
+import { MemoryLibSQL } from "@mastra/libsql";
+import { WorkflowsPG } from "@mastra/pg";
+import { ObservabilityStorageClickhouse } from "@mastra/clickhouse";
+
+export const mastra = new Mastra({
+  storage: new MastraCompositeStore({
+    id: "composite",
+    domains: {
+      memory: new MemoryLibSQL({ url: "file:./memory.db" }),
+      workflows: new WorkflowsPG({ connectionString: process.env.DATABASE_URL }),
+      observability: new ObservabilityStorageClickhouse({
+        url: process.env.CLICKHOUSE_URL,
+        username: process.env.CLICKHOUSE_USERNAME,
+        password: process.env.CLICKHOUSE_PASSWORD,
+      }),
+    },
+  }),
+});
+```
+
+This is useful when different types of data have different performance or operational requirements, such as low-latency storage for memory, durable storage for workflows, and high-throughput storage for observability.
+
+:::info
+See [Storage Domains](/reference/v1/storage/composite#storage-domains) for more information.
+:::
+
+### Agent-level storage
+
+Agent-level storage overrides storage configured at the instance-level. Add storage to a specific agent when you need data boundaries or compliance requirements:
+
+```typescript title="src/mastra/agents/memory-agent.ts"
+import { Agent } from "@mastra/core/agent";
+import { Memory } from "@mastra/memory";
+import { PostgresStore } from "@mastra/pg";
+
+export const agent = new Agent({
+  id: "agent",
+  memory: new Memory({
+    storage: new PostgresStore({
+      id: 'agent-storage',
+      connectionString: process.env.AGENT_DATABASE_URL,
+    }),
+  }),
+});
+```
+
+This is useful when different agents need to store data in separate databases for security, compliance, or organizational reasons.
+
+:::warning[Mastra Cloud Store limitation]
+Agent-level storage is not supported when using [Mastra Cloud Store](/docs/v1/mastra-cloud/deployment#using-mastra-cloud-store). If you use Mastra Cloud Store, configure storage on the Mastra instance instead. This limitation does not apply if you bring your own database.
+:::
+
+## Threads and resources
+
+Mastra organizes memory into threads using two identifiers:
+
+- **Thread**: A conversation session containing a sequence of messages (e.g., `convo_123`)
+- **Resource**: An identifier for the entity the thread belongs to, typically a user (e.g., `user_123`)
+
+Both identifiers are required for agents to store and recall information:
+
+```typescript
+const stream = await agent.stream("message for agent", {
+  memory: {
+    thread: "convo_123",
+    resource: "user_123",
+  },
+});
+```
+
+:::note
+[Studio](/docs/v1/getting-started/studio) automatically generates a thread and resource ID for you. Remember to  to pass these explicitly when calling `stream` or `generate` yourself.
+:::
+
+### Thread and resource relationship
+
+Each thread has an owner (its `resourceId`) that is set when the thread is created and cannot be changed. When you query a thread, you must use the correct owner's resource ID. Attempting to query a thread with a different resource ID will result in an error:
+
+```text
+Thread with id <thread_id> is for resource with id <resource_a>
+but resource <resource_b> was queried
+```
+
+Note that while each thread has one owner, messages within that thread can have different `resourceId` values. This is used for message attribution and filtering (e.g., distinguishing between different agents in a multi-agent system, or filtering messages for analytics).
+
+**Security:** Memory is a storage layer, not an authorization layer. Your application must implement access control before calling memory APIs. The `resourceId` parameter controls both validation and filtering - provide it to validate ownership and filter messages, or omit it for server-side access without validation.
+
+To avoid accidentally reusing thread IDs across different owners, use UUIDs: `crypto.randomUUID()`
+
+### Thread title generation
+
+Mastra can automatically generate descriptive thread titles based on the user's first message.
+
+Use this option when implementing a ChatGPT-style chat interface to render a title alongside each thread in the conversation list (for example, in a sidebar) derived from the thread’s initial user message.
+
+```typescript
+export const testAgent = new Agent({
+  id: "test-agent",
+  memory: new Memory({
+    options: {
+      generateTitle: true,
+    },
+  }),
+});
+```
+
+Title generation runs asynchronously after the agent responds and does not affect response time.
+
+To optimize cost or behavior, provide a smaller `model` and custom `instructions`:
+
+```typescript
+export const testAgent = new Agent({
+  id: "test-agent",
+  memory: new Memory({
+    options: {
+      generateTitle: {
+        model: "openai/gpt-4o-mini",
+        instructions: "Generate a concise title based on the user's first message",
+      },
+    },
+  }),
+});
+```
+
+## Semantic recall
+
+Semantic recall uses vector embeddings to retrieve relevant past messages based on meaning rather than recency. This requires a vector database instance, which can be configured at the instance or agent level.
+
+The vector database doesn't have to be the same as your storage provider. For example, you might use PostgreSQL for storage and Pinecone for vectors:
+
+```typescript
+import { Mastra } from "@mastra/core";
+import { Agent } from "@mastra/core/agent";
+import { Memory } from "@mastra/memory";
+import { PostgresStore } from "@mastra/pg";
+import { PineconeVector } from "@mastra/pinecone";
+
+// Instance-level vector configuration
+export const mastra = new Mastra({
+  storage: new PostgresStore({
+    id: 'mastra-storage',
+    connectionString: process.env.DATABASE_URL,
+  }),
+});
+
+// Agent-level vector configuration
+export const agent = new Agent({
+  id: "agent",
+  memory: new Memory({
+    vector: new PineconeVector({
+      id: 'agent-vector',
+      apiKey: process.env.PINECONE_API_KEY,
+    }),
+    options: {
+      semanticRecall: {
+        topK: 5,
+        messageRange: 2,
+      },
+    },
+  }),
+});
+```
+
+We support all popular vector providers including [Pinecone](/reference/v1/vectors/pinecone), [Chroma](/reference/v1/vectors/chroma), [Qdrant](/reference/v1/vectors/qdrant), and many more.
+
+For more information on configuring semantic recall, see the [Semantic Recall](./semantic-recall) documentation.
+

package/.docs/raw/memory/working-memory.mdx

@@ -1,13 +1,20 @@
 ---
 title: "Working Memory | Memory"
 description: "Learn how to configure working memory in Mastra to store persistent user data, preferences."
+packages:
+  - "@mastra/core"
+  - "@mastra/libsql"
+  - "@mastra/memory"
+  - "@mastra/mongodb"
+  - "@mastra/pg"
+  - "@mastra/upstash"
 ---
 
 import YouTube from "@site/src/components/YouTube-player";
 
 # Working Memory
 
-While [conversation history](/docs/v1/memory/conversation-history) and [semantic recall](./semantic-recall) help agents remember conversations, working memory allows them to maintain persistent information about users across interactions.
+While [message history](/docs/v1/memory/message-history) and [semantic recall](./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.
 
@@ -24,7 +31,7 @@ Working memory can persist at two different scopes:
 
 Here's a minimal example of setting up an agent with working memory:
 
-```typescript {11-14}
+```typescript {11-15}
 import { Agent } from "@mastra/core/agent";
 import { Memory } from "@mastra/memory";
 
@@ -85,13 +92,15 @@ const memory = new Memory({
 
 ### Usage with Agents
 
-When using resource-scoped memory, make sure to pass the `resourceId` parameter:
+When using resource-scoped memory, make sure to pass the `resource` parameter in the memory options:
 
 ```typescript
-// Resource-scoped memory requires resourceId
+// Resource-scoped memory requires resource
 const response = await agent.generate("Hello!", {
-  threadId: "conversation-123",
-  resourceId: "user-alice-456", // Same user across different threads
+  memory: {
+    thread: "conversation-123",
+    resource: "user-alice-456", // Same user across different threads
+  },
 });
 ```
 
@@ -126,9 +135,9 @@ const memory = new Memory({
 
 Resource-scoped working memory requires specific storage adapters that support the `mastra_resources` table:
 
-### ✅ Supported Storage Adapters
+### Supported Storage Adapters
 
-- **LibSQL** (`@mastra/libsql`)
+- **libSQL** (`@mastra/libsql`)
 - **PostgreSQL** (`@mastra/pg`)
 - **Upstash** (`@mastra/upstash`)
 - **MongoDB** (`@mastra/mongodb`)
@@ -325,7 +334,7 @@ While agents typically update working memory through the `updateWorkingMemory` t
 
 When creating a thread, you can provide initial working memory through the metadata's `workingMemory` key:
 
-```typescript title="src/app/medical-consultation.ts" showLineNumbers copy
+```typescript title="src/app/medical-consultation.ts"
 // Create a thread with initial working memory
 const thread = await memory.createThread({
   threadId: "thread-123",
@@ -344,8 +353,10 @@ const thread = await memory.createThread({
 
 // The agent will now have access to this information in all messages
 await agent.generate("What's my blood type?", {
-  threadId: thread.id,
-  resourceId: "user-456",
+  memory: {
+    thread: thread.id,
+    resource: "user-456",
+  },
 });
 // Response: "Your blood type is O+."
 ```
@@ -354,7 +365,7 @@ await agent.generate("What's my blood type?", {
 
 You can also update an existing thread's working memory:
 
-```typescript title="src/app/medical-consultation.ts" showLineNumbers copy
+```typescript title="src/app/medical-consultation.ts"
 // Update thread metadata to add/modify working memory
 await memory.updateThread({
   id: "thread-123",
@@ -376,7 +387,7 @@ await memory.updateThread({
 
 Alternatively, use the `updateWorkingMemory` method directly:
 
-```typescript title="src/app/medical-consultation.ts" showLineNumbers copy
+```typescript title="src/app/medical-consultation.ts"
 await memory.updateWorkingMemory({
   threadId: "thread-123",
   resourceId: "user-456", // Required for resource-scoped memory

package/.docs/raw/observability/logging.mdx

@@ -1,24 +1,26 @@
 ---
 title: "Logging | Observability"
 description: Learn how to use logging in Mastra to monitor execution, capture application behavior, and improve the accuracy of AI applications.
+packages:
+  - "@mastra/core"
+  - "@mastra/loggers"
 ---
 
 # Logging
 
 Mastra's logging system captures function execution, input data, and output responses in a structured format.
 
-When deploying to Mastra Cloud, logs are shown on the [Logs](/docs/v1/deployment/mastra-cloud/observability) page. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
+When deploying to Mastra Cloud, logs are shown on the [Logs](/docs/v1/mastra-cloud/observability) page. In self-hosted or custom environments, logs can be directed to files or external services depending on the configured transports.
 
 ## Configuring logs with PinoLogger
 
 When [initializing a new Mastra project](/guides/v1/getting-started/quickstart) using the CLI, `PinoLogger` is included by default.
 
-```typescript title="src/mastra/index.ts" showLineNumbers copy
+```typescript title="src/mastra/index.ts"
 import { Mastra } from "@mastra/core/mastra";
 import { PinoLogger } from "@mastra/loggers";
 
 export const mastra = new Mastra({
-  // ...
   logger: new PinoLogger({
     name: "Mastra",
     level: "info",
@@ -26,7 +28,11 @@ export const mastra = new Mastra({
 });
 ```
 
-> See the [PinoLogger](/reference/v1/logging/pino-logger) API reference for all available configuration options.
+:::info
+
+Visit [PinoLogger](/reference/v1/logging/pino-logger) for all available configuration options.
+
+:::
 
 ## Customizing logs
 
@@ -36,14 +42,12 @@ Mastra provides access to a logger instance via the `mastra.getLogger()` method,
 
 Within a workflow step, access the logger via the `mastra` parameter inside the `execute` function. This allows you to log messages relevant to the step’s execution.
 
-```typescript {8-9} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {6-7} title="src/mastra/workflows/test-workflow.ts"
 import { createWorkflow, createStep } from "@mastra/core/workflows";
 import { z } from "zod";
 
 const step1 = createStep({
-  //...
   execute: async ({ mastra }) => {
-
     const logger = mastra.getLogger();
     logger.info("workflow info log");
 
@@ -62,14 +66,13 @@ export const testWorkflow = createWorkflow({...})
 
 Similarly, tools have access to the logger instance via the `mastra` parameter. Use this to log tool specific activity during execution.
 
-```typescript {8-9} title="src/mastra/tools/test-tool.ts" showLineNumbers copy
+```typescript {6-7} title="src/mastra/tools/test-tool.ts"
 import { createTool } from "@mastra/core/tools";
 import { z } from "zod";
 
 export const testTool = createTool({
-  // ...
-  execute: async ({ mastra }) => {
-    const logger = mastra?.getLogger();
+  execute: async (inputData, context) => {
+    const logger = context?.mastra.getLogger();
     logger?.info("tool info log");
 
     return {
@@ -85,17 +88,15 @@ Logger methods accept an optional second argument for additional data. This can
 
 In this example, the log message includes an object with a key of `agent` and a value of the `testAgent` instance.
 
-```typescript {11} title="src/mastra/workflows/test-workflow.ts" showLineNumbers copy
+```typescript {9} title="src/mastra/workflows/test-workflow.ts"
 import { createWorkflow, createStep } from "@mastra/core/workflows";
 import { z } from "zod";
 
 const step1 = createStep({
-  //...
   execute: async ({ mastra }) => {
-
     const testAgent = mastra.getAgent("testAgent");
-
     const logger = mastra.getLogger();
+    
     logger.info("workflow info log", { agent: testAgent });
 
     return {