@mastra/core 1.15.0-alpha.0 → 1.15.0-alpha.2

package/dist/docs/references/docs-agents-processors.md

@@ -7,7 +7,7 @@ Processors are configured as:
 - **`inputProcessors`**: Run before messages reach the language model.
 - **`outputProcessors`**: Run after the language model generates a response, but before it's returned to users.
 
-You can use individual `Processor` objects or compose them into workflows using Mastra's workflow primitives. Workflows give you advanced control over processor execution order, parallel processing, and conditional logic.
+You can use individual [`Processor`](https://mastra.ai/reference/processors/processor-interface) objects or compose them into workflows using Mastra's workflow primitives. Workflows give you advanced control over processor execution order, parallel processing, and conditional logic.
 
 Some processors implement both input and output logic and can be used in either array depending on where the transformation should occur.
 
@@ -26,7 +26,7 @@ Use processors to:
 
 Mastra includes several processors for common use cases. You can also create custom processors for application-specific requirements.
 
-## Adding processors to an agent
+## Quickstart
 
 Import and instantiate the processor, then pass it to the agent's `inputProcessors` or `outputProcessors` array:
 
@@ -81,27 +81,20 @@ Your processors run first, then memory persists messages.
 
 This ordering ensures that if your output guardrail calls `abort()`, memory processors are skipped and no messages are saved. See [Memory Processors](https://mastra.ai/docs/memory/memory-processors) for details.
 
-## Creating custom processors
+## Create custom processors
 
 Custom processors implement the `Processor` interface:
 
-### Custom input processor
+### Transform input messages
 
 ```typescript
-import type { Processor, MastraDBMessage, RequestContext } from '@mastra/core'
+import type { Processor, ProcessInputArgs } from '@mastra/core/processors'
+import type { MastraDBMessage } from '@mastra/core/memory'
 
 export class CustomInputProcessor implements Processor {
   id = 'custom-input'
 
-  async processInput({
-    messages,
-    systemMessages,
-    context,
-  }: {
-    messages: MastraDBMessage[]
-    systemMessages: CoreMessage[]
-    context: RequestContext
-  }): Promise<MastraDBMessage[]> {
+  async processInput({ messages }: ProcessInputArgs): Promise<MastraDBMessage[]> {
     // Transform messages before they reach the LLM
     return messages.map(msg => ({
       ...msg,
@@ -114,58 +107,20 @@ export class CustomInputProcessor implements Processor {
 }
 ```
 
-The `processInput` method receives:
+The `processInput()` method receives `messages`, `systemMessages`, and an `abort()` function. Return a `MastraDBMessage[]` to replace messages, or `{ messages, systemMessages }` to also modify system messages.
 
-- `messages`: User and assistant messages (not system messages)
-- `systemMessages`: All system messages (agent instructions, memory context, user-provided system prompts)
-- `messageList`: The full MessageList instance for advanced use cases
-- `abort`: Function to stop processing and return early
-- `requestContext`: Execution metadata like `threadId` and `resourceId`
+See the [`Processor` reference](https://mastra.ai/reference/processors/processor-interface) for all available arguments and return types.
 
-The method can return:
+### Control each step
 
-- `MastraDBMessage[]` — Transformed messages array (backward compatible)
-- `{ messages: MastraDBMessage[]; systemMessages: CoreMessage[] }` — Both messages and modified system messages
-
-The framework handles both return formats, so modifying system messages is optional and existing processors continue to work.
-
-### Modifying system messages
-
-To modify system messages (e.g., trim verbose prompts for smaller models), return an object with both `messages` and `systemMessages`:
+While `processInput()` runs once at the start of agent execution, `processInputStep()` runs at **each step** of the agentic loop (including tool call continuations). This enables per-step configuration changes like dynamic model switching or tool choice modifications.
 
 ```typescript
-import type { Processor, CoreMessage, MastraDBMessage } from '@mastra/core'
-
-export class SystemTrimmer implements Processor {
-  id = 'system-trimmer'
-
-  async processInput({
-    messages,
-    systemMessages,
-  }): Promise<{ messages: MastraDBMessage[]; systemMessages: CoreMessage[] }> {
-    // Trim system messages for smaller models
-    const trimmedSystemMessages = systemMessages.map(msg => ({
-      ...msg,
-      content: typeof msg.content === 'string' ? msg.content.substring(0, 500) : msg.content,
-    }))
-
-    return { messages, systemMessages: trimmedSystemMessages }
-  }
-}
-```
-
-This is useful for:
-
-- Trimming verbose system prompts for models with smaller context windows
-- Filtering or modifying semantic recall content to prevent "prompt too long" errors
-- Dynamically adjusting system instructions based on the conversation
-
-### Per-step processing with `processInputStep`
-
-While `processInput` runs once at the start of agent execution, `processInputStep` runs at **each step** of the agentic loop (including tool call continuations). This enables per-step configuration changes like dynamic model switching or tool choice modifications.
-
-```typescript
-import type { Processor, ProcessInputStepArgs, ProcessInputStepResult } from '@mastra/core'
+import type {
+  Processor,
+  ProcessInputStepArgs,
+  ProcessInputStepResult,
+} from '@mastra/core/processors'
 
 export class DynamicModelProcessor implements Processor {
   id = 'dynamic-model'
@@ -192,100 +147,13 @@ export class DynamicModelProcessor implements Processor {
 }
 ```
 
-The `processInputStep` method receives:
-
-- `stepNumber`: Current step in the agentic loop (0-indexed)
-- `steps`: Results from previous steps
-- `messages`: Current messages snapshot (read-only)
-- `systemMessages`: Current system messages (read-only)
-- `messageList`: The full MessageList instance for mutations
-- `model`: Current model being used
-- `tools`: Current tools available for this step
-- `toolChoice`: Current tool choice setting
-- `activeTools`: Currently active tools
-- `providerOptions`: Provider-specific options
-- `modelSettings`: Model settings like temperature
-- `structuredOutput`: Structured output configuration
-
-The method can return any combination of:
-
-- `model`: Change the model for this step
-- `tools`: Replace or add tools (use spread to merge: `{ tools: { ...tools, newTool } }`)
-- `toolChoice`: Change tool selection behavior
-- `activeTools`: Filter which tools are available
-- `messages`: Replace messages (applied to messageList)
-- `systemMessages`: Replace all system messages
-- `providerOptions`: Modify provider options
-- `modelSettings`: Modify model settings
-- `structuredOutput`: Modify structured output configuration
-
-#### Ensuring a final response with `maxSteps`
-
-When using `maxSteps` to limit agent execution, the agent may return an empty response if it attempts a tool call on the final step. Use `processInputStep` to force a text response on the last step:
-
-```typescript
-import { Processor, ProcessInputStepArgs, ProcessInputStepResult } from '@mastra/core/processors'
+The method receives the current `stepNumber`, `model`, `tools`, `toolChoice`, `messages`, and more. Return an object with any properties you want to override for that step, for example `{ model, toolChoice, tools, systemMessages }`.
 
-export class EnsureFinalResponseProcessor implements Processor {
-  readonly id = 'ensure-final-response'
+See the [`Processor` reference](https://mastra.ai/reference/processors/processor-interface) for all available arguments and return types.
 
-  private maxSteps: number
+### Use the `prepareStep()` callback
 
-  constructor(maxSteps: number) {
-    this.maxSteps = maxSteps
-  }
-
-  async processInputStep({
-    stepNumber,
-    systemMessages,
-  }: ProcessInputStepArgs): Promise<ProcessInputStepResult> {
-    // On the last step, prevent tool calls and instruct the LLM to summarize
-    if (stepNumber === this.maxSteps - 1) {
-      return {
-        tools: {},
-        toolChoice: 'none',
-        systemMessages: [
-          ...systemMessages,
-          {
-            role: 'system',
-            content:
-              'You have reached the maximum number of steps. Summarize your progress so far and provide a best-effort response. If the task is incomplete, clearly indicate what remains to be done.',
-          },
-        ],
-      }
-    }
-    return {}
-  }
-}
-```
-
-Use it with your agent:
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { EnsureFinalResponseProcessor } from '../processors/ensure-final-response'
-
-const MAX_STEPS = 5
-
-const agent = new Agent({
-  id: 'bounded-agent',
-  name: 'Bounded Agent',
-  model: 'openai/gpt-5-mini',
-  tools: {
-    /* your tools */
-  },
-  inputProcessors: [new EnsureFinalResponseProcessor(MAX_STEPS)],
-})
-
-// Pass maxSteps when calling generate/stream
-const result = await agent.generate('Your prompt', { maxSteps: MAX_STEPS })
-```
-
-This ensures that on the final allowed step (step 4 when `maxSteps` is 5, since steps are 0-indexed), the LLM generates a summary instead of attempting another tool call, and clearly indicates if the task is incomplete.
-
-#### Using `prepareStep` callback
-
-For simpler per-step logic, you can use the `prepareStep` callback on `generate()` or `stream()` instead of creating a full processor:
+The `prepareStep()` callback on `generate()` or `stream()` is a shorthand for `processInputStep()`. Internally, Mastra wraps it in a processor that calls your function at each step. It accepts the same arguments and return type as `processInputStep()`, but doesn't require creating a class:
 
 ```typescript
 await agent.generate('Complex task', {
@@ -300,10 +168,11 @@ await agent.generate('Complex task', {
 })
 ```
 
-### Custom output processor
+### Transform output messages
 
 ```typescript
-import type { Processor, MastraDBMessage, ChunkType } from '@mastra/core'
+import type { Processor } from '@mastra/core/processors'
+import type { MastraDBMessage } from '@mastra/core/memory'
 
 export class CustomOutputProcessor implements Processor {
   id = 'custom-output'
@@ -312,6 +181,35 @@ export class CustomOutputProcessor implements Processor {
     // Transform messages after the LLM generates them
     return messages.filter(msg => msg.role !== 'system')
   }
+}
+```
+
+The method also receives a `result` object with the full generation data — `text`, `usage` (token counts), `finishReason`, and `steps` (each containing `toolCalls`, `toolResults`, etc.). Use it to track usage or inspect tool calls:
+
+```typescript
+import type { Processor } from '@mastra/core/processors'
+
+export class UsageTracker implements Processor {
+  id = 'usage-tracker'
+
+  async processOutputResult({ messages, result }) {
+    console.log(`Tokens: ${result.usage.inputTokens} in, ${result.usage.outputTokens} out`)
+    console.log(`Finish reason: ${result.finishReason}`)
+    return messages
+  }
+}
+```
+
+### Filter streamed output
+
+The `processOutputStream()` method transforms or filters streaming chunks before they reach the client:
+
+```typescript
+import type { Processor } from '@mastra/core/processors'
+import type { ChunkType } from '@mastra/core/stream'
+
+export class StreamFilter implements Processor {
+  id = 'stream-filter'
 
   async processOutputStream({ part }): Promise<ChunkType | null> {
     // Transform or filter streaming chunks
@@ -320,42 +218,132 @@ export class CustomOutputProcessor implements Processor {
 }
 ```
 
-The `processOutputStream` method receives all streaming chunks. To also receive custom `data-*` chunks emitted by tools via `writer.custom()`, set `processDataParts = true` on your processor. This lets you inspect, modify, or block tool-emitted data chunks before they reach the client.
+To also receive custom `data-*` chunks emitted by tools via `writer.custom()`, set `processDataParts = true` on your processor. This lets you inspect, modify, or block tool-emitted data chunks before they reach the client.
 
-#### Accessing generation result data
+### Validate each response
 
-The `processOutputResult` method receives a `result` object containing the resolved generation data — the same information available in the `onFinish` callback. This lets you access token usage, generated text, finish reason, and step details.
+The `processOutputStep()` method runs after each LLM step, allowing you to validate the response and optionally request a retry:
 
 ```typescript
-import type { Processor } from '@mastra/core'
+import type { Processor } from '@mastra/core/processors'
 
-export class UsageTracker implements Processor {
-  id = 'usage-tracker'
+export class ResponseValidator implements Processor {
+  id = 'response-validator'
 
-  async processOutputResult({ messages, result }) {
-    console.log(`Text: ${result.text}`)
-    console.log(`Tokens: ${result.usage.inputTokens} in, ${result.usage.outputTokens} out`)
-    console.log(`Finish reason: ${result.finishReason}`)
-    console.log(`Steps: ${result.steps.length}`)
+  async processOutputStep({ text, abort, retryCount }) {
+    const isValid = await validateResponse(text)
 
-    // Each step contains toolCalls, toolResults, reasoning, sources, files, etc.
-    for (const step of result.steps) {
-      if (step.toolCalls?.length) {
-        console.log(`Step used ${step.toolCalls.length} tool calls`)
-      }
+    if (!isValid && retryCount < 3) {
+      abort('Response did not meet requirements. Try again.', { retry: true })
     }
 
-    return messages
+    return []
   }
 }
 ```
 
-#### Emitting custom stream events with writer
+For more on retry behavior, see [Retry mechanism](#retry-mechanism) in Advanced patterns.
+
+## Built-in utility processors
+
+Mastra provides utility processors for common tasks:
+
+**For security and validation processors**, see the [Guardrails](https://mastra.ai/docs/agents/guardrails) page for input/output guardrails and moderation processors. **For memory-specific processors**, see the [Memory Processors](https://mastra.ai/docs/memory/memory-processors) page for processors that handle message history, semantic recall, and working memory.
+
+### `TokenLimiter`
+
+Prevents context window overflow by removing older messages when the total token count exceeds a specified limit. Prioritizes recent messages and preserves system messages.
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { TokenLimiter } from '@mastra/core/processors'
+
+const agent = new Agent({
+  name: 'my-agent',
+  model: 'openai/gpt-5.4',
+  inputProcessors: [new TokenLimiter(127000)],
+})
+```
+
+See the [`TokenLimiterProcessor` reference](https://mastra.ai/reference/processors/token-limiter-processor) for custom encoding, strategy, and count mode options.
+
+### `ToolCallFilter`
+
+Removes tool calls and results from messages sent to the LLM, saving tokens on verbose tool interactions. Optionally exclude only specific tools. This filter only affects the LLM input, filtered messages are still saved to memory.
+
+See the [`ToolCallFilter` reference](https://mastra.ai/reference/processors/tool-call-filter) for configuration options and the [Memory Processors](https://mastra.ai/docs/memory/memory-processors) page for pre-memory filtering.
+
+### `ToolSearchProcessor`
+
+Enables dynamic tool discovery for agents with large tool libraries. Instead of providing all tools upfront, the processor gives the agent `search_tools` and `load_tool` meta-tools to find and load tools by keyword on demand, reducing context token usage.
+
+See the [`ToolSearchProcessor` reference](https://mastra.ai/reference/processors/tool-search-processor) for configuration options and usage examples.
+
+## Advanced patterns
+
+### Ensure a final response with `maxSteps`
+
+When using `maxSteps` to limit agent execution, the agent may return an empty response if it attempts a tool call on the final step. Use `processInputStep()` to force a text response on the last step:
+
+```typescript
+import type {
+  Processor,
+  ProcessInputStepArgs,
+  ProcessInputStepResult,
+} from '@mastra/core/processors'
+
+export class EnsureFinalResponseProcessor implements Processor {
+  readonly id = 'ensure-final-response'
+
+  private maxSteps: number
+
+  constructor(maxSteps: number) {
+    this.maxSteps = maxSteps
+  }
+
+  async processInputStep({
+    stepNumber,
+    systemMessages,
+  }: ProcessInputStepArgs): Promise<ProcessInputStepResult> {
+    // On the last step, prevent tool calls and instruct the LLM to summarize
+    if (stepNumber === this.maxSteps - 1) {
+      return {
+        tools: {},
+        toolChoice: 'none',
+        systemMessages: [
+          ...systemMessages,
+          {
+            role: 'system',
+            content:
+              'You have reached the maximum number of steps. Summarize your progress so far and provide a best-effort response. If the task is incomplete, clearly indicate what remains to be done.',
+          },
+        ],
+      }
+    }
+    return {}
+  }
+}
+```
+
+Add it to `inputProcessors` and pass the same `maxSteps` value to `generate()` or `stream()`:
+
+```typescript
+const MAX_STEPS = 5
+
+const agent = new Agent({
+  inputProcessors: [new EnsureFinalResponseProcessor(MAX_STEPS)],
+  // ...
+})
+
+await agent.generate('Your prompt', { maxSteps: MAX_STEPS })
+```
+
+### Emit custom stream events
 
 Output processors receive a `writer` object that lets you emit custom data chunks back to the client during streaming. This is useful for use cases like streaming moderation results or sending UI update signals without blocking the original stream.
 
 ```typescript
-import type { Processor, ChunkType, MastraDBMessage } from '@mastra/core'
+import type { Processor } from '@mastra/core/processors'
 
 export class ModerationProcessor implements Processor {
   id = 'moderation'
@@ -402,12 +390,13 @@ for await (const chunk of stream.fullStream) {
 
 Custom chunk types must use the `data-` prefix (e.g., `data-moderation-update`, `data-status`).
 
-#### Adding metadata in output processors
+### Add metadata to messages
 
 You can add custom metadata to messages in `processOutputResult`. This metadata is accessible via the response object:
 
 ```typescript
-import type { Processor, MastraDBMessage } from '@mastra/core'
+import type { Processor } from '@mastra/core/processors'
+import type { MastraDBMessage } from '@mastra/core/memory'
 
 export class MetadataProcessor implements Processor {
   id = 'metadata-processor'
@@ -447,124 +436,20 @@ const assistantMessage = result.response?.uiMessages?.find(m => m.role === 'assi
 console.log(assistantMessage?.metadata?.customData)
 ```
 
-Access the metadata when streaming:
-
-```typescript
-const stream = await agent.stream('Hello')
-
-for await (const chunk of stream.fullStream) {
-  if (chunk.type === 'finish') {
-    // Access response with processor-added metadata from the finish chunk
-    const uiMessages = chunk.payload.response?.uiMessages
-    const assistantMessage = uiMessages?.find(m => m.role === 'assistant')
-    console.log(assistantMessage?.metadata?.customData)
-  }
-}
-
-// Or via the response promise after consuming the stream
-const response = await stream.response
-console.log(response.uiMessages)
-```
-
-## Built-in utility processors
-
-Mastra provides utility processors for common tasks:
-
-**For security and validation processors**, see the [Guardrails](https://mastra.ai/docs/agents/guardrails) page for input/output guardrails and moderation processors. **For memory-specific processors**, see the [Memory Processors](https://mastra.ai/docs/memory/memory-processors) page for processors that handle message history, semantic recall, and working memory.
-
-### `TokenLimiter`
-
-Prevents context window overflow by removing older messages when the total token count exceeds a specified limit.
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { TokenLimiter } from '@mastra/core/processors'
-
-const agent = new Agent({
-  name: 'my-agent',
-  model: 'openai/gpt-5.4',
-  inputProcessors: [
-    // Ensure the total tokens don't exceed ~127k
-    new TokenLimiter(127000),
-  ],
-})
-```
-
-The `TokenLimiter` uses the `o200k_base` encoding by default. You can specify other encodings for different models:
-
-```typescript
-import cl100k_base from 'js-tiktoken/ranks/cl100k_base'
-
-const agent = new Agent({
-  name: 'my-agent',
-  inputProcessors: [
-    new TokenLimiter({
-      limit: 16000, // Example limit for a 16k context model
-      encoding: cl100k_base,
-    }),
-  ],
-})
-```
-
-### `ToolCallFilter`
-
-Removes tool calls from messages sent to the LLM, saving tokens by excluding potentially verbose tool interactions.
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { ToolCallFilter, TokenLimiter } from '@mastra/core/processors'
-
-const agent = new Agent({
-  name: 'my-agent',
-  model: 'openai/gpt-5.4',
-  inputProcessors: [
-    // Example 1: Remove all tool calls/results
-    new ToolCallFilter(),
-
-    // Example 2: Remove only specific tool calls
-    new ToolCallFilter({ exclude: ['generateImageTool'] }),
-
-    // Always place TokenLimiter last
-    new TokenLimiter(127000),
-  ],
-})
-```
-
-> **Note:** The example above filters tool calls and limits tokens for the LLM, but these filtered messages will still be saved to memory. To also filter messages before they're saved to memory, manually add memory processors before utility processors. See [Memory Processors](https://mastra.ai/docs/memory/memory-processors) for details.
-
-### `ToolSearchProcessor`
-
-Enables dynamic tool discovery and loading for agents with large tool libraries. Instead of providing all tools upfront, the agent searches for tools by keyword and loads them on demand, reducing context token usage.
-
-```typescript
-import { Agent } from '@mastra/core/agent'
-import { ToolSearchProcessor } from '@mastra/core/processors'
-
-const agent = new Agent({
-  name: 'my-agent',
-  model: 'openai/gpt-5.4',
-  inputProcessors: [
-    new ToolSearchProcessor({
-      tools: {
-        createIssue: githubTools.createIssue,
-        sendEmail: emailTools.send,
-        // ... hundreds of tools
-      },
-      search: { topK: 5, minScore: 0.1 },
-    }),
-  ],
-})
-```
-
-The processor gives the agent two meta-tools: `search_tools` to find tools by keyword and `load_tool` to add a tool to the conversation. Loaded tools persist within the thread. See the [ToolSearchProcessor reference](https://mastra.ai/reference/processors/tool-search-processor) for full configuration options.
+For streaming, access metadata from the `finish` chunk payload or the `stream.response` promise.
 
-## Using workflows as processors
+### Use workflows as processors
 
 You can use Mastra workflows as processors to create complex processing pipelines with parallel execution, conditional branching, and error handling:
 
 ```typescript
 import { createWorkflow, createStep } from '@mastra/core/workflows'
-import { ProcessorStepSchema } from '@mastra/core/processors'
+import {
+  ProcessorStepSchema,
+  PromptInjectionDetector,
+  PIIDetector,
+  ModerationProcessor,
+} from '@mastra/core/processors'
 import { Agent } from '@mastra/core/agent'
 
 // Create a workflow that runs multiple checks in parallel
@@ -573,11 +458,26 @@ const moderationWorkflow = createWorkflow({
   inputSchema: ProcessorStepSchema,
   outputSchema: ProcessorStepSchema,
 })
-  .then(createStep(new LengthValidator({ maxLength: 10000 })))
   .parallel([
-    createStep(new PIIDetector({ strategy: 'redact' })),
-    createStep(new ToxicityChecker({ threshold: 0.8 })),
+    createStep(
+      new PIIDetector({
+        strategy: 'redact',
+      }),
+    ),
+    createStep(
+      new PromptInjectionDetector({
+        strategy: 'block',
+      }),
+    ),
+    createStep(
+      new ModerationProcessor({
+        strategy: 'block',
+      }),
+    ),
   ])
+  .map(async ({ inputData }) => {
+    return inputData['processor:pii-detector']
+  })
   .commit()
 
 // Use the workflow as an input processor
@@ -589,14 +489,18 @@ const agent = new Agent({
 })
 ```
 
+After a `.parallel()` step, each branch result is keyed by its processor ID (e.g. `processor:pii-detector`). Use `.map()` to select the branch whose output the next step should receive.
+
+If a branch uses a mutating strategy like `redact`, map to that branch so its transformed messages carry forward. If all branches only `block`, any branch works. Pick any one since none of them modify the messages.
+
 When an agent is registered with Mastra, processor workflows are automatically registered as workflows, allowing you to view and debug them in the [Studio](https://mastra.ai/docs/getting-started/studio).
 
-## Retry mechanism
+### Retry mechanism
 
 Processors can request that the LLM retry its response with feedback. This is useful for implementing quality checks, output validation, or iterative refinement:
 
 ```typescript
-import type { Processor } from '@mastra/core'
+import type { Processor } from '@mastra/core/processors'
 
 export class QualityChecker implements Processor {
   id = 'quality-checker'
@@ -627,14 +531,14 @@ const agent = new Agent({
 
 The retry mechanism:
 
-- Only works in `processOutputStep` and `processInputStep` methods
+- Only works in `processOutputStep()` and `processInputStep()` methods
 - Replays the step with the abort reason added as context for the LLM
 - Tracks retry count via the `retryCount` parameter
 - Respects `maxProcessorRetries` limit on the agent
 
 ## Related documentation
 
-- [Guardrails](https://mastra.ai/docs/agents/guardrails) - Security and validation processors
-- [Memory Processors](https://mastra.ai/docs/memory/memory-processors) - Memory-specific processors and automatic integration
-- [Processor Interface](https://mastra.ai/reference/processors/processor-interface) - Full API reference for processors
-- [ToolSearchProcessor Reference](https://mastra.ai/reference/processors/tool-search-processor) - API reference for dynamic tool search
+- [Guardrails](https://mastra.ai/docs/agents/guardrails): Security and validation processors
+- [Memory Processors](https://mastra.ai/docs/memory/memory-processors): Memory-specific processors and automatic integration
+- [Processor Interface](https://mastra.ai/reference/processors/processor-interface): Full API reference for processors
+- [ToolSearchProcessor Reference](https://mastra.ai/reference/processors/tool-search-processor): API reference for dynamic tool search