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

package/.docs/raw/reference/legacyWorkflows/step-condition.mdx

@@ -1,137 +0,0 @@
----
-title: "Reference: StepCondition | Legacy Workflows | Mastra Docs"
-description: Documentation for the step condition class in workflows, which determines whether a step should execute based on the output of previous steps or trigger data.
----
-
-# StepCondition
-
-Conditions determine whether a step should execute based on the output of previous steps or trigger data.
-
-## Usage
-
-There are three ways to specify conditions: function, query object, and simple path comparison.
-
-### 1. Function Condition
-
-```typescript copy showLineNumbers
-workflow.step(processOrder, {
-  when: async ({ context }) => {
-    const auth = context?.getStepResult<{ status: string }>("auth");
-    return auth?.status === "authenticated";
-  },
-});
-```
-
-### 2. Query Object
-
-```typescript copy showLineNumbers
-workflow.step(processOrder, {
-  when: {
-    ref: { step: "auth", path: "status" },
-    query: { $eq: "authenticated" },
-  },
-});
-```
-
-### 3. Simple Path Comparison
-
-```typescript copy showLineNumbers
-workflow.step(processOrder, {
-  when: {
-    "auth.status": "authenticated",
-  },
-});
-```
-
-Based on the type of condition, the workflow runner will try to match the condition to one of these types.
-
-1. Simple Path Condition (when there's a dot in the key)
-2. Base/Query Condition (when there's a 'ref' property)
-3. Function Condition (when it's an async function)
-
-## StepCondition
-
-<PropertiesTable
-  content={[
-    {
-      name: "ref",
-      type: "{ stepId: string | 'trigger'; path: string }",
-      description:
-        "Reference to step output value. stepId can be a step ID or 'trigger' for initial data. path specifies location of value in step result",
-      isOptional: false,
-    },
-    {
-      name: "query",
-      type: "Query<any>",
-      description: "MongoDB-style query using sift operators ($eq, $gt, etc)",
-      isOptional: false,
-    },
-  ]}
-/>
-
-## Query
-
-The Query object provides MongoDB-style query operators for comparing values from previous steps or trigger data. It supports basic comparison operators like `$eq`, `$gt`, `$lt` as well as array operators like `$in` and `$nin`, and can be combined with and/or operators for complex conditions.
-
-This query syntax allows for readable conditional logic for determining whether a step should execute.
-
-<PropertiesTable
-  content={[
-    {
-      name: "$eq",
-      type: "any",
-      description: "Equal to value",
-    },
-    {
-      name: "$ne",
-      type: "any",
-      description: "Not equal to value",
-    },
-    {
-      name: "$gt",
-      type: "number",
-      description: "Greater than value",
-    },
-    {
-      name: "$gte",
-      type: "number",
-      description: "Greater than or equal to value",
-    },
-    {
-      name: "$lt",
-      type: "number",
-      description: "Less than value",
-    },
-    {
-      name: "$lte",
-      type: "number",
-      description: "Less than or equal to value",
-    },
-    {
-      name: "$in",
-      type: "any[]",
-      description: "Value exists in array",
-    },
-    {
-      name: "$nin",
-      type: "any[]",
-      description: "Value does not exist in array",
-    },
-    {
-      name: "and",
-      type: "StepCondition[]",
-      description: "Array of conditions that must all be true",
-    },
-    {
-      name: "or",
-      type: "StepCondition[]",
-      description: "Array of conditions where at least one must be true",
-    },
-  ]}
-/>
-
-## Related
-
-- [Step Options Reference](./step-options)
-- [Step Function Reference](./step-function)
-- [Control Flow Guide](/docs/workflows-legacy/control-flow)

package/.docs/raw/reference/legacyWorkflows/step-function.mdx

@@ -1,93 +0,0 @@
----
-title: "Reference: Workflow.step() | Legacy Workflows | Mastra Docs"
-description: Documentation for the `.step()` method in workflows, which adds a new step to the workflow.
----
-
-# Workflow.step()
-
-The `.step()` method adds a new step to the workflow, optionally configuring its variables and execution conditions.
-
-## Usage
-
-```typescript
-workflow.step({
-  id: "stepTwo",
-  outputSchema: z.object({
-    result: z.number(),
-  }),
-  execute: async ({ context }) => {
-    return { result: 42 };
-  },
-});
-```
-
-## Parameters
-
-<PropertiesTable
-  content={[
-    {
-      name: "stepConfig",
-      type: "Step | StepDefinition | string",
-      description:
-        "Step instance, configuration object, or step ID to add to workflow",
-      isOptional: false,
-    },
-    {
-      name: "options",
-      type: "StepOptions",
-      description: "Optional configuration for step execution",
-      isOptional: true,
-    },
-  ]}
-/>
-
-### StepDefinition
-
-<PropertiesTable
-  content={[
-    {
-      name: "id",
-      type: "string",
-      description: "Unique identifier for the step",
-      isOptional: false,
-    },
-    {
-      name: "outputSchema",
-      type: "z.ZodSchema",
-      description: "Schema for validating step output",
-      isOptional: true,
-    },
-    {
-      name: "execute",
-      type: "(params: ExecuteParams) => Promise<any>",
-      description: "Function containing step logic",
-      isOptional: false,
-    },
-  ]}
-/>
-
-### StepOptions
-
-<PropertiesTable
-  content={[
-    {
-      name: "variables",
-      type: "Record<string, VariableRef>",
-      description: "Map of variable names to their source references",
-      isOptional: true,
-    },
-    {
-      name: "when",
-      type: "StepCondition",
-      description: "Condition that must be met for step to execute",
-      isOptional: true,
-    },
-  ]}
-/>
-
-## Related
-
-- [Basic Usage with Step Instance](/docs/workflows-legacy/steps)
-- [Step Class Reference](./step-class)
-- [Workflow Class Reference](./workflow)
-- [Control Flow Guide](/docs/workflows-legacy/control-flow)

package/.docs/raw/reference/legacyWorkflows/step-options.mdx

@@ -1,69 +0,0 @@
----
-title: "Reference: StepOptions | Legacy Workflows | Mastra Docs"
-description: Documentation for the step options in workflows, which control variable mapping, execution conditions, and other runtime behavior.
----
-
-# StepOptions
-
-Configuration options for workflow steps that control variable mapping, execution conditions, and other runtime behavior.
-
-## Usage
-
-```typescript
-workflow.step(processOrder, {
-  variables: {
-    orderId: { step: "trigger", path: "id" },
-    userId: { step: "auth", path: "user.id" },
-  },
-  when: {
-    ref: { step: "auth", path: "status" },
-    query: { $eq: "authenticated" },
-  },
-});
-```
-
-## Properties
-
-<PropertiesTable
-  content={[
-    {
-      name: "variables",
-      type: "Record<string, VariableRef>",
-      description: "Maps step input variables to values from other steps",
-      isOptional: true,
-    },
-    {
-      name: "when",
-      type: "StepCondition",
-      description: "Condition that must be met for step execution",
-      isOptional: true,
-    },
-  ]}
-/>
-
-### VariableRef
-
-<PropertiesTable
-  content={[
-    {
-      name: "step",
-      type: "string | Step | { id: string }",
-      description: "Source step for the variable value",
-      isOptional: false,
-    },
-    {
-      name: "path",
-      type: "string",
-      description: "Path to the value in the step's output",
-      isOptional: false,
-    },
-  ]}
-/>
-
-## Related
-
-- [Path Comparison](/docs/workflows-legacy/control-flow)
-- [Step Function Reference](./step-function)
-- [Step Class Reference](./step-class)
-- [Workflow Class Reference](./workflow)
-- [Control Flow Guide](/docs/workflows-legacy/control-flow)

package/.docs/raw/reference/legacyWorkflows/step-retries.mdx

@@ -1,196 +0,0 @@
----
-title: "Reference: Step Retries | Legacy Workflows | Mastra Docs"
-description: "Automatically retry failed steps in Mastra workflows with configurable retry policies."
----
-
-# Step Retries
-
-Mastra provides built-in retry mechanisms to handle transient failures in workflow steps. This allows workflows to recover gracefully from temporary issues without requiring manual intervention.
-
-## Overview
-
-When a step in a workflow fails (throws an exception), Mastra can automatically retry the step execution based on a configurable retry policy. This is useful for handling:
-
-- Network connectivity issues
-- Service unavailability
-- Rate limiting
-- Temporary resource constraints
-- Other transient failures
-
-## Default Behavior
-
-By default, steps do not retry when they fail. This means:
-
-- A step will execute once
-- If it fails, it will immediately mark the step as failed
-- The workflow will continue to execute any subsequent steps that don't depend on the failed step
-
-## Configuration Options
-
-Retries can be configured at two levels:
-
-### 1. Workflow-level Configuration
-
-You can set a default retry configuration for all steps in a workflow:
-
-```typescript
-const workflow = new LegacyWorkflow({
-  name: "my-workflow",
-  retryConfig: {
-    attempts: 3, // Number of retries (in addition to the initial attempt)
-    delay: 1000, // Delay between retries in milliseconds
-  },
-});
-```
-
-### 2. Step-level Configuration
-
-You can also configure retries on individual steps, which will override the workflow-level configuration for that specific step:
-
-```typescript
-const fetchDataStep = new LegacyStep({
-  id: "fetchData",
-  execute: async () => {
-    // Fetch data from external API
-  },
-  retryConfig: {
-    attempts: 5, // This step will retry up to 5 times
-    delay: 2000, // With a 2-second delay between retries
-  },
-});
-```
-
-## Retry Parameters
-
-The `retryConfig` object supports the following parameters:
-
-| Parameter  | Type   | Default | Description                                                       |
-| ---------- | ------ | ------- | ----------------------------------------------------------------- |
-| `attempts` | number | 0       | The number of retry attempts (in addition to the initial attempt) |
-| `delay`    | number | 1000    | Time in milliseconds to wait between retries                      |
-
-## How Retries Work
-
-When a step fails, Mastra's retry mechanism:
-
-1. Checks if the step has retry attempts remaining
-2. If attempts remain:
-   - Decrements the attempt counter
-   - Transitions the step to a "waiting" state
-   - Waits for the configured delay period
-   - Retries the step execution
-3. If no attempts remain or all attempts have been exhausted:
-   - Marks the step as "failed"
-   - Continues workflow execution (for steps that don't depend on the failed step)
-
-During retry attempts, the workflow execution remains active but paused for the specific step that is being retried.
-
-## Examples
-
-### Basic Retry Example
-
-```typescript
-import { LegacyWorkflow, LegacyStep } from "@mastra/core/workflows/legacy";
-
-// Define a step that might fail
-const unreliableApiStep = new LegacyStep({
-  id: "callUnreliableApi",
-  execute: async () => {
-    // Simulate an API call that might fail
-    const random = Math.random();
-    if (random < 0.7) {
-      throw new Error("API call failed");
-    }
-    return { data: "API response data" };
-  },
-  retryConfig: {
-    attempts: 3, // Retry up to 3 times
-    delay: 2000, // Wait 2 seconds between attempts
-  },
-});
-
-// Create a workflow with the unreliable step
-const workflow = new LegacyWorkflow({
-  name: "retry-demo-workflow",
-});
-
-workflow.step(unreliableApiStep).then(processResultStep).commit();
-```
-
-### Workflow-level Retries with Step Override
-
-```typescript
-import { LegacyWorkflow, LegacyStep } from "@mastra/core/workflows/legacy";
-
-// Create a workflow with default retry configuration
-const workflow = new LegacyWorkflow({
-  name: "multi-retry-workflow",
-  retryConfig: {
-    attempts: 2, // All steps will retry twice by default
-    delay: 1000, // With a 1-second delay
-  },
-});
-
-// This step uses the workflow's default retry configuration
-const standardStep = new LegacyStep({
-  id: "standardStep",
-  execute: async () => {
-    // Some operation that might fail
-  },
-});
-
-// This step overrides the workflow's retry configuration
-const criticalStep = new LegacyStep({
-  id: "criticalStep",
-  execute: async () => {
-    // Critical operation that needs more retry attempts
-  },
-  retryConfig: {
-    attempts: 5, // Override with 5 retry attempts
-    delay: 5000, // And a longer 5-second delay
-  },
-});
-
-// This step disables retries
-const noRetryStep = new LegacyStep({
-  id: "noRetryStep",
-  execute: async () => {
-    // Operation that should not retry
-  },
-  retryConfig: {
-    attempts: 0, // Explicitly disable retries
-  },
-});
-
-workflow.step(standardStep).then(criticalStep).then(noRetryStep).commit();
-```
-
-## Monitoring Retries
-
-You can monitor retry attempts in your logs. Mastra logs retry-related events at the `debug` level:
-
-```
-[DEBUG] Step fetchData failed (runId: abc-123)
-[DEBUG] Attempt count for step fetchData: 2 remaining attempts (runId: abc-123)
-[DEBUG] Step fetchData waiting (runId: abc-123)
-[DEBUG] Step fetchData finished waiting (runId: abc-123)
-[DEBUG] Step fetchData pending (runId: abc-123)
-```
-
-## Best Practices
-
-1. **Use Retries for Transient Failures**: Only configure retries for operations that might experience transient failures. For deterministic errors (like validation failures), retries won't help.
-
-2. **Set Appropriate Delays**: Consider using longer delays for external API calls to allow time for services to recover.
-
-3. **Limit Retry Attempts**: Don't set extremely high retry counts as this could cause workflows to run for excessive periods during outages.
-
-4. **Implement Idempotent Operations**: Ensure your step's `execute` function is idempotent (can be called multiple times without side effects) since it may be retried.
-
-5. **Consider Backoff Strategies**: For more advanced scenarios, consider implementing exponential backoff in your step's logic for operations that might be rate-limited.
-
-## Related
-
-- [Step Class Reference](./step-class)
-- [Workflow Configuration](./workflow)
-- [Error Handling in Workflows](/docs/workflows-legacy/error-handling)

package/.docs/raw/reference/legacyWorkflows/suspend.mdx

@@ -1,70 +0,0 @@
----
-title: "Reference: suspend() | Legacy Workflows | Mastra Docs"
-description: "Documentation for the suspend function in Mastra workflows, which pauses execution until resumed."
----
-
-# suspend()
-
-Pauses workflow execution at the current step until explicitly resumed. The workflow state is persisted and can be continued later.
-
-## Usage Example
-
-```typescript
-const approvalStep = new LegacyStep({
-  id: "needsApproval",
-  execute: async ({ context, suspend }) => {
-    if (context.steps.amount > 1000) {
-      await suspend();
-    }
-    return { approved: true };
-  },
-});
-```
-
-## Parameters
-
-<PropertiesTable
-  content={[
-    {
-      name: "metadata",
-      type: "Record<string, any>",
-      description: "Optional data to store with the suspended state",
-      isOptional: true,
-    },
-  ]}
-/>
-
-## Returns
-
-<PropertiesTable
-  content={[
-    {
-      name: "Promise<void>",
-      type: "Promise",
-      description: "Resolves when the workflow is successfully suspended",
-    },
-  ]}
-/>
-
-## Additional Examples
-
-Suspend with metadata:
-
-```typescript
-const reviewStep = new LegacyStep({
-  id: "review",
-  execute: async ({ context, suspend }) => {
-    await suspend({
-      reason: "Needs manager approval",
-      requestedBy: context.user,
-    });
-    return { reviewed: true };
-  },
-});
-```
-
-### Related
-
-- [Suspend & Resume Workflows](/docs/workflows-legacy/suspend-and-resume)
-- [.resume()](./resume)
-- [.watch()](./watch)

package/.docs/raw/reference/legacyWorkflows/then.mdx

@@ -1,72 +0,0 @@
----
-title: "Reference: Workflow.then() | Legacy Workflows | Mastra Docs"
-description: Documentation for the `.then()` method in workflows, which creates sequential dependencies between steps.
----
-
-# Workflow.then()
-
-The `.then()` method creates a sequential dependency between workflow steps, ensuring steps execute in a specific order.
-
-## Usage
-
-```typescript
-workflow.step(stepOne).then(stepTwo).then(stepThree);
-```
-
-## Parameters
-
-<PropertiesTable
-  content={[
-    {
-      name: "step",
-      type: "Step | string",
-      description:
-        "The step instance or step ID that should execute after the previous step completes",
-      isOptional: false,
-    },
-  ]}
-/>
-
-## Returns
-
-<PropertiesTable
-  content={[
-    {
-      name: "workflow",
-      type: "LegacyWorkflow",
-      description: "The workflow instance for method chaining",
-    },
-  ]}
-/>
-
-## Validation
-
-When using `then`:
-
-- The previous step must exist in the workflow
-- Steps cannot form circular dependencies
-- Each step can only appear once in a sequential chain
-
-## Error Handling
-
-```typescript
-try {
-  workflow
-    .step(stepA)
-    .then(stepB)
-    .then(stepA) // Will throw error - circular dependency
-    .commit();
-} catch (error) {
-  if (error instanceof ValidationError) {
-    console.log(error.type); // 'circular_dependency'
-    console.log(error.details);
-  }
-}
-```
-
-## Related
-
-- [step Reference](./step-class)
-- [after Reference](./after)
-- [Sequential Steps Example](/examples/workflows_legacy/sequential-steps)
-- [Control Flow Guide](/docs/workflows-legacy/control-flow)