Capable

Manage approval queue

manage_approvals

Destructive

Admin-only governance queue for requests held by policy/autonomy. list returns captured tool/args, target, requester, reason, review/source, status and expiry; filter by status. autonomy returns role/source levels and evidence over days (default90); configure via update_workspace.autonomy_by_role. approve records a decision and RUNS the captured call as its original requester; execution may be applied, failed, expired or uncertain. For an uncertain outcome, inspect the affected record before a new request. deny closes without running. Either decision stores an optional note and requires confirm:true after previewing tool, target, requester and age. Requesters cannot decide their own requests. A require_approval policy on this tool blocks it; queue operations never queue themselves.

When to use: An admin reviews held requests or evidence before changing autonomy.

Example: What's waiting for my approval?

Input Schema

Name	Required	Description
`id`	No	The request id to approve or deny (from a list call). Ignored by list.
`days`	No	autonomy only: evidence window in days (default 90).
`note`	No	Optional decision note stored with an approve or deny.
`limit`	No	list only: how many requests to return, newest first (default 50, max 200).
`action`	Yes	list the queue, approve / deny one request by id, or autonomy: the posture with its evidence. One of: list \| approve \| deny \| autonomy.
`status`	No	list only: return requests in exactly this status (pending, approved, executing, indeterminate, denied, expired, applied, failed); omit for every status.
`confirm`	No	approve / deny: true carries the decision out; omitted or false returns the preview and changes nothing.

Output Schema

Name	Required	Description	Default
`note`	No
`count`	No
`action`	No
`levels`	No
`decided`	No
`sources`	No
`approval`	No
`evidence`	No
`approvals`	No
`execution`	No
`approval_id`	No
`window_days`	No
`autonomy_by_role`	No
`requires_confirm`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 26, 2026

changedInput schema / properties / action / description

Previous value: -"list the queue, or approve / deny one request by id. One of: list | approve | deny."New value: +"list the queue, approve / deny one request by id, or autonomy: the posture with its evidence. One of: list | approve | deny | autonomy."

addedInput schema / properties / days

Added value: +{
+  "description": "autonomy only: evidence window in days (default 90).",
+  "type": [
+    "number",
+    "string"
+  ]
+}

changedOutput schema / properties / action / enum

Previous value: -[
-  "list",
-  "approve",
-  "deny"
-]New value: +[
+  "list",
+  "approve",
+  "deny",
+  "autonomy"
+]

addedOutput schema / properties / autonomy_by_role
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / evidence

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / levels
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / sources
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / window_days

Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

Changed4 schema fields changedOct 24, 2026

removedInput schema / properties / confirm / anyOf

Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]

addedInput schema / properties / confirm / type

Added value: +[
+  "boolean",
+  "string",
+  "number"
+]

removedInput schema / properties / limit / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  }
-]

addedInput schema / properties / limit / type

Added value: +[
+  "number",
+  "string"
+]

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed6 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / approval / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / approval / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / approvals / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / approvals / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond annotations: approve actually executes the captured call as the original requester, outcomes can be applied/failed/expired/uncertain, deny closes without executing, confirm:true is required after previewing, requesters cannot decide their own requests, and a require_approval policy on this tool blocks it while queue operations never queue themselves. These are exactly the safety facts the destructiveHint/readOnlyHint flags cannot convey, and nothing contradicts those annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph, but it is front-loaded (purpose first, then per-action semantics, then constraints, then when-to-use and example). Sentences earn their place, though the mid-paragraph shift into approve/deny mechanics could be split for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers a multi-action, destructive, execution-triggering tool end to end: allowed actions, decision prerequisites, execution side effects and their uncertain states, authorization limits, and self-recursion behavior. With an output schema and annotations already present, nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still adds decision-relevant meaning by explaining the two-phase confirm flow ('requires confirm:true after previewing tool, target, requester and age') and that an uncertain outcome requires inspecting the affected record first. Defaults for days/limit are left to the schema, which is fine.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first clause names the resource and scope precisely: an admin-only governance queue for requests held by policy/autonomy. Each action is then defined by what it does (list returns captured tool/args..., approve records a decision and runs the captured call, deny closes without running), which no sibling tool offers. An agent can distinguish this from review_proposed_updates, get_review_status, or update_workspace without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to use: An admin reviews held requests or evidence before changing autonomy' plus a concrete example question routes the agent correctly, and it names update_workspace.autonomy_by_role as the place to configure rather than manage. It stops short of stating negative cases (e.g. non-admin callers, or queueing a request instead of deciding one), so it is strong but not complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Capable tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?