@mastra/mcp-docs-server 1.0.0-beta.10 → 1.0.0-beta.13

package/.docs/raw/reference/processors/processor-interface.mdx

@@ -9,7 +9,7 @@ The `Processor` interface defines the contract for all processors in Mastra. Pro
 
 ## When processor methods run
 
-The four processor methods run at different points in the agent execution lifecycle:
+The five processor methods run at different points in the agent execution lifecycle:
 
 ```
 ┌─────────────────────────────────────────────────────────────────┐
@@ -39,6 +39,11 @@ The four processor methods run at different points in the agent execution lifecy
 │  │  └──────────┬───────────┘                               │    │
 │  │             │                                           │    │
 │  │             ▼                                           │    │
+│  │  ┌──────────────────────┐                               │    │
+│  │  │  processOutputStep   │  ← Runs after EACH LLM step   │    │
+│  │  └──────────┬───────────┘                               │    │
+│  │             │                                           │    │
+│  │             ▼                                           │    │
 │  │     Tool Execution (if needed)                          │    │
 │  │             │                                           │    │
 │  │             └──────── Loop back if tools called ────────│    │
@@ -60,6 +65,7 @@ The four processor methods run at different points in the agent execution lifecy
 | `processInput` | Once at the start, before the agentic loop | Validate/transform initial user input, add context |
 | `processInputStep` | At each step of the agentic loop, before each LLM call | Transform messages between steps, handle tool results |
 | `processOutputStream` | On each streaming chunk during LLM response | Filter/modify streaming content, detect patterns in real-time |
+| `processOutputStep` | After each LLM response, before tool execution | Validate output quality, implement guardrails with retry |
 | `processOutputResult` | Once after generation completes | Post-process final response, log results |
 
 ## Interface definition
@@ -70,9 +76,10 @@ interface Processor<TId extends string = string> {
   readonly name?: string;
 
   processInput?(args: ProcessInputArgs): Promise<ProcessInputResult> | ProcessInputResult;
+  processInputStep?(args: ProcessInputStepArgs): ProcessorMessageResult;
   processOutputStream?(args: ProcessOutputStreamArgs): Promise<ChunkType | null | undefined>;
+  processOutputStep?(args: ProcessOutputStepArgs): ProcessorMessageResult;
   processOutputResult?(args: ProcessOutputResultArgs): ProcessorMessageResult;
-  processInputStep?(args: ProcessInputStepArgs): ProcessorMessageResult;
 }
 ```
 
@@ -129,10 +136,16 @@ processInput?(args: ProcessInputArgs): Promise<ProcessInputResult> | ProcessInpu
     },
     {
       name: "abort",
-      type: "(reason?: string) => never",
-      description: "Function to abort processing. Throws a TripWire error that stops execution.",
+      type: "(reason?: string, options?: { retry?: boolean; metadata?: unknown }) => never",
+      description: "Function to abort processing. Throws a TripWire error that stops execution. Pass `retry: true` to request the LLM retry the step with feedback.",
       isOptional: false,
     },
