@mastra/mcp-docs-server 0.13.39 → 1.0.0-beta.0

package/.docs/raw/guides/migrations/upgrade-to-v1/mastra.mdx

@@ -0,0 +1,171 @@
+---
+title: "Mastra Class | v1 Migration Guide"
+description: "Learn how to migrate Mastra class changes when upgrading to v1."
+---
+
+# Mastra Class
+
+The Mastra class has been restructured to restrict top-level imports and replace direct property access with getter methods.
+
+## Changed
+
+### Top-level imports to subpath imports
+
+The main `@mastra/core` index file now only exports `Mastra` and `Config`. All other exports have been moved to subpath imports. This change improves tree-shaking and reduces bundle size by allowing bundlers to eliminate unused code.
+
+To migrate, update all imports from `@mastra/core` to use the appropriate subpath.
+
+```diff
+- import { Mastra, Agent, Workflow, createTool } from '@mastra/core';
++ import { Mastra, type Config } from '@mastra/core';
++ import { Agent } from '@mastra/core/agent';
++ import { Workflow } from '@mastra/core/workflows';
++ import { createTool } from '@mastra/core/tools';
+```
+
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod v1/mastra-core-imports .
+```
+
+:::
+
+### `experimental_auth` to `auth`
+
+The experimental auth configuration has been promoted to stable. This change reflects that the auth API is now stable and production-ready.
+
+To migrate, rename the `experimental_auth` key to `auth` in your Mastra configuration.
+
+```diff
+  const mastra = new Mastra({
+-   experimental_auth: {
++   auth: {
+      provider: workos,
+    },
+  });
+```
+
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod v1/experimental-auth .
+```
+
+:::
+
+### Required `id` parameter for all mastra primitives
+
+All storage, vector stores, agents, workflows, mcpServers, processors, scorers, tools now require an `id` parameter during initialization. This enables the standardized Mastra API and prevents ID conflicts.
+
+All these primitives also now have a `get`, `list`, and `add` functions.
+
+To migrate, add an `id` parameter to all storage and vector store instantiations. When using the same storage/vector class multiple times, ensure each instance has a unique ID.
+
+```diff
+- const storage = new LibSQLStore({
+-   url: ':memory:',
+- });
++ const storage = new LibSQLStore({
++   id: 'my-app-storage',
++   url: ':memory:',
++ });
+
+- const vector = new PgVector({
+-   connectionString: process.env.DATABASE_URL,
+- });
++ const vector = new PgVector({
++   id: 'my-app-vector',
++   connectionString: process.env.DATABASE_URL,
++ });
+```
+
+When using separate instances for different purposes, use descriptive unique IDs:
+
+```diff
+  const agentMemory = new Memory({
+    storage: new LibSQLStore({
+-     url: 'file:./agent.db',
++     id: 'weather-agent-memory-storage',
++     url: 'file:./agent.db',
+    }),
+  });
+
+  const mastra = new Mastra({
+    storage: new LibSQLStore({
++     id: 'mastra-storage',
+      url: ':memory:',
+    }),
+  });
+```
+
+### Primitive plural APIs changes from `get<primitives>` to `list<primitive>`
+
+```diff
+- const mcpServers = mastra.getMCPServers();
++ const mcpServers = mastra.listMCPServers();
+```
+
+### Each primtive has a `getById` and a `get` function
+
+```typescript
+mastra.getMCPServer('myServer');          // Works (registry key)
+mastra.getMCPServerById('my-mcp-server'); // Works (intrinsic ID)
+```
+
+### Tool registration now uses intrinsic IDs
+
+When tools are auto-registered from agents or MCP servers to the Mastra instance, they now use the tool's intrinsic `id` instead of the configuration object key. This prevents collisions when multiple agents/MCP servers have tools with the same configuration key.
+
+To migrate, update any code that references tools by their configuration keys to use the tool's intrinsic ID instead.
+
+```diff
+  const agent = new Agent({
+    id: 'agent1',
+    tools: {
+      searchTool: weatherSearchTool,
+    },
+  });
+
+- mastra.getTool('searchTool');
++ mastra.getTool(weatherSearchTool.id);
+```
+
+## Removed
+
+### `memory` property from Mastra class
+
+The `memory` property has been removed from the Mastra class. Memory is now configured at the Agent level rather than globally.
+
+To migrate, move memory configuration from the Mastra constructor to individual Agent constructors.
+
+```diff
+- const mastra = new Mastra({
+-   memory: new Memory({
+-     storage: libsqlStore,
+-     vector: libsqlVector,
+-     embedder: fastembed,
+-   }),
+- });
+- 
+- const agent = new Agent({
+-   name: 'my-agent',
+- });
+
++ const mastra = new Mastra({
++   // memory removed from here
++ });
++ 
++ const agent = new Agent({
++   name: 'my-agent',
++   memory: new Memory({
++     storage: libsqlStore,
++     vector: libsqlVector,
++     embedder: fastembed,
++   }),
++ });
+```

package/.docs/raw/guides/migrations/upgrade-to-v1/mcp.mdx

@@ -0,0 +1,114 @@
+---
+title: "MCP | v1 Migration Guide"
+description: "Learn how to migrate MCP-related changes when upgrading to v1."
+---
+
+# MCP
+
+MCP (Model Context Protocol) tool execution context has been reorganized, and deprecated client classes have been removed.
+
+## Changed
+
+### `getMCPServers` to `listMCPServers`
+
+The `mastra.getMCPServers()` method has been renamed to `mastra.listMCPServers()`. This change aligns with the naming convention used across the API where plural getter methods use the `list` prefix.
+
+To migrate, replace all calls to `mastra.getMCPServers()` with `mastra.listMCPServers()`.
+
+```diff
+- const servers = await mastra.getMCPServers();
++ const servers = await mastra.listMCPServers();
+```
+
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod v1/mcp-get-mcp-servers .
+```
+
+:::
+
+### `getTools` to `listTools`
+
+The `mcp.getTools()` method has been renamed to `mcp.listTools()`. This change aligns with the naming convention used across the API where plural getter methods use the `list` prefix.
+
+To migrate, replace all calls to `mcp.getTools()` with `mcp.listTools()`.
+
+```diff
+- const tools = await mcp.getTools();
++ const tools = await mcp.listTools();
+```
+
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod v1/mcp-get-tools .
+```
+
+:::
+
+### `getToolsets` to `listToolsets`
+
+The `mcp.getToolsets()` method has been renamed to `mcp.listToolsets()`. This change aligns with the naming convention used across the API where plural getter methods use the `list` prefix.
+
+To migrate, replace all calls to `mcp.getToolsets()` with `mcp.listToolsets()`.
+
+```diff
+- const toolsets = await mcp.getToolsets();
++ const toolsets = await mcp.listToolsets();
+```
+
+:::tip[Codemod]
+
+You can use Mastra's codemod CLI to update your code automatically:
+
+```shell
+npx @mastra/codemod v1/mcp-get-toolsets .
+```
+
+:::
+
+### MCP tool context properties organization
+
+Context properties in MCP tools are now organized under the `context.mcp` namespace. This change provides better organization and clearer API surface for MCP-specific functionality.
+
+To migrate, access MCP-specific properties like `elicitation` and `extra` through `context.mcp` instead of directly from the context parameter.
+
+```diff
+  createTool({
+    id: 'account-balance',
+-   execute: async ({ context, elicitation, extra }) => {
+-     await checkAuth(extra.authInfo);
+-     const result = await elicitation.sendRequest({
+-       message: `Is it ok to fetch account ${context.accountId}?`,
+-     });
+-   },
++   execute: async (inputData, context) => {
++     await checkAuth(context?.mcp?.extra.authInfo);
++     const result = await context?.mcp?.elicitation.sendRequest({
++       message: `Is it ok to fetch account ${inputData.accountId}?`,
++     });
++   },
+  });
+```
+
+## Removed
+
+### Deprecated MCP client classes
+
+The `MastraMCPClient` and related deprecated APIs have been removed from `@mastra/mcp`. This change consolidates on the new MCP client API.
+
+To migrate, use the new `MCPClient` class instead of deprecated classes.
+
+```diff
+- import { MastraMCPClient, MCPConfiguration } from '@mastra/mcp/client';
++ import { MCPClient } from '@mastra/mcp/client';
+
+- const client = new MastraMCPClient({ ... });
+- const config = new MCPConfiguration({ ... });
++ const client = new MCPClient({ ... });
+```

package/.docs/raw/guides/migrations/upgrade-to-v1/memory.mdx

@@ -0,0 +1,241 @@
+---
+title: "Memory | v1 Migration Guide"
+description: "Learn how to migrate memory-related changes when upgrading to v1."
+---
+
+# Memory
+
+Memory configuration now requires explicit parameters, and default settings have been updated for better performance and predictability.
+
+## Changed
+
+### Default settings for semantic recall and last messages
+
+Default settings have changed to more reasonable values based on usage patterns. The `lastMessages` default decreased from 40 to 10, `semanticRecall` is now disabled by default, and thread title generation is disabled by default. These changes improve performance and reduce unexpected LLM API calls.
+
+To migrate, if you were relying on the old defaults, explicitly configure these settings.
+
+```diff
+  const memory = new Memory({
+    storage,
+    vector,
+    embedder,
++   options: {
++     lastMessages: 40, // Was default before
++     semanticRecall: {
++       topK: 2,
++       messageRange: 2,
++       scope: 'thread',
++     }, // Was enabled by default before
++     generateTitle: true, // Was enabled by default before
++   },
+  });
+```
+
+### Default memory scope from `thread` to `resource`
+
+The default scope for both working memory and semantic recall has changed from `'thread'` to `'resource'`. This change aligns with common use cases where applications want to remember user information across conversations. When semantic recall is enabled, it now defaults to searching across all user conversations rather than just the current thread.
+
+To migrate, if you want to maintain the old behavior where memory is isolated per conversation thread, explicitly set `scope: 'thread'`.
+
+```diff
+  const memory = new Memory({
+    storage,
+    vector,
+    embedder,
+    options: {
+      workingMemory: {
+        enabled: true,
++       scope: 'thread', // Explicitly set to thread-scoped
+        template: `# User Profile...`,
+      },
+      semanticRecall: {
+        topK: 3,
++       scope: 'thread', // Explicitly set to thread-scoped
+      },
+    },
+  });
+```
+
+### Thread title generation location
+
+The `generateTitle` option has been moved from `threads.generateTitle` to the top-level of memory options. This change simplifies the API by moving the option to where it logically belongs.
+
+To migrate, move `generateTitle` from the `threads` config to the top level of options.
+
+```diff
+  const memory = new Memory({
+    storage,
+    vector,
+    embedder,
+    options: {
+-     threads: {
+-       generateTitle: true,
+-     },
++     generateTitle: true,
+    },
+  });
+```
+
+### Semantic recall default settings optimization
+
+The default settings for semantic recall have been optimized based on RAG research. The `topK` increased from 2 to 4, and `messageRange` changed from `{ before: 2, after: 2 }` to `{ before: 1, after: 1 }`. These changes provide better accuracy while only slightly increasing message count.
+
+To migrate, if you were relying on the previous defaults, explicitly set these values.
+
+```diff
+  const memory = new Memory({
+    storage,
+    vector,
+    embedder,
+    options: {
+      semanticRecall: {
++       topK: 2, // Was default before
++       messageRange: { before: 2, after: 2 }, // Was default before
+      },
+    },
+  });
+```
+
+### `Memory.query()` renamed to `Memory.recall()`
+
+The `Memory.query()` method has been renamed to `Memory.recall()`. The new method returns a simpler format with just `{ messages: MastraDBMessage[] }` instead of multiple format variations. This change better describes the action of retrieving messages from memory and simplifies the API.
+
+To migrate, rename `query()` to `recall()` and update code that expects the old return format.
+
+```diff
+- const result = await memory.query({ threadId: 'thread-123' });
++ const result = await memory.recall({ threadId: 'thread-123' });
+- // result: { messages: CoreMessage[], uiMessages: UIMessageWithMetadata[], messagesV2: MastraMessageV2[] }
++ // result: { messages: MastraDBMessage[] }
++ const messages = result.messages;
+```
+
+### `Memory.recall()` parameter changes
+
+The `Memory.recall()` method now uses `StorageListMessagesInput` format with pagination, and the `vectorMessageSearch` parameter has been renamed to `vectorSearchString`. These changes align the memory API with the storage pagination API and provide more consistent naming.
+
+To migrate, update method name, query parameters, and the vector search parameter.
+
+```diff
+- memory.query({
++ memory.recall({
+    threadId: 'thread-123',
+-   vectorMessageSearch: 'What did we discuss?',
+-   selectBy: { ... },
++   vectorSearchString: 'What did we discuss?',
++   page: 0,
++   perPage: 20,
++   orderBy: 'createdAt',
++   filter: { ... },
++   threadConfig: { semanticRecall: true },
+  });
+```
+
+### `MastraMessageV2` type renamed to `MastraDBMessage`
+
+The `MastraMessageV2` type has been renamed to `MastraDBMessage` for clarity. This change better describes the purpose of this type as the database message format.
+
+To migrate, replace all instances of `MastraMessageV2` with `MastraDBMessage`.
+
+```diff
+- import { MastraMessageV2 } from '@mastra/core';
+- function yourCustomFunction(input: MastraMessageV2) {}
++ import { MastraDBMessage } from '@mastra/core';
++ function yourCustomFunction(input: MastraDBMessage) {}
+```
+
+
+
+## Removed
+
+### Working memory `text-stream` mode
+
+Working memory `use: "text-stream"` option has been removed. Only `tool-call` mode is supported. This change simplifies the working memory API by removing the less reliable streaming mode.
+
+To migrate, remove the `use: "text-stream"` option. Working memory will default to tool-call mode.
+
+```diff
+  const memory = new Memory({
+    storage,
+    vector,
+    embedder,
+    options: {
+      workingMemory: {
+        enabled: true,
+-       use: 'text-stream',
+        template: '...',
+      },
+    },
+  });
+```
+
+### `Memory.rememberMessages()` method
+
+The `Memory.rememberMessages()` method has been removed. This method performed the same function as `query()` (now `recall()`), and consolidating to one method simplifies the API.
+
+To migrate, replace `rememberMessages()` calls with `recall()`.
+
+```diff
+- const { messages } = await memory.rememberMessages({
++ const { messages } = await memory.recall({
+    threadId,
+    resourceId,
+  });
+```
+
+### `format` parameter from memory methods
+
+The `format` parameter has been removed from all memory get methods. `MastraDBMessage` is now the default return format everywhere. AI SDK format conversion has moved to dedicated utility functions in `@mastra/ai-sdk/ui`. This change improves tree-shaking by moving UI-specific conversion code to a separate package.
+
+To migrate, remove the `format` parameter and use conversion functions for AI SDK formats.
+
+```diff
+- const messages = await memory.getMessages({ threadId, format: 'v2' });
+- const uiMessages = await memory.getMessages({ threadId, format: 'ui' });
+
++ const result = await memory.recall({ threadId });
++ const messages = result.messages; // Always MastraDBMessage[]
++ 
++ // Use conversion functions for AI SDK formats
++ import { toAISdkV5Messages } from '@mastra/ai-sdk/ui';
++ const uiMessages = toAISdkV5Messages(messages);
+```
+
+### `MastraMessageV3` type
+
+The `MastraMessageV3` type and related conversion methods have been removed. Messages now convert directly between `MastraMessageV2` (now `MastraDBMessage`) and AI SDK v5 formats. This change simplifies the architecture by removing an intermediary format.
+
+To migrate, use `MastraDBMessage` for storage or AI SDK v5 message formats directly.
+
+```diff
+- import type { MastraMessageV3 } from '@mastra/core/agent';
+- const v3Messages = messageList.get.all.v3();
+
++ // For storage
++ const v2Messages = messageList.get.all.v2();
++ 
++ // For AI SDK v5
++ const uiMessages = messageList.get.all.aiV5.ui();
++ const modelMessages = messageList.get.all.aiV5.model();
+```
+
+### `processors` config from Memory constructor
+
+The `processors` config option in the Memory constructor has been deprecated and now throws an error. Processors should be configured at the Agent level instead. This change provides clearer configuration boundaries and better encapsulation.
+
+To migrate, move processor configuration from Memory to Agent.
+
+```diff
+  const memory = new Memory({
+    storage,
+    vector,
+    embedder,
+-   processors: [/* ... */],
+  });
+  
+  const agent = new Agent({
+    memory,
++   processors: [/* ... */],
+  });
+```

package/.docs/raw/guides/migrations/upgrade-to-v1/overview.mdx

@@ -0,0 +1,83 @@
+---
+title: "Overview | v1 Migration Guide"
+description: "Overview of breaking changes when upgrading to Mastra v1."
+---
+
+# Upgrade to Mastra v1
+
+This guide provides a comprehensive overview of breaking changes when upgrading from Mastra 0.x to v1.0. The migration is organized by package and feature area to help you systematically update your codebase.
+
+:::tip[Need help?]
+Need help with the migration? Join our [Discord community](https://discord.gg/BTYqqHKUrf) to ask questions.
+:::
+
+## Migration Strategy
+
+### Update all Mastra packages
+
+Use your package manager to update your project's versions. Be sure to update **all** Mastra packages at the same time to ensure compatibility.
+
+### Update Node.js version
+
+Mastra v1 requires Node.js 22.13.0 or higher. Update your development and production environments accordingly.
+
+## Breaking Changes by Area
+
+- **[Mastra Class]/guides/v1/migrations/upgrade-to-v1/mastra)** - Import restructuring and property access changes.
+- **[Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)** - Voice methods moved to namespace and streaming API updates.
+- **[Tools]/guides/v1/migrations/upgrade-to-v1/tools)** - CreateTool execute signature changed to separate input and context.
+- **[Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)** - Function name changes and legacy features removed.
+- **[Memory]/guides/v1/migrations/upgrade-to-v1/memory)** - Configuration now requires explicit parameters and defaults changed.
+- **[Storage]/guides/v1/migrations/upgrade-to-v1/storage)** - Pagination standardized and methods renamed to list pattern.
+- **[Vectors]/guides/v1/migrations/upgrade-to-v1/vectors)** - Vector store methods renamed to list pattern.
+- **[MCP]/guides/v1/migrations/upgrade-to-v1/mcp)** - Tool context reorganized and deprecated client classes removed.
+- **[Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)** - OTEL telemetry replaced with dedicated observability package and exporters.
+- **[Evals & Scorers]/guides/v1/migrations/upgrade-to-v1/evals)** - Scorers API consolidated with new naming conventions.
+- **[CLI]/guides/v1/migrations/upgrade-to-v1/cli)** - Commands and flags removed for simpler interface.
+- **[Client SDKs]/guides/v1/migrations/upgrade-to-v1/client)** - Types and utilities renamed for consistency.
+- **[Voice Packages]/guides/v1/migrations/upgrade-to-v1/voice)** - Packages renamed from speech to voice.
+
+## Migration Checklist
+
+Work through this checklist in order, starting with high-impact changes that affect most applications.
+
+:::info[Codemod]
+
+We prepared automated [codemods](https://github.com/mastra-ai/mastra/tree/main/packages/codemod) for you. Throughout the migration guide you'll find instructions on how to use them for specific changes.
+
+If you want, you can run all v1 codemods at once:
+
+```sh
+npx @mastra/codemod v1
+```
+
+:::
+
+### High Impact Changes
+
+- Update `createTool` tool signatures to `(inputData, context)` format - [Tools]/guides/v1/migrations/upgrade-to-v1/tools)
+- Restructure `@mastra/core` imports to use subpath imports - [Mastra Class]/guides/v1/migrations/upgrade-to-v1/mastra)
+- Update pagination from `offset/limit` to `page/perPage` - [Storage]/guides/v1/migrations/upgrade-to-v1/storage)
+- Install `@mastra/observability` and wrap configuration with `new Observability()` - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
+- Migrate from `telemetry:` to `observability:` configuration (if upgrading from 0.x OTEL) - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
+
+### Medium Impact Changes
+
+- Rename `RuntimeContext` to `RequestContext` throughout codebase - [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent), [Tools]/guides/v1/migrations/upgrade-to-v1/tools), [Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)
+- Update storage methods from `get*` to `list*` pattern - [Storage]/guides/v1/migrations/upgrade-to-v1/storage)
+- Replace direct property access with getter methods - [Mastra Class]/guides/v1/migrations/upgrade-to-v1/mastra), [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)
+- Update memory scope if relying on default `thread` scope - [Memory]/guides/v1/migrations/upgrade-to-v1/memory)
+- Update vector store calls to use named arguments - [Storage]/guides/v1/migrations/upgrade-to-v1/storage)
+- Remove `format` parameter from agent methods - [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)
+- Update voice methods to use `agent.voice` namespace - [Agent Class]/guides/v1/migrations/upgrade-to-v1/agent)
+- Rename configuration property `processors` to `spanOutputProcessors` (if using custom processors) - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)
+
+### Low Impact Changes
+
+- Rename `createRunAsync` to `createRun` - [Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)
+- Update voice package names from `@mastra/speech-*` to `@mastra/voice-*` - [Voice Packages]/guides/v1/migrations/upgrade-to-v1/voice)
+- Update scorer methods: `runExperiment` → `runEvals`, `getScorerByName` → `getScorerById` - [Evals & Scorers]/guides/v1/migrations/upgrade-to-v1/evals)
+- Remove deprecated CLI flags - [CLI]/guides/v1/migrations/upgrade-to-v1/cli)
+- Update client SDK types from `Get*` to `List*` - [Client SDKs]/guides/v1/migrations/upgrade-to-v1/client)
+- Replace `runCount` with `retryCount` - [Workflows]/guides/v1/migrations/upgrade-to-v1/workflows)
+- Update custom exporter method `exportEvent` to `exportTracingEvent` (if using custom exporters) - [Tracing]/guides/v1/migrations/upgrade-to-v1/tracing)

package/.docs/raw/guides/migrations/upgrade-to-v1/processors.mdx

@@ -0,0 +1,62 @@
+---
+title: "Processors | v1 Migration Guide"
+description: "Learn how to migrate processor changes when upgrading to v1."
+---
+
+# Processors
+
+Processor interfaces have been updated to use consistent naming patterns and database message types.
+
+## Changed
+
+### Processor configuration from `name` to `id`
+
+Processors now require an `id` field instead of `name`. The `name` field is now optional. This change provides consistency with other Mastra entities like scorers and agents.
+
+To migrate, update processor definitions to use `id` as the required field.
+
+```diff
+  import type { InputProcessor } from '@mastra/core/processors';
+
+  const processor: InputProcessor = {
+-   name: 'my-processor',
++   id: 'my-processor',
++   name: 'My Processor', // optional
+    processInput: async ({ messages }) => {
+      // ...
+    },
+  };
+```
+
+### Processor message types from `MastraMessageV2` to `MastraDBMessage`
+
+Processor message types have changed from `MastraMessageV2` to `MastraDBMessage`. This change provides consistency with scorer configuration and better type safety by aligning with the database message format.
+
+To migrate, update processor message type imports and usage.
+
+```diff
+  import type { InputProcessor } from '@mastra/core/processors';
+- import type { MastraMessageV2 } from '@mastra/core/agent';
++ import type { MastraDBMessage } from '@mastra/core/agent';
+
+  const processor: InputProcessor = {
+    id: 'my-processor',
+-   processInput: async ({ messages }: { messages: MastraMessageV2[] }) => {
++   processInput: async ({ messages }: { messages: MastraDBMessage[] }) => {
+      // ...
+    },
+  };
+```
+
+## Removed
+
+### Deprecated input processor exports
+
+Deprecated input-processor exports which include the built-in processors have been removed from `@mastra/core/agent/input-processors/processors`. Use `@mastra/core/processors` instead. This change consolidates processor types under the unified `Processor` interface.
+
+If you have used `InputProcessor`, replace it with `Processor` which implements a `processInput` function.
+
+```diff
+- import { InputProcessor, ModerationProcessor } from '@mastra/core/agent/input-processors/processors';
++ import { Processor, ModerationProcessor } from '@mastra/core/processors';
+```