@mastra/mcp-docs-server 1.1.49-alpha.1 → 1.1.49-alpha.2
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/harness/modes.md +116 -0
- package/.docs/docs/harness/overview.md +129 -0
- package/.docs/docs/harness/session.md +136 -0
- package/.docs/docs/harness/subagents.md +109 -0
- package/.docs/docs/harness/threads-and-state.md +134 -0
- package/.docs/docs/harness/tool-approvals.md +145 -0
- package/.docs/reference/harness/harness-class.md +124 -186
- package/.docs/reference/harness/session.md +429 -0
- package/.docs/reference/index.md +1 -0
- package/CHANGELOG.md +7 -0
- package/package.json +4 -4
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
# Tool approvals and permissions
|
|
2
|
+
|
|
3
|
+
The Harness provides a permission system that controls which tools require user approval before execution. You can configure policies at the category level or per-tool, and grant session-wide exceptions for trusted tools.
|
|
4
|
+
|
|
5
|
+
## When to use tool approvals
|
|
6
|
+
|
|
7
|
+
Use tool approvals when agents have access to destructive or sensitive tools (file writes, command execution, API calls) and you want a human-in-the-loop checkpoint before those tools run.
|
|
8
|
+
|
|
9
|
+
## Permission policies
|
|
10
|
+
|
|
11
|
+
Three policies control tool behavior:
|
|
12
|
+
|
|
13
|
+
- `allow`: The tool runs without prompting
|
|
14
|
+
- `ask`: The tool pauses and emits a `tool_approval_required` event; the user must approve or decline
|
|
15
|
+
- `deny`: The tool is blocked from execution
|
|
16
|
+
|
|
17
|
+
### Setting policies
|
|
18
|
+
|
|
19
|
+
Set policies per-category or per-tool. Per-tool policies take precedence over category policies:
|
|
20
|
+
|
|
21
|
+
```typescript
|
|
22
|
+
// Category-level: all execute tools require approval
|
|
23
|
+
harness.setPermissionForCategory({ category: 'execute', policy: 'ask' })
|
|
24
|
+
|
|
25
|
+
// Tool-level: this specific tool is always blocked
|
|
26
|
+
harness.setPermissionForTool({ toolName: 'dangerous_tool', policy: 'deny' })
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
### Tool categories
|
|
30
|
+
|
|
31
|
+
The `toolCategoryResolver` maps tool names to categories. Pass it to the Harness constructor:
|
|
32
|
+
|
|
33
|
+
```typescript
|
|
34
|
+
const harness = new Harness({
|
|
35
|
+
id: 'my-agent',
|
|
36
|
+
toolCategoryResolver: toolName => {
|
|
37
|
+
if (toolName.includes('write') || toolName.includes('delete')) return 'edit'
|
|
38
|
+
if (toolName.includes('execute')) return 'execute'
|
|
39
|
+
return 'read'
|
|
40
|
+
},
|
|
41
|
+
})
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Built-in categories are `read`, `edit`, `execute`, `mcp`, and `other`.
|
|
45
|
+
|
|
46
|
+
## Responding to approval requests
|
|
47
|
+
|
|
48
|
+
When a tool's policy is `ask`, the Harness emits a `tool_approval_required` event. Your UI should display a prompt and call `session.respondToToolApproval()`:
|
|
49
|
+
|
|
50
|
+
```typescript
|
|
51
|
+
harness.subscribe(event => {
|
|
52
|
+
if (event.type === 'tool_approval_required') {
|
|
53
|
+
// Show approval UI...
|
|
54
|
+
harness.session.respondToToolApproval({ decision: 'approve' })
|
|
55
|
+
}
|
|
56
|
+
})
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
The `decision` field accepts `'approve'`, `'decline'`, or `'always_allow_category'`. When `always_allow_category` is used, the tool's category is granted for the rest of the session. Future tools in the same category are auto-approved.
|
|
60
|
+
|
|
61
|
+
```typescript
|
|
62
|
+
harness.session.respondToToolApproval({ decision: 'always_allow_category' })
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
## Session grants
|
|
66
|
+
|
|
67
|
+
The Harness owns permission _policy_ (which categories require approval); the [`Session`](https://mastra.ai/docs/harness/session) owns the _grants_ a user makes during a conversation. Grant a category or tool for the rest of the session so it runs without further prompting:
|
|
68
|
+
|
|
69
|
+
```typescript
|
|
70
|
+
// Grant all edit tools for this session
|
|
71
|
+
harness.session.grantCategory('edit')
|
|
72
|
+
|
|
73
|
+
// Grant a specific tool
|
|
74
|
+
harness.session.grantTool('mastra_workspace_execute_command')
|
|
75
|
+
|
|
76
|
+
// Check current grants
|
|
77
|
+
const grants = harness.session.getGrants()
|
|
78
|
+
// { categories: ['edit'], tools: ['mastra_workspace_execute_command'] }
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Tool suspensions
|
|
82
|
+
|
|
83
|
+
Interactive built-in tools (`ask_user`, `submit_plan`) use the native tool-suspension primitive instead of the approval flow. They emit a `tool_suspended` event with `toolCallId`, `toolName`, and `suspendPayload`. Resume with `respondToToolSuspension()`:
|
|
84
|
+
|
|
85
|
+
```typescript
|
|
86
|
+
harness.subscribe(event => {
|
|
87
|
+
if (event.type === 'tool_suspended' && event.toolName === 'ask_user') {
|
|
88
|
+
const { question } = event.suspendPayload as { question: string }
|
|
89
|
+
// Show question to user, then resume:
|
|
90
|
+
harness.respondToToolSuspension({
|
|
91
|
+
toolCallId: event.toolCallId,
|
|
92
|
+
resumeData: 'User response here',
|
|
93
|
+
})
|
|
94
|
+
}
|
|
95
|
+
})
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
### Plan approval
|
|
99
|
+
|
|
100
|
+
The `submit_plan` tool suspends via the same mechanism. Resume with an `action` field:
|
|
101
|
+
|
|
102
|
+
```typescript
|
|
103
|
+
// Approve the plan
|
|
104
|
+
harness.respondToToolSuspension({
|
|
105
|
+
toolCallId: event.toolCallId,
|
|
106
|
+
resumeData: { action: 'approved' },
|
|
107
|
+
})
|
|
108
|
+
|
|
109
|
+
// Reject with feedback
|
|
110
|
+
harness.respondToToolSuspension({
|
|
111
|
+
toolCallId: event.toolCallId,
|
|
112
|
+
resumeData: { action: 'rejected', feedback: 'Needs more detail' },
|
|
113
|
+
})
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
## Built-in tools
|
|
117
|
+
|
|
118
|
+
The Harness provides these built-in tools to agents in every mode:
|
|
119
|
+
|
|
120
|
+
| Tool | Description |
|
|
121
|
+
| --------------- | ------------------------------------------------------------------- |
|
|
122
|
+
| `ask_user` | Ask the user a question (free text, single-select, or multi-select) |
|
|
123
|
+
| `submit_plan` | Submit a plan for user review and approval |
|
|
124
|
+
| `task_write` | Create or replace a structured task list |
|
|
125
|
+
| `task_update` | Update one tracked task by ID |
|
|
126
|
+
| `task_complete` | Mark one tracked task completed |
|
|
127
|
+
| `task_check` | Check task list completion status |
|
|
128
|
+
| `subagent` | Spawn a focused subagent (requires `subagents` config) |
|
|
129
|
+
|
|
130
|
+
Disable specific built-in tools with `disableBuiltinTools`:
|
|
131
|
+
|
|
132
|
+
```typescript
|
|
133
|
+
const harness = new Harness({
|
|
134
|
+
id: 'no-plans',
|
|
135
|
+
disableBuiltinTools: ['submit_plan'],
|
|
136
|
+
})
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
## Related
|
|
140
|
+
|
|
141
|
+
- [Harness overview](https://mastra.ai/docs/harness/overview)
|
|
142
|
+
- [Session](https://mastra.ai/docs/harness/session)
|
|
143
|
+
- [Subagents](https://mastra.ai/docs/harness/subagents)
|
|
144
|
+
- [Agent approval](https://mastra.ai/docs/agents/agent-approval)
|
|
145
|
+
- [API reference](https://mastra.ai/reference/harness/harness-class)
|