+    {
+      name: "retryCount",
+      type: "number",
+      description: "Number of times processors have triggered retry for this generation. Use this to limit retry attempts.",
+      isOptional: true,
+    },
     {
       name: "tracingContext",
       type: "TracingContext",
@@ -185,8 +198,8 @@ processInputStep?(args: ProcessInputStepArgs): ProcessorMessageResult;
 #### Execution order in the agentic loop
 
 1. `processInput` (once at start)
-2. `processInputStep` (at each step, before LLM call)
-3. `prepareStep` callback (if provided)
+2. `processInputStep` from inputProcessors (at each step, before LLM call)
+3. `prepareStep` callback (runs as part of the processInputStep pipeline, after inputProcessors)
 4. LLM execution
 5. Tool execution (if needed)
 6. Repeat from step 2 if tools were called
@@ -198,13 +211,13 @@ processInputStep?(args: ProcessInputStepArgs): ProcessorMessageResult;
     {
       name: "messages",
       type: "MastraDBMessage[]",
-      description: "All messages including tool calls and results from previous steps.",
+      description: "All messages including tool calls and results from previous steps (read-only snapshot).",
       isOptional: false,
     },
     {
       name: "messageList",
       type: "MessageList",
-      description: "MessageList instance for managing messages.",
+      description: "MessageList instance for managing messages. Can mutate directly or return in result.",
       isOptional: false,
     },
     {
@@ -213,12 +226,60 @@ processInputStep?(args: ProcessInputStepArgs): ProcessorMessageResult;
       description: "Current step number (0-indexed). Step 0 is the initial LLM call.",
       isOptional: false,
     },
+    {
+      name: "steps",
+      type: "StepResult[]",
+      description: "Results from previous steps, including text, toolCalls, and toolResults.",
+      isOptional: false,
+    },
     {
       name: "systemMessages",
       type: "CoreMessage[]",
-      description: "All system messages for read/modify access.",
+      description: "All system messages (read-only snapshot). Return in result to replace.",
       isOptional: false,
     },
+    {
+      name: "model",
+      type: "MastraLanguageModelV2",
+      description: "Current model being used. Return a different model in result to switch.",
+      isOptional: false,
+    },
+    {
+      name: "toolChoice",
+      type: "ToolChoice",
+      description: "Current tool choice setting ('auto', 'none', 'required', or specific tool).",
+      isOptional: true,
+    },
+    {
+      name: "activeTools",
+      type: "string[]",
+      description: "Currently active tool names. Return filtered array to limit tools.",
+      isOptional: true,
+    },
+    {
+      name: "tools",
+      type: "ToolSet",
+      description: "Current tools available for this step. Return in result to add/replace tools.",
+      isOptional: true,
+    },
+    {
+      name: "providerOptions",
+      type: "SharedV2ProviderOptions",
+      description: "Provider-specific options (e.g., Anthropic cacheControl, OpenAI reasoningEffort).",
+      isOptional: true,
+    },
+    {
+      name: "modelSettings",
+      type: "CallSettings",
+      description: "Model settings like temperature, maxTokens, topP.",
+      isOptional: true,
+    },
+    {
+      name: "structuredOutput",
+      type: "StructuredOutputOptions",
+      description: "Structured output configuration (schema, output mode). Return in result to modify.",
+      isOptional: true,
+    },
     {
       name: "abort",
       type: "(reason?: string) => never",
@@ -240,12 +301,99 @@ processInputStep?(args: ProcessInputStepArgs): ProcessorMessageResult;
   ]}
 />
 
+#### ProcessInputStepResult
+
+The method can return any combination of these properties:
+
+<PropertiesTable
+  content={[
+    {
+      name: "model",
+      type: "LanguageModelV2 | string",
+      description: "Change the model for this step. Can be a model instance or router ID like 'openai/gpt-4o'.",
+      isOptional: true,
+    },
+    {
+      name: "toolChoice",
+      type: "ToolChoice",
+      description: "Change tool selection behavior for this step.",
+      isOptional: true,
+    },
+    {
+      name: "activeTools",
+      type: "string[]",
+      description: "Filter which tools are available for this step.",
+      isOptional: true,
+    },
+    {
+      name: "tools",
+      type: "ToolSet",
+      description: "Replace or modify tools for this step. Use spread to merge: { tools: { ...tools, newTool } }.",
+      isOptional: true,
+    },
+    {
+      name: "messages",
+      type: "MastraDBMessage[]",
+      description: "Replace all messages. Cannot be used with messageList.",
+      isOptional: true,
+    },
+    {
+      name: "messageList",
+      type: "MessageList",
+      description: "Return the same messageList instance (indicates you mutated it). Cannot be used with messages.",
+      isOptional: true,
+    },
+    {
+      name: "systemMessages",
+      type: "CoreMessage[]",
+      description: "Replace all system messages for this step only.",
+      isOptional: true,
+    },
+    {
+      name: "providerOptions",
+      type: "SharedV2ProviderOptions",
+      description: "Change provider-specific options for this step.",
+      isOptional: true,
+    },
+    {
+      name: "modelSettings",
+      type: "CallSettings",
+      description: "Change model settings for this step.",
+      isOptional: true,
+    },
+    {
+      name: "structuredOutput",
+      type: "StructuredOutputOptions",
+      description: "Change structured output configuration for this step.",
+      isOptional: true,
+    },
+  ]}
+/>
+
+#### Processor chaining
+
+When multiple processors implement `processInputStep`, they run in order and changes chain through:
+
+```
+Processor 1: receives { model: 'gpt-4o' } → returns { model: 'gpt-4o-mini' }
+Processor 2: receives { model: 'gpt-4o-mini' } → returns { toolChoice: 'none' }
+Final: model = 'gpt-4o-mini', toolChoice = 'none'
+```
+
+#### System message isolation
+
+System messages are **reset to their original values** at the start of each step. Modifications made in `processInputStep` only affect the current step, not subsequent steps.
+
 #### Use cases
 
