@mastra/mcp-docs-server 1.2.15-alpha.7 → 1.2.15-alpha.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.docs/docs/server/mastra-client.md +11 -11
- package/.docs/docs/workflows/agents-and-tools.md +2 -2
- package/.docs/docs/workflows/{stored-workflows.md → dynamic-workflows.md} +23 -23
- package/.docs/reference/client-js/workflows.md +19 -19
- package/.docs/reference/core/{addStoredWorkflow.md → addDynamicWorkflow.md} +10 -10
- package/.docs/reference/core/{addStoredWorkflows.md → addDynamicWorkflows.md} +9 -9
- package/.docs/reference/editor/tool-provider.md +26 -1
- package/.docs/reference/index.md +3 -3
- package/.docs/reference/server/routes.md +9 -9
- package/.docs/reference/storage/overview.md +9 -9
- package/.docs/reference/storage/retention.md +1 -1
- package/.docs/reference/workflows/{stored-workflow-definition.md → dynamic-workflow-definition.md} +7 -7
- package/.docs/reference/workflows/workflow-methods/agent.md +3 -3
- package/.docs/reference/workflows/workflow-methods/tool.md +3 -3
- package/CHANGELOG.md +7 -0
- package/package.json +5 -5
|
@@ -69,15 +69,15 @@ The Mastra Client SDK exposes all resources served by the Mastra Server.
|
|
|
69
69
|
- **[Logs](https://mastra.ai/reference/client-js/logs)**: View logs and debug system behavior.
|
|
70
70
|
- **[Telemetry](https://mastra.ai/reference/client-js/telemetry)**: View app performance and trace activity.
|
|
71
71
|
|
|
72
|
-
## Create and run
|
|
72
|
+
## Create and run dynamic workflows
|
|
73
73
|
|
|
74
|
-
Use `
|
|
74
|
+
Use `upsertDynamicWorkflow()` to create or replace a persisted workflow definition. A successful upsert validates the complete definition, registers it with the running Mastra instance, and makes it available through the standard workflow execution API.
|
|
75
75
|
|
|
76
76
|
The following example shows the full lifecycle of a mapping workflow, from creation and inspection through execution and deletion:
|
|
77
77
|
|
|
78
78
|
```typescript
|
|
79
79
|
import { MastraClient } from '@mastra/client-js'
|
|
80
|
-
import type {
|
|
80
|
+
import type { UpsertDynamicWorkflowParams } from '@mastra/client-js'
|
|
81
81
|
|
|
82
82
|
const client = new MastraClient({
|
|
83
83
|
baseUrl: process.env.MASTRA_API_URL || 'http://localhost:4111',
|
|
@@ -105,25 +105,25 @@ const definition = {
|
|
|
105
105
|
}),
|
|
106
106
|
},
|
|
107
107
|
],
|
|
108
|
-
} satisfies
|
|
108
|
+
} satisfies UpsertDynamicWorkflowParams
|
|
109
109
|
|
|
110
|
-
await client.
|
|
110
|
+
await client.upsertDynamicWorkflow(definition)
|
|
111
111
|
|
|
112
|
-
const
|
|
113
|
-
const
|
|
112
|
+
const dynamicWorkflow = client.getDynamicWorkflow(definition.id)
|
|
113
|
+
const dynamicDefinition = await dynamicWorkflow.details()
|
|
114
114
|
|
|
115
|
-
const workflow = client.getWorkflow(
|
|
115
|
+
const workflow = client.getWorkflow(dynamicDefinition.id)
|
|
116
116
|
const run = await workflow.createRun()
|
|
117
117
|
const result = await run.startAsync({ inputData: { name: 'Ada' } })
|
|
118
118
|
|
|
119
119
|
console.log(result)
|
|
120
120
|
|
|
121
|
-
await
|
|
121
|
+
await dynamicWorkflow.delete()
|
|
122
122
|
```
|
|
123
123
|
|
|
124
|
-
Use `
|
|
124
|
+
Use `listDynamicWorkflows()` to list persisted definitions. Calling `upsertDynamicWorkflow()` again with the same `id` replaces the stored definition and live workflow registration.
|
|
125
125
|
|
|
126
|
-
> **Warning:** Durable storage requires a configured storage adapter that supports the `workflowDefinitions` domain. Without that domain, Core can register a workflow in memory, but the server's
|
|
126
|
+
> **Warning:** Durable storage requires a configured storage adapter that supports the `workflowDefinitions` domain. Without that domain, Core can register a workflow in memory, but the server's dynamic-workflow API can't preserve it across restarts.
|
|
127
127
|
>
|
|
128
128
|
> Stored definitions support declarative agent, tool, mapping, nested workflow, parallel, foreach, sleep, sleep-until, conditional, and loop entries. They can't contain JavaScript closures. Conditional and loop logic must use the declarative predicate format, and referenced agents, tools, and nested workflows must already be registered.
|
|
129
129
|
>
|
|
@@ -123,7 +123,7 @@ export const testWorkflow = createWorkflow({})
|
|
|
123
123
|
.commit()
|
|
124
124
|
```
|
|
125
125
|
|
|
126
|
-
`.agent()` records a declarative entry in the workflow graph rather than an opaque step, so workflows built this way can be persisted as [
|
|
126
|
+
`.agent()` records a declarative entry in the workflow graph rather than an opaque step, so workflows built this way can be persisted as [dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows). Visit [Workflow.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent) for all parameters.
|
|
127
127
|
|
|
128
128
|
## Using tools in workflows
|
|
129
129
|
|
|
@@ -184,7 +184,7 @@ import { testTool } from '../tools/test-tool'
|
|
|
184
184
|
export const testWorkflow = createWorkflow({}).then(step1).tool(testTool).commit()
|
|
185
185
|
```
|
|
186
186
|
|
|
187
|
-
Like `.agent()`, `.tool()` records a declarative entry, so the workflow can be persisted as a [
|
|
187
|
+
Like `.agent()`, `.tool()` records a declarative entry, so the workflow can be persisted as a [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows). Visit [Workflow.tool()](https://mastra.ai/reference/workflows/workflow-methods/tool) for all parameters.
|
|
188
188
|
|
|
189
189
|
## Related
|
|
190
190
|
|
|
@@ -1,22 +1,22 @@
|
|
|
1
1
|
> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
|
|
2
2
|
|
|
3
|
-
#
|
|
3
|
+
# Dynamic workflows
|
|
4
4
|
|
|
5
5
|
> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Dynamic workflows are workflow definitions expressed as data instead of code. A definition is a JSON document that describes the workflow's schemas and step graph. Mastra validates the definition and registers it as a runnable workflow, then persists it in storage so it survives process restarts.
|
|
8
8
|
|
|
9
|
-
Because a definition contains no JavaScript closures, anything that can produce JSON can author a workflow: an HTTP client, an LLM, a visual editor, or your own tooling. Once registered, a
|
|
9
|
+
Because a definition contains no JavaScript closures, anything that can produce JSON can author a workflow: an HTTP client, an LLM, a visual editor, or your own tooling. Once registered, a dynamic workflow runs through the same execution API as a code-defined workflow.
|
|
10
10
|
|
|
11
|
-
## When to use
|
|
11
|
+
## When to use dynamic workflows
|
|
12
12
|
|
|
13
|
-
Use
|
|
13
|
+
Use dynamic workflows when users, agents, visual editors, or external systems need to create workflows without changing application code or deploying again.
|
|
14
14
|
|
|
15
|
-
Keep defining workflows with [`createWorkflow()`](https://mastra.ai/docs/workflows/overview) when the workflow belongs in your application source or needs custom step functions.
|
|
15
|
+
Keep defining workflows with [`createWorkflow()`](https://mastra.ai/docs/workflows/overview) when the workflow belongs in your application source or needs custom step functions. Dynamic workflows can invoke agents, tools, and workflows that are already registered on the `Mastra` instance.
|
|
16
16
|
|
|
17
17
|
## Quickstart
|
|
18
18
|
|
|
19
|
-
The following example registers a tool and invokes it from a
|
|
19
|
+
The following example registers a tool and invokes it from a dynamic workflow. It then runs the workflow. `LibSQLStore` persists the definition in `mastra.db`, so Mastra can restore it after a restart.
|
|
20
20
|
|
|
21
21
|
```typescript
|
|
22
22
|
import { Mastra } from '@mastra/core/mastra'
|
|
@@ -46,7 +46,7 @@ const mastra = new Mastra({
|
|
|
46
46
|
tools: { 'create-greeting': greetingTool },
|
|
47
47
|
})
|
|
48
48
|
|
|
49
|
-
await mastra.
|
|
49
|
+
await mastra.addDynamicWorkflow({
|
|
50
50
|
id: 'greeting-workflow',
|
|
51
51
|
description: 'Create a greeting for the supplied name',
|
|
52
52
|
inputSchema: {
|
|
@@ -83,9 +83,9 @@ if (result.status === 'success') {
|
|
|
83
83
|
}
|
|
84
84
|
```
|
|
85
85
|
|
|
86
|
-
The workflow prints `Hello, Ada!`. Calling [`
|
|
86
|
+
The workflow prints `Hello, Ada!`. Calling [`addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow) validates the definition before it changes storage or the live workflow registry.
|
|
87
87
|
|
|
88
|
-
The definition uses JSON Schema because it must survive a JSON round trip. The `graph` describes which registered components to invoke and how data moves between them. See the [
|
|
88
|
+
The definition uses JSON Schema because it must survive a JSON round trip. The `graph` describes which registered components to invoke and how data moves between them. See the [dynamic workflow definition reference](https://mastra.ai/reference/workflows/dynamic-workflow-definition) for every field and graph entry.
|
|
89
89
|
|
|
90
90
|
## Build and update definitions
|
|
91
91
|
|
|
@@ -93,54 +93,54 @@ A definition can come from any source that produces JSON. For example, an API ro
|
|
|
93
93
|
|
|
94
94
|
```typescript
|
|
95
95
|
const definition = await request.json()
|
|
96
|
-
await mastra.
|
|
96
|
+
await mastra.addDynamicWorkflow(definition)
|
|
97
97
|
```
|
|
98
98
|
|
|
99
99
|
### Register dependencies first
|
|
100
100
|
|
|
101
|
-
Register referenced components on the same `Mastra` instance before adding the
|
|
101
|
+
Register referenced components on the same `Mastra` instance before adding the dynamic workflow. Agent and nested workflow entries use their intrinsic IDs. A tool entry uses its key from the `Mastra` `tools` object, so the quickstart registers the tool under `create-greeting` before referencing that key with `toolId`.
|
|
102
102
|
|
|
103
|
-
Use a `mapping` entry when one step's output doesn't match the next step's input. Mapping entries can read data from the workflow input and previous step results, along with workflow state and request context. The [definition reference](https://mastra.ai/reference/workflows/
|
|
103
|
+
Use a `mapping` entry when one step's output doesn't match the next step's input. Mapping entries can read data from the workflow input and previous step results, along with workflow state and request context. The [definition reference](https://mastra.ai/reference/workflows/dynamic-workflow-definition) lists the supported mapping descriptors.
|
|
104
104
|
|
|
105
105
|
### Replace a workflow
|
|
106
106
|
|
|
107
107
|
Add a new definition with the same `id` to replace the persisted definition and live registration:
|
|
108
108
|
|
|
109
109
|
```typescript
|
|
110
|
-
await mastra.
|
|
110
|
+
await mastra.addDynamicWorkflow(updatedDefinition)
|
|
111
111
|
```
|
|
112
112
|
|
|
113
113
|
New runs use the updated graph. Runs that already started continue with their original graph.
|
|
114
114
|
|
|
115
115
|
### Add nested workflows together
|
|
116
116
|
|
|
117
|
-
When a root workflow references helper workflows that aren't registered yet, add the full set with [`
|
|
117
|
+
When a root workflow references helper workflows that aren't registered yet, add the full set with [`addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows):
|
|
118
118
|
|
|
119
119
|
```typescript
|
|
120
|
-
await mastra.
|
|
120
|
+
await mastra.addDynamicWorkflows([rootDefinition, helperDefinition])
|
|
121
121
|
```
|
|
122
122
|
|
|
123
123
|
Mastra validates the bundle as a unit and determines the registration order from the dependencies. If validation fails, none of the definitions are registered.
|
|
124
124
|
|
|
125
125
|
### Manage definitions over HTTP
|
|
126
126
|
|
|
127
|
-
Applications don't need direct access to the `Mastra` instance to manage
|
|
127
|
+
Applications don't need direct access to the `Mastra` instance to manage dynamic workflows. Use one of these interfaces:
|
|
128
128
|
|
|
129
|
-
- [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows): Call `
|
|
129
|
+
- [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows): Call `upsertDynamicWorkflow()` from a JavaScript or TypeScript client.
|
|
130
130
|
- [Server routes](https://mastra.ai/reference/server/routes): Send definitions to `POST /api/stored/workflows`.
|
|
131
131
|
|
|
132
|
-
On authenticated servers,
|
|
132
|
+
On authenticated servers, dynamic-workflow management requires the `stored-workflows:read` and `stored-workflows:write` permissions. Running the registered workflow requires `workflows:execute`.
|
|
133
133
|
|
|
134
134
|
### Persist definitions
|
|
135
135
|
|
|
136
136
|
Stored definitions use the `workflowDefinitions` storage domain. On startup, Mastra loads active definitions from storage and registers them in dependency order.
|
|
137
137
|
|
|
138
|
-
Without a storage adapter that supports this domain, `
|
|
138
|
+
Without a storage adapter that supports this domain, `addDynamicWorkflow()` still registers the workflow in memory, but the definition is lost when the process restarts. See the [storage reference](https://mastra.ai/reference/storage/overview) for adapter support.
|
|
139
139
|
|
|
140
140
|
## Related
|
|
141
141
|
|
|
142
|
-
- [
|
|
143
|
-
- [`Mastra.
|
|
144
|
-
- [`Mastra.
|
|
142
|
+
- [Dynamic workflow definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition)
|
|
143
|
+
- [`Mastra.addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow)
|
|
144
|
+
- [`Mastra.addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows)
|
|
145
145
|
- [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows)
|
|
146
146
|
- [Server routes](https://mastra.ai/reference/server/routes)
|
|
@@ -225,28 +225,28 @@ A workflow run result yields the following:
|
|
|
225
225
|
|
|
226
226
|
**payload** (`object`): Contains currentStep (id, status, output, payload) and workflowState (status, steps record)
|
|
227
227
|
|
|
228
|
-
##
|
|
228
|
+
## Dynamic workflows
|
|
229
229
|
|
|
230
|
-
> **Beta:**
|
|
230
|
+
> **Beta:** Dynamic workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
|
|
231
231
|
|
|
232
|
-
|
|
232
|
+
Dynamic workflows are workflow definitions expressed as JSON. The server persists each definition and registers it as a runnable workflow. See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) for the definition format.
|
|
233
233
|
|
|
234
|
-
### `
|
|
234
|
+
### `listDynamicWorkflows()`
|
|
235
235
|
|
|
236
|
-
List
|
|
236
|
+
List dynamic workflow definitions, optionally filtered by `status` (`'active' | 'archived'`) and `authorId`:
|
|
237
237
|
|
|
238
238
|
```typescript
|
|
239
|
-
const { definitions, total } = await mastraClient.
|
|
239
|
+
const { definitions, total } = await mastraClient.listDynamicWorkflows({
|
|
240
240
|
status: 'active',
|
|
241
241
|
})
|
|
242
242
|
```
|
|
243
243
|
|
|
244
|
-
### `
|
|
244
|
+
### `upsertDynamicWorkflow()`
|
|
245
245
|
|
|
246
|
-
Create or replace a
|
|
246
|
+
Create or replace a dynamic workflow definition. The server validates the definition, persists it, and live-registers it for execution:
|
|
247
247
|
|
|
248
248
|
```typescript
|
|
249
|
-
const stored = await mastraClient.
|
|
249
|
+
const stored = await mastraClient.upsertDynamicWorkflow({
|
|
250
250
|
id: 'greeting-workflow',
|
|
251
251
|
description: 'Returns a greeting for the supplied name',
|
|
252
252
|
inputSchema: {
|
|
@@ -274,7 +274,7 @@ const stored = await mastraClient.upsertStoredWorkflow({
|
|
|
274
274
|
When the root definition nests helper workflows that don't exist yet, pass them in the same request through `dependencies`. The server validates and registers the bundle as a unit and echoes the helper ids back as `dependencyIds`:
|
|
275
275
|
|
|
276
276
|
```typescript
|
|
277
|
-
const stored = await mastraClient.
|
|
277
|
+
const stored = await mastraClient.upsertDynamicWorkflow({
|
|
278
278
|
id: 'root-workflow',
|
|
279
279
|
// ...schemas and graph referencing 'helper-workflow'...
|
|
280
280
|
dependencies: [helperDefinition],
|
|
@@ -283,33 +283,33 @@ const stored = await mastraClient.upsertStoredWorkflow({
|
|
|
283
283
|
console.log(stored.dependencyIds) // ['helper-workflow']
|
|
284
284
|
```
|
|
285
285
|
|
|
286
|
-
### `
|
|
286
|
+
### `getDynamicWorkflow()`
|
|
287
287
|
|
|
288
|
-
Get a
|
|
288
|
+
Get a dynamic workflow instance for definition management. To execute a dynamic workflow, use `getWorkflow(id).createRun()` like any other workflow:
|
|
289
289
|
|
|
290
290
|
```typescript
|
|
291
|
-
const
|
|
291
|
+
const dynamicWorkflow = mastraClient.getDynamicWorkflow('greeting-workflow')
|
|
292
292
|
```
|
|
293
293
|
|
|
294
|
-
### `
|
|
294
|
+
### `dynamicWorkflow.details()`
|
|
295
295
|
|
|
296
296
|
Retrieve the persisted definition, including schemas, graph, status, and timestamps:
|
|
297
297
|
|
|
298
298
|
```typescript
|
|
299
|
-
const definition = await
|
|
299
|
+
const definition = await dynamicWorkflow.details()
|
|
300
300
|
```
|
|
301
301
|
|
|
302
|
-
### `
|
|
302
|
+
### `dynamicWorkflow.delete()`
|
|
303
303
|
|
|
304
304
|
Delete the stored definition and unregister the live workflow:
|
|
305
305
|
|
|
306
306
|
```typescript
|
|
307
|
-
await
|
|
307
|
+
await dynamicWorkflow.delete()
|
|
308
308
|
```
|
|
309
309
|
|
|
310
|
-
### Executing a
|
|
310
|
+
### Executing a dynamic workflow
|
|
311
311
|
|
|
312
|
-
Once registered, a
|
|
312
|
+
Once registered, a dynamic workflow runs through the ordinary workflow API:
|
|
313
313
|
|
|
314
314
|
```typescript
|
|
315
315
|
const workflow = mastraClient.getWorkflow('greeting-workflow')
|
|
@@ -1,17 +1,17 @@
|
|
|
1
1
|
> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
|
|
2
2
|
|
|
3
|
-
# Mastra.
|
|
3
|
+
# Mastra.addDynamicWorkflow()
|
|
4
4
|
|
|
5
|
-
> **Beta:**
|
|
5
|
+
> **Beta:** Dynamic workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
|
|
6
6
|
|
|
7
|
-
The `.
|
|
7
|
+
The `.addDynamicWorkflow()` method validates a dynamic workflow definition and registers it as a live workflow on the instance, persisting it through the `workflowDefinitions` storage domain. Once registered, the workflow runs like any other workflow via [`getWorkflow()`](https://mastra.ai/reference/core/getWorkflow).
|
|
8
8
|
|
|
9
|
-
See [
|
|
9
|
+
See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) for a complete setup example and the [dynamic workflow definition reference](https://mastra.ai/reference/workflows/dynamic-workflow-definition) for the accepted fields and graph entries.
|
|
10
10
|
|
|
11
11
|
## Usage example
|
|
12
12
|
|
|
13
13
|
```typescript
|
|
14
|
-
await mastra.
|
|
14
|
+
await mastra.addDynamicWorkflow({
|
|
15
15
|
id: 'greeting-workflow',
|
|
16
16
|
description: 'Returns a greeting for the supplied name',
|
|
17
17
|
inputSchema: {
|
|
@@ -41,7 +41,7 @@ const result = await run.start({ inputData: { name: 'Ada' } })
|
|
|
41
41
|
|
|
42
42
|
## Parameters
|
|
43
43
|
|
|
44
|
-
**def** (`
|
|
44
|
+
**def** (`DynamicWorkflowGraph`): The workflow definition: id, optional description and metadata, JSON Schema input/output schemas, optional state and request-context schemas, and the step graph.
|
|
45
45
|
|
|
46
46
|
## Returns
|
|
47
47
|
|
|
@@ -52,11 +52,11 @@ A promise that resolves once the definition is validated, registered, and persis
|
|
|
52
52
|
- The definition is fully validated (structure, references, schema flow) before anything is mutated. Agents, tools, and workflows referenced by the graph must already be registered on the instance.
|
|
53
53
|
- Adding a definition with an existing ID replaces both the stored definition and the live registration. In-flight runs keep the graph they started with.
|
|
54
54
|
- Without a storage adapter that supports the `workflowDefinitions` domain, the workflow is still validated and registered in memory, but the definition is lost on restart.
|
|
55
|
-
- To add a root workflow together with helper workflows it nests, use [`
|
|
55
|
+
- To add a root workflow together with helper workflows it nests, use [`addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows).
|
|
56
56
|
|
|
57
57
|
## Related
|
|
58
58
|
|
|
59
|
-
- [Mastra.
|
|
59
|
+
- [Mastra.addDynamicWorkflows()](https://mastra.ai/reference/core/addDynamicWorkflows): Add a dependency-ordered bundle of definitions
|
|
60
60
|
- [Mastra.getWorkflow()](https://mastra.ai/reference/core/getWorkflow): Retrieve a registered workflow
|
|
61
|
-
- [
|
|
62
|
-
- [
|
|
61
|
+
- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows): Set up and use dynamic workflows
|
|
62
|
+
- [Dynamic workflow definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition): Definition fields and graph entries
|
|
@@ -1,19 +1,19 @@
|
|
|
1
1
|
> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
|
|
2
2
|
|
|
3
|
-
# Mastra.
|
|
3
|
+
# Mastra.addDynamicWorkflows()
|
|
4
4
|
|
|
5
|
-
> **Beta:**
|
|
5
|
+
> **Beta:** Dynamic workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
|
|
6
6
|
|
|
7
|
-
The `.
|
|
7
|
+
The `.addDynamicWorkflows()` method adds a bundle of dynamic workflow definitions that may reference each other. The typical case is a root workflow plus helper workflows it nests, where none of the definitions exist yet.
|
|
8
8
|
|
|
9
9
|
The whole bundle is validated up front. Members are then registered in dependency order, so a helper is always in place before the workflow that nests it.
|
|
10
10
|
|
|
11
|
-
[`
|
|
11
|
+
[`addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow) is the single-member case.
|
|
12
12
|
|
|
13
13
|
## Usage example
|
|
14
14
|
|
|
15
15
|
```typescript
|
|
16
|
-
await mastra.
|
|
16
|
+
await mastra.addDynamicWorkflows([
|
|
17
17
|
helperDefinition, // nested by the root — order in the array doesn't matter
|
|
18
18
|
rootDefinition, // graph contains { type: 'workflow', workflowId: helperDefinition.id }
|
|
19
19
|
])
|
|
@@ -21,7 +21,7 @@ await mastra.addStoredWorkflows([
|
|
|
21
21
|
|
|
22
22
|
## Parameters
|
|
23
23
|
|
|
24
|
-
**defs** (`readonly
|
|
24
|
+
**defs** (`readonly DynamicWorkflowGraph[]`): The workflow definitions to add. Nested-workflow references may resolve against the live registries or against other members of the same bundle.
|
|
25
25
|
|
|
26
26
|
## Returns
|
|
27
27
|
|
|
@@ -35,6 +35,6 @@ A promise that resolves once every member is validated, registered, and persiste
|
|
|
35
35
|
|
|
36
36
|
## Related
|
|
37
37
|
|
|
38
|
-
- [Mastra.
|
|
39
|
-
- [
|
|
40
|
-
- [
|
|
38
|
+
- [Mastra.addDynamicWorkflow()](https://mastra.ai/reference/core/addDynamicWorkflow): Add a single definition
|
|
39
|
+
- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows): Set up and use dynamic workflows
|
|
40
|
+
- [Dynamic workflow definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition): Definition fields and graph entries
|
|
@@ -83,7 +83,32 @@ Composio tools use uppercase slug format: `GITHUB_CREATE_ISSUE`, `SLACK_SEND_MES
|
|
|
83
83
|
|
|
84
84
|
### Authentication
|
|
85
85
|
|
|
86
|
-
Connections use per-author scope by default. Set `defaultScope: 'caller-supplied'` to bucket authorization by the caller identity resolved from request context.
|
|
86
|
+
Connections use per-author scope by default. Set `defaultScope: 'caller-supplied'` to bucket authorization by the caller identity resolved from `MASTRA_RESOURCE_ID_KEY` in request context. Ensure each authenticated request provides a stable, unique resource ID. When using `MastraAuthWorkos`, configure `mapUserToResourceId` to set this value from the authenticated user.
|
|
87
|
+
|
|
88
|
+
### Connection management tools
|
|
89
|
+
|
|
90
|
+
Composio provides tools for starting and monitoring authorization from an agent chat. When `allowedToolkits` is set, include `composio` to make these tools available:
|
|
91
|
+
|
|
92
|
+
```typescript
|
|
93
|
+
const editor = new MastraEditor({
|
|
94
|
+
toolProviders: {
|
|
95
|
+
composio: new ComposioToolProvider({
|
|
96
|
+
apiKey: process.env.COMPOSIO_API_KEY!,
|
|
97
|
+
allowedToolkits: ['composio', 'gmail'],
|
|
98
|
+
defaultScope: 'caller-supplied',
|
|
99
|
+
}),
|
|
100
|
+
},
|
|
101
|
+
})
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
Add only the connection management tools that the agent needs:
|
|
105
|
+
|
|
106
|
+
| Tool | Behavior |
|
|
107
|
+
| ------------------------------- | ---------------------------------------------------------------------------- |
|
|
108
|
+
| `COMPOSIO_MANAGE_CONNECTIONS` | Creates an authorization link in chat through a session owned by the caller. |
|
|
109
|
+
| `COMPOSIO_WAIT_FOR_CONNECTIONS` | Waits for the caller to finish authorization before the agent continues. |
|
|
110
|
+
|
|
111
|
+
`COMPOSIO_WAIT_FOR_CONNECTIONS` is optional. Without it, complete authorization and return to the chat. Then ask the agent to continue. The connected account remains associated with the caller resource ID for later requests.
|
|
87
112
|
|
|
88
113
|
***
|
|
89
114
|
|
package/.docs/reference/index.md
CHANGED
|
@@ -82,9 +82,9 @@ The Reference section provides documentation of Mastra's API, including paramete
|
|
|
82
82
|
- [createCodingAgent()](https://mastra.ai/reference/coding-agent/create-coding-agent)
|
|
83
83
|
- [Mastra Class](https://mastra.ai/reference/core/mastra-class)
|
|
84
84
|
- [MastraModelGateway](https://mastra.ai/reference/core/mastra-model-gateway)
|
|
85
|
+
- [.addDynamicWorkflow()](https://mastra.ai/reference/core/addDynamicWorkflow)
|
|
86
|
+
- [.addDynamicWorkflows()](https://mastra.ai/reference/core/addDynamicWorkflows)
|
|
85
87
|
- [.addGateway()](https://mastra.ai/reference/core/addGateway)
|
|
86
|
-
- [.addStoredWorkflow()](https://mastra.ai/reference/core/addStoredWorkflow)
|
|
87
|
-
- [.addStoredWorkflows()](https://mastra.ai/reference/core/addStoredWorkflows)
|
|
88
88
|
- [.getAgent()](https://mastra.ai/reference/core/getAgent)
|
|
89
89
|
- [.getAgentById()](https://mastra.ai/reference/core/getAgentById)
|
|
90
90
|
- [.getDeployer()](https://mastra.ai/reference/core/getDeployer)
|
|
@@ -366,9 +366,9 @@ The Reference section provides documentation of Mastra's API, including paramete
|
|
|
366
366
|
- [.speak()](https://mastra.ai/reference/voice/voice.speak)
|
|
367
367
|
- [.updateConfig()](https://mastra.ai/reference/voice/voice.updateConfig)
|
|
368
368
|
- [Overview](https://mastra.ai/reference/workers/overview)
|
|
369
|
+
- [Dynamic Workflow Definition](https://mastra.ai/reference/workflows/dynamic-workflow-definition)
|
|
369
370
|
- [Run Class](https://mastra.ai/reference/workflows/run)
|
|
370
371
|
- [Step Class](https://mastra.ai/reference/workflows/step)
|
|
371
|
-
- [Stored Workflow Definition](https://mastra.ai/reference/workflows/stored-workflow-definition)
|
|
372
372
|
- [Workflow Class](https://mastra.ai/reference/workflows/workflow)
|
|
373
373
|
- [Workflow State Reader](https://mastra.ai/reference/workflows/workflow-state-reader)
|
|
374
374
|
- [.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent)
|
|
@@ -197,18 +197,18 @@ The `/api/workflows/run-counts` endpoint returns counts of `running` and [`suspe
|
|
|
197
197
|
}
|
|
198
198
|
```
|
|
199
199
|
|
|
200
|
-
###
|
|
200
|
+
### Dynamic workflows
|
|
201
201
|
|
|
202
|
-
|
|
202
|
+
Dynamic workflow definitions (beta) are workflows expressed as JSON, persisted through the `workflowDefinitions` storage domain, and live-registered on the running instance. See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows).
|
|
203
203
|
|
|
204
|
-
| Method | Path
|
|
205
|
-
| -------- |
|
|
206
|
-
| `GET` | `/api/stored/workflows`
|
|
207
|
-
| `GET` | `/api/stored/workflows/:
|
|
208
|
-
| `POST` | `/api/stored/workflows`
|
|
209
|
-
| `DELETE` | `/api/stored/workflows/:
|
|
204
|
+
| Method | Path | Description |
|
|
205
|
+
| -------- | ------------------------------------------ | ------------------------------------------------------------------------------ |
|
|
206
|
+
| `GET` | `/api/stored/workflows` | List dynamic workflow definitions, filterable by `status` and `authorId` |
|
|
207
|
+
| `GET` | `/api/stored/workflows/:dynamicWorkflowId` | Get a dynamic workflow definition by ID |
|
|
208
|
+
| `POST` | `/api/stored/workflows` | Upsert a definition (plus optional helper `dependencies`) and live-register it |
|
|
209
|
+
| `DELETE` | `/api/stored/workflows/:dynamicWorkflowId` | Delete a dynamic workflow definition and unregister the live workflow |
|
|
210
210
|
|
|
211
|
-
On authenticated servers, the read routes require the `stored-workflows:read` permission and the write routes require `stored-workflows:write`. Registered
|
|
211
|
+
On authenticated servers, the read routes require the `stored-workflows:read` permission and the write routes require `stored-workflows:write`. Registered dynamic workflows are executed through the ordinary `/api/workflows/:workflowId` routes above.
|
|
212
212
|
|
|
213
213
|
### Create run request body
|
|
214
214
|
|
|
@@ -10,15 +10,15 @@ Mastra storage is organized into domains. Each domain owns a set of tables or co
|
|
|
10
10
|
|
|
11
11
|
Not every storage adapter implements every domain. Composite storage lets you mix adapters per domain when the adapter packages export the corresponding domain classes.
|
|
12
12
|
|
|
13
|
-
| Domain | Description
|
|
14
|
-
| --------------------- |
|
|
15
|
-
| `memory` | Conversation persistence: messages, threads, and resources (including working memory).
|
|
16
|
-
| `workflows` | Workflow run snapshots used for suspend and resume.
|
|
17
|
-
| `workflowDefinitions` | Persisted [
|
|
18
|
-
| `scores` | Evaluation score records from eval runs.
|
|
19
|
-
| `observability` | Traces and spans used by observability exporters and Studio.
|
|
20
|
-
| `datasets` | Dataset records, versioned items, and dataset versions used by experiments.
|
|
21
|
-
| `experiments` | Experiment runs and per-item experiment results.
|
|
13
|
+
| Domain | Description |
|
|
14
|
+
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
|
|
15
|
+
| `memory` | Conversation persistence: messages, threads, and resources (including working memory). |
|
|
16
|
+
| `workflows` | Workflow run snapshots used for suspend and resume. |
|
|
17
|
+
| `workflowDefinitions` | Persisted [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows) definitions (beta). Loaded and live-registered on boot. |
|
|
18
|
+
| `scores` | Evaluation score records from eval runs. |
|
|
19
|
+
| `observability` | Traces and spans used by observability exporters and Studio. |
|
|
20
|
+
| `datasets` | Dataset records, versioned items, and dataset versions used by experiments. |
|
|
21
|
+
| `experiments` | Experiment runs and per-item experiment results. |
|
|
22
22
|
|
|
23
23
|
The schema definitions below cover the built-in database-backed tables documented for `memory`, `workflows`, `scores`, and `observability`. Other domains, and non-database adapters, use implementation-specific storage structures.
|
|
24
24
|
|
|
@@ -92,7 +92,7 @@ Each domain declares which of its tables can be age-pruned and which timestamp c
|
|
|
92
92
|
> - Experiments prune as whole units: an aged experiment's result rows are deleted together with it (results cascade with their parent), so a run is never left partially deleted. Retention doesn't have a separate `results` key.
|
|
93
93
|
> - For `schedules`, the growth table is the fire history (`schedule_triggers`, one row per fire): schedule definitions are config and aren't pruned.
|
|
94
94
|
> - On PostgreSQL, timestamp anchors use the timezone-aware mirror columns (for example `createdAtZ`, `completedAtZ`).
|
|
95
|
-
> - LibSQL
|
|
95
|
+
> - LibSQL and PostgreSQL support all domains above except `harness`, which PostgreSQL doesn't implement. MongoDB supports all except `threadState` and `harness`.
|
|
96
96
|
> - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
|
|
97
97
|
|
|
98
98
|
## Methods
|
package/.docs/reference/workflows/{stored-workflow-definition.md → dynamic-workflow-definition.md}
RENAMED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
> Discover all available pages from the documentation index: https://mastra.ai/llms.txt
|
|
2
2
|
|
|
3
|
-
#
|
|
3
|
+
# Dynamic workflow definition
|
|
4
4
|
|
|
5
|
-
> **Beta:**
|
|
5
|
+
> **Beta:** Dynamic workflows are in beta. Breaking changes may occur without a major version bump until the API is stable.
|
|
6
6
|
|
|
7
|
-
A
|
|
7
|
+
A dynamic workflow definition is a JSON-compatible `DynamicWorkflowGraph` accepted by [`Mastra.addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow), the stored-workflow server routes, and the Client SDK workflows API.
|
|
8
8
|
|
|
9
|
-
See [
|
|
9
|
+
See [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) for a complete setup and usage example.
|
|
10
10
|
|
|
11
11
|
## Definition fields
|
|
12
12
|
|
|
@@ -286,7 +286,7 @@ Validation errors include a dotted path, such as `graph.2.steps.0`, that identif
|
|
|
286
286
|
|
|
287
287
|
## Related
|
|
288
288
|
|
|
289
|
-
- [Use
|
|
290
|
-
- [`Mastra.
|
|
291
|
-
- [`Mastra.
|
|
289
|
+
- [Use dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows)
|
|
290
|
+
- [`Mastra.addDynamicWorkflow()`](https://mastra.ai/reference/core/addDynamicWorkflow)
|
|
291
|
+
- [`Mastra.addDynamicWorkflows()`](https://mastra.ai/reference/core/addDynamicWorkflows)
|
|
292
292
|
- [Client SDK workflows API](https://mastra.ai/reference/client-js/workflows)
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
The `.agent()` method adds an agent as a declarative step. The step accepts `{ prompt: string }` as input and returns `{ text: string }` by default. Use `.map()` before the agent to build the prompt from workflow data.
|
|
6
6
|
|
|
7
|
-
Unlike wrapping an agent with `createStep()`, `.agent()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [
|
|
7
|
+
Unlike wrapping an agent with `createStep()`, `.agent()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows).
|
|
8
8
|
|
|
9
9
|
## Usage example
|
|
10
10
|
|
|
@@ -53,10 +53,10 @@ workflow.agent("test-agent", { maxSteps: 3 }).commit();
|
|
|
53
53
|
|
|
54
54
|
## Persisting agent steps
|
|
55
55
|
|
|
56
|
-
Workflows built with `.agent()` serialize to the same declarative entries that [
|
|
56
|
+
Workflows built with `.agent()` serialize to the same declarative entries that [dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) use. Only `retries` and `metadata` round-trip through storage. Options that hold functions, such as `onFinish` or a function-valued `toolChoice`, throw an error when the workflow is stored.
|
|
57
57
|
|
|
58
58
|
## Related
|
|
59
59
|
|
|
60
60
|
- [Agents and Tools](https://mastra.ai/docs/workflows/agents-and-tools)
|
|
61
|
-
- [
|
|
61
|
+
- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows)
|
|
62
62
|
- [Workflow.tool()](https://mastra.ai/reference/workflows/workflow-methods/tool)
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
The `.tool()` method adds a tool as a declarative step. The tool's own input and output schemas apply, so the previous step's output must satisfy the tool's input schema. Use `.map()` to transform the data if they don't match.
|
|
6
6
|
|
|
7
|
-
Unlike wrapping a tool with `createStep()`, `.tool()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [
|
|
7
|
+
Unlike wrapping a tool with `createStep()`, `.tool()` records a declarative entry in the workflow graph. This makes the workflow portable: the same graph can be serialized and persisted as a [dynamic workflow](https://mastra.ai/docs/workflows/dynamic-workflows).
|
|
8
8
|
|
|
9
9
|
## Usage example
|
|
10
10
|
|
|
@@ -34,10 +34,10 @@ workflow.tool("lookup-customer", { retries: 2 }).commit();
|
|
|
34
34
|
|
|
35
35
|
## Persisting tool steps
|
|
36
36
|
|
|
37
|
-
Workflows built with `.tool()` serialize to the same declarative entries that [
|
|
37
|
+
Workflows built with `.tool()` serialize to the same declarative entries that [dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows) use. Only `retries` and `metadata` round-trip through storage. A function-valued `scorers` option throws an error when the workflow is stored.
|
|
38
38
|
|
|
39
39
|
## Related
|
|
40
40
|
|
|
41
41
|
- [Agents and Tools](https://mastra.ai/docs/workflows/agents-and-tools)
|
|
42
|
-
- [
|
|
42
|
+
- [Dynamic workflows](https://mastra.ai/docs/workflows/dynamic-workflows)
|
|
43
43
|
- [Workflow.agent()](https://mastra.ai/reference/workflows/workflow-methods/agent)
|
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,12 @@
|
|
|
1
1
|
# @mastra/mcp-docs-server
|
|
2
2
|
|
|
3
|
+
## 1.2.15-alpha.8
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- Updated dependencies [[`6445eba`](https://github.com/mastra-ai/mastra/commit/6445eba6020abac681aba1cc9289f446cb400cbe), [`df31eb0`](https://github.com/mastra-ai/mastra/commit/df31eb0c7087d782a0d9346e467f9a4af4b0eef6), [`fcd0667`](https://github.com/mastra-ai/mastra/commit/fcd0667a4e378be35c9a1b1eb19cce78fbfd7282), [`bab06b1`](https://github.com/mastra-ai/mastra/commit/bab06b18923873a584bdfc71a6b4ec7fb4727fb7)]:
|
|
8
|
+
- @mastra/core@1.58.0-alpha.5
|
|
9
|
+
|
|
3
10
|
## 1.2.15-alpha.7
|
|
4
11
|
|
|
5
12
|
### Patch Changes
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@mastra/mcp-docs-server",
|
|
3
|
-
"version": "1.2.15-alpha.
|
|
3
|
+
"version": "1.2.15-alpha.9",
|
|
4
4
|
"description": "MCP server for accessing Mastra.ai documentation, changelogs, and news.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
@@ -28,8 +28,8 @@
|
|
|
28
28
|
"jsdom": "^26.1.0",
|
|
29
29
|
"local-pkg": "^1.1.2",
|
|
30
30
|
"zod": "^4.4.3",
|
|
31
|
-
"@mastra/
|
|
32
|
-
"@mastra/
|
|
31
|
+
"@mastra/core": "1.58.0-alpha.5",
|
|
32
|
+
"@mastra/mcp": "^1.16.0-alpha.1"
|
|
33
33
|
},
|
|
34
34
|
"devDependencies": {
|
|
35
35
|
"@hono/node-server": "^2.0.0",
|
|
@@ -46,8 +46,8 @@
|
|
|
46
46
|
"typescript": "^6.0.3",
|
|
47
47
|
"vitest": "4.1.10",
|
|
48
48
|
"@internal/types-builder": "0.0.96",
|
|
49
|
-
"@
|
|
50
|
-
"@
|
|
49
|
+
"@mastra/core": "1.58.0-alpha.5",
|
|
50
|
+
"@internal/lint": "0.0.121"
|
|
51
51
|
},
|
|
52
52
|
"homepage": "https://mastra.ai",
|
|
53
53
|
"repository": {
|