+- Dynamic model switching based on step number or context
+- Disabling tools after a certain number of steps
+- Dynamically adding or replacing tools based on conversation context
 - Transforming message part types between providers (e.g., `reasoning` → `thinking` for Anthropic)
 - Modifying messages based on step number or accumulated context
-- Implementing per-step message filtering or enrichment
-- Adding step-specific context or instructions
+- Adding step-specific system instructions
+- Adjusting provider options per step (e.g., cache control)
+- Modifying structured output schema based on step context
 
 ---
 
@@ -358,6 +506,125 @@ processOutputResult?(args: ProcessOutputResultArgs): ProcessorMessageResult;
   ]}
 />
 
+---
+
+### processOutputStep
+
+Processes output after each LLM response in the agentic loop, before tool execution. Unlike `processOutputResult` which runs once at the end, this runs at every step. This is the ideal method for implementing guardrails that can trigger retries.
+
+```typescript copy
+processOutputStep?(args: ProcessOutputStepArgs): ProcessorMessageResult;
+```
+
+#### ProcessOutputStepArgs
+
+<PropertiesTable
+  content={[
+    {
+      name: "messages",
+      type: "MastraDBMessage[]",
+      description: "All messages including the latest LLM response.",
+      isOptional: false,
+    },
+    {
+      name: "messageList",
+      type: "MessageList",
+      description: "MessageList instance for managing messages.",
+      isOptional: false,
+    },
+    {
+      name: "stepNumber",
+      type: "number",
+      description: "Current step number (0-indexed).",
+      isOptional: false,
+    },
+    {
+      name: "finishReason",
+      type: "string",
+      description: "The finish reason from the LLM (stop, tool-use, length, etc.).",
+      isOptional: true,
+    },
+    {
+      name: "toolCalls",
+      type: "ToolCallInfo[]",
+      description: "Tool calls made in this step (if any).",
+      isOptional: true,
+    },
+    {
+      name: "text",
+      type: "string",
+      description: "Generated text from this step.",
+      isOptional: true,
+    },
+    {
+      name: "systemMessages",
+      type: "CoreMessage[]",
+      description: "All system messages for read/modify access.",
+      isOptional: true,
+    },
+    {
+      name: "abort",
+      type: "(reason?: string, options?: { retry?: boolean; metadata?: unknown }) => never",
+      description: "Function to abort processing. Pass `retry: true` to request the LLM retry the step.",
+      isOptional: false,
+    },
+    {
+      name: "retryCount",
+      type: "number",
+      description: "Number of times processors have triggered retry. Use this to limit retry attempts.",
+      isOptional: true,
+    },
+    {
+      name: "tracingContext",
+      type: "TracingContext",
+      description: "Tracing context for observability.",
+      isOptional: true,
+    },
+    {
+      name: "requestContext",
+      type: "RequestContext",
+      description: "Request-scoped context with execution metadata.",
+      isOptional: true,
+    },
+  ]}
+/>
+
+#### Use cases
+
+- Implementing quality guardrails that can request retries
+- Validating LLM output before tool execution
+- Adding per-step logging or metrics
+- Implementing output moderation with retry capability
+
+#### Example: Quality guardrail with retry
+
+```typescript title="src/mastra/processors/quality-guardrail.ts" showLineNumbers copy
+import type { Processor } from "@mastra/core";
+
+export class QualityGuardrail implements Processor {
+  id = "quality-guardrail";
+
+  async processOutputStep({ text, abort, retryCount }) {
+    const score = await evaluateResponseQuality(text);
+
+    if (score < 0.7) {
+      if (retryCount < 3) {
+        // Request retry with feedback for the LLM
+        abort("Response quality too low. Please provide more detail.", {
+          retry: true,
+          metadata: { qualityScore: score },
+        });
+      } else {
+        // Max retries reached, block the response
+        abort("Response quality too low after multiple attempts.");
+      }
+    }
+
+    return [];
+  }
+}
+```
+
 ## Processor types
 
 Mastra provides type aliases to ensure processors implement the required methods:
@@ -369,9 +636,10 @@ type InputProcessor = Processor & (
   | { processInputStep: required }
 );
 
-// Must implement processOutputStream OR processOutputResult (or both)
+// Must implement processOutputStream, processOutputStep, OR processOutputResult (or any combination)
 type OutputProcessor = Processor & (
   | { processOutputStream: required }
+  | { processOutputStep: required }
   | { processOutputResult: required }
 );
 ```
@@ -404,13 +672,46 @@ export class LowercaseProcessor implements Processor {
 
 ### Per-step processor with processInputStep
 
+```typescript title="src/mastra/processors/dynamic-model.ts" showLineNumbers copy
+import type { Processor, ProcessInputStepArgs, ProcessInputStepResult } from "@mastra/core";
+
+export class DynamicModelProcessor implements Processor {
+  id = "dynamic-model";
+
+  async processInputStep({
+    stepNumber,
+    steps,
+    toolChoice,
+  }: ProcessInputStepArgs): Promise<ProcessInputStepResult> {
+    // Use a fast model for initial response
+    if (stepNumber === 0) {
+      return { model: "openai/gpt-4o-mini" };
+    }
+
+    // Switch to powerful model after tool calls
+    if (steps.length > 0 && steps[steps.length - 1].toolCalls?.length) {
+      return { model: "openai/gpt-4o" };
+    }
+
+    // Disable tools after 5 steps to force completion
+    if (stepNumber > 5) {
+      return { toolChoice: "none" };
+    }
+
+    return {};
+  }
+}
+```
+
+### Message transformer with processInputStep
+
 ```typescript title="src/mastra/processors/reasoning-transformer.ts" showLineNumbers copy
 import type { Processor, MastraDBMessage } from "@mastra/core";
 
 export class ReasoningTransformer implements Processor {
   id = "reasoning-transformer";
 
-  async processInputStep({ messages, messageList, stepNumber }) {
+  async processInputStep({ messages, messageList }) {
     // Transform reasoning parts to thinking parts at each step
     // This is useful when switching between model providers
     for (const msg of messages) {

package/.docs/raw/reference/rag/database-config.mdx

@@ -348,5 +348,5 @@ const vectorTool = createVectorQueryTool({
 ## Related
 
 - [createVectorQueryTool()](/reference/v1/tools/vector-query-tool)
-- [Hybrid Vector Search](/examples/v1/rag/query/hybrid-vector-search)
+- [Hybrid Vector Search](/docs/v1/rag/retrieval#metadata-filtering)
 - [Metadata Filters](/reference/v1/rag/metadata-filters)

package/.docs/raw/reference/server/create-route.mdx

@@ -325,4 +325,4 @@ Common status codes:
 
 - [Server Routes](/reference/v1/server/routes) - Default Mastra routes
 - [MastraServer](/reference/v1/server/mastra-server) - Server adapter class
-- [Server Adapters](/docs/v1/server-db/server-adapters) - Using adapters
+- [Server Adapters](/docs/v1/server/server-adapters) - Using adapters

package/.docs/raw/reference/server/express-adapter.mdx

@@ -13,7 +13,7 @@ The `@mastra/express` package provides a server adapter for running Mastra with
 
 :::info
 
-For general adapter concepts (constructor options, initialization flow, etc.), see [Server Adapters](/docs/v1/server-db/server-adapters).
+For general adapter concepts (constructor options, initialization flow, etc.), see [Server Adapters](/docs/v1/server/server-adapters).
 
 :::
 
@@ -26,7 +26,7 @@ For general adapter concepts (constructor options, initialization flow, etc.), s
 Install the Express adapter and Express framework:
 
 ```bash copy
-npm install @mastra/express express
+npm install @mastra/express@beta express
 ```
 
 </StepItem>
@@ -246,7 +246,7 @@ app.use((req, res, next) => {
 
 ## Manual initialization
 
-For custom middleware ordering, call each method separately instead of `init()`. See [Server Adapters: Manual initialization](/docs/v1/server-db/server-adapters#manual-initialization) for details.
+For custom middleware ordering, call each method separately instead of `init()`. See [Server Adapters: Manual initialization](/docs/v1/server/server-adapters#manual-initialization) for details.
 
 ## Examples
 
@@ -254,7 +254,7 @@ For custom middleware ordering, call each method separately instead of `init()`.
 
 ## Related
 
-- [Server Adapters](/docs/v1/server-db/server-adapters) - Shared adapter concepts
+- [Server Adapters](/docs/v1/server/server-adapters) - Shared adapter concepts
 - [Hono Adapter](/reference/v1/server/hono-adapter) - Alternative adapter
 - [MastraServer Reference](/reference/v1/server/mastra-server) - Full API reference
 - [createRoute() Reference](/reference/v1/server/create-route) - Creating type-safe custom routes

package/.docs/raw/reference/server/hono-adapter.mdx

@@ -13,7 +13,7 @@ The `@mastra/hono` package provides a server adapter for running Mastra with [Ho
 
 :::info
 
-For general adapter concepts (constructor options, initialization flow, etc.), see [Server Adapters](/docs/v1/server-db/server-adapters).
+For general adapter concepts (constructor options, initialization flow, etc.), see [Server Adapters](/docs/v1/server/server-adapters).
 
 :::
 
@@ -26,7 +26,7 @@ For general adapter concepts (constructor options, initialization flow, etc.), s
 Install the Hono adapter and Hono framework:
 
 ```bash copy
-npm install @mastra/hono hono
+npm install @mastra/hono@beta hono
 ```
 
 </StepItem>
@@ -228,7 +228,7 @@ app.use('*', async (c, next) => {
 
 ## Manual initialization
 
-For custom middleware ordering, call each method separately instead of `init()`. See [Server Adapters: Manual initialization](/docs/v1/server-db/server-adapters#manual-initialization) for details.
+For custom middleware ordering, call each method separately instead of `init()`. See [Server Adapters: Manual initialization](/docs/v1/server/server-adapters#manual-initialization) for details.
 
 ## Examples
 
@@ -236,7 +236,7 @@ For custom middleware ordering, call each method separately instead of `init()`.
 
 ## Related
 
-- [Server Adapters](/docs/v1/server-db/server-adapters) - Shared adapter concepts
+- [Server Adapters](/docs/v1/server/server-adapters) - Shared adapter concepts
 - [Express Adapter](/reference/v1/server/express-adapter) - Alternative adapter
 - [MastraServer Reference](/reference/v1/server/mastra-server) - Full API reference
 - [createRoute() Reference](/reference/v1/server/create-route) - Creating type-safe custom routes

package/.docs/raw/reference/server/mastra-server.mdx

@@ -340,6 +340,6 @@ export class MyServer extends MastraServer<MyApp, MyRequest, MyResponse> {
 
 ## Related
 
-- [Server Adapters](/docs/v1/server-db/server-adapters) - Using adapters
-- [Custom Adapters](/docs/v1/server-db/custom-adapters) - Creating custom adapters
+- [Server Adapters](/docs/v1/server/server-adapters) - Using adapters
+- [Custom Adapters](/docs/v1/server/custom-adapters) - Creating custom adapters
 - [createRoute()](/reference/v1/server/create-route) - Creating custom routes

package/.docs/raw/reference/server/routes.mdx

@@ -58,16 +58,43 @@ Server adapters register these routes when you call `server.init()`. All routes
 |--------|------|-------------|
 | `GET` | `/api/workflows` | List all workflows |
 | `GET` | `/api/workflows/:workflowId` | Get workflow by ID |
+| `POST` | `/api/workflows/:workflowId/create-run` | Create a new workflow run |
+| `POST` | `/api/workflows/:workflowId/start-async` | Start workflow and await result |
 | `POST` | `/api/workflows/:workflowId/stream` | Stream workflow execution |
 | `POST` | `/api/workflows/:workflowId/resume` | Resume suspended workflow |
 | `POST` | `/api/workflows/:workflowId/resume-async` | Resume asynchronously |
 | `GET` | `/api/workflows/:workflowId/runs` | List workflow runs |
 | `GET` | `/api/workflows/:workflowId/runs/:runId` | Get specific run |
 
+### Create run request body
+
+```typescript
+{
+  resourceId?: string;     // Associate run with a resource (e.g., user ID)
+  disableScorers?: boolean; // Disable scorers for this run
+}
+```
+
+### Start-async request body
+
+```typescript
+{
+  resourceId?: string;     // Associate run with a resource (e.g., user ID)
+  inputData?: unknown;
+  initialState?: unknown;
+  requestContext?: Record<string, unknown>;
+  tracingOptions?: {
+    spanName?: string;
+    attributes?: Record<string, unknown>;
+  };
+}
+```
+
 ### Stream workflow request body
 
 ```typescript
 {
+  resourceId?: string;     // Associate run with a resource (e.g., user ID)
   inputData?: unknown;
   initialState?: unknown;
   requestContext?: Record<string, unknown>;
@@ -247,4 +274,4 @@ Common status codes:
 ## Related
 
 - [createRoute()](/reference/v1/server/create-route) - Creating custom routes
-- [Server Adapters](/docs/v1/server-db/server-adapters) - Using adapters
+- [Server Adapters](/docs/v1/server/server-adapters) - Using adapters

package/.docs/raw/reference/streaming/ChunkType.mdx

@@ -1255,7 +1255,7 @@ Contains monitoring and observability data from agent execution. Can include wor
 
 ### tripwire
 
-Emitted when the stream is forcibly terminated due to content being blocked by output processors. This acts as a safety mechanism to prevent harmful or inappropriate content from being streamed.
+Emitted when the stream is forcibly terminated due to content being blocked by a processor. This acts as a safety mechanism to prevent harmful or inappropriate content from being streamed. The payload includes information about why the content was blocked and whether a retry was requested.
 
 <PropertiesTable
   content={[
@@ -1274,11 +1274,32 @@ Emitted when the stream is forcibly terminated due to content being blocked by o
           type: "TripwirePayload",
           parameters: [
             {
-              name: "tripwireReason",
+              name: "reason",
               type: "string",
               description:
                 "Explanation of why the content was blocked (e.g., 'Output processor blocked content')",
             },
+            {
+              name: "retry",
+              type: "boolean",
+              isOptional: true,
+              description:
+                "Whether the processor requested a retry of the step",
+            },
+            {
+              name: "metadata",
+              type: "unknown",
+              isOptional: true,
+              description:
+                "Additional metadata from the processor (e.g., scores, categories)",
+            },
+            {
+              name: "processorId",
+              type: "string",
+              isOptional: true,
+              description:
+                "ID of the processor that triggered the tripwire",
+            },
           ],
         },
       ],