Swarm

List approval requests

swarm_list_approval_requests

Read-onlyIdempotent

Browse human approvals by status or resource; inspect one with swarm_get_approval_request. No gate is decided.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "swarm_list_approval_requests"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size; follow next_cursor for more.
`order`	No	asc or desc; retain the same order across pages.
`cursor`	No	Previous next_cursor; keep filters and order.
`status`	No	Status filter; use values returned for this resource.
`space_id`	No	Space ID from swarm_list_spaces; omit if sole.
`resource_id`	No	Resource ID from an authorized read.
`resource_type`	No	Resource type: artifact, task or run.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 29, 2026

changedInput schema / properties / cursor / description

Previous value: -"Previous next_cursor; same filters and order."New value: +"Previous next_cursor; keep filters and order."

changedInput schema / properties / limit / description

Previous value: -"Page size."New value: +"Page size; follow next_cursor for more."

changedInput schema / properties / order / description

Previous value: -"Paging order."New value: +"asc or desc; retain the same order across pages."

addedInput schema / properties / resource_id / description
```
Added value: +"Resource ID from an authorized read."
```
addedInput schema / properties / resource_type / description
```
Added value: +"Resource type: artifact, task or run."
```

changedInput schema / properties / space_id / description

Previous value: -"Omit for a single approved Space."New value: +"Space ID from swarm_list_spaces; omit if sole."

addedInput schema / properties / status / description

Added value: +"Status filter; use values returned for this resource."

Changed4 schema fields changedOct 29, 2026
- addedInput schema / properties / cursor / description
```
Added value: +"Previous next_cursor; same filters and order."
```
- addedInput schema / properties / limit / description
```
Added value: +"Page size."
```
- addedInput schema / properties / order / description
```
Added value: +"Paging order."
```
- addedInput schema / properties / space_id / description
```
Added value: +"Omit for a single approved Space."
```
First observedOct 28, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. 'No gate is decided' reinforces the read-only nature in domain terms, but the description adds nothing about pagination, completeness of results, or next_cursor behavior that isn't already in the schema.

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

Conciseness5/5

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

A single tight sentence with the primary action first, then the sibling handoff, then the scope caveat. No filler, nothing to trim.

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

Completeness4/5

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

Seven optional params are fully documented, an output schema exists, and annotations carry the safety profile, so the short description is nearly sufficient. It could note that space_id scoping is optional or that results are cursor-paginated, leaving a small residual gap.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter documents its purpose, format and cross-page consistency. The description only repeats that filters exist (status, resource), adding no syntax or semantics beyond the schema, so baseline 3 applies.

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?

States a specific verb (browse), resource (human approvals) and filter dimensions (status or resource), and names the sibling swarm_get_approval_request for single-item inspection. An agent can distinguish list vs get without opening either 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?

Explicitly routes inspection of a single approval to swarm_get_approval_request and adds a scope caveat ('No gate is decided'), which tells the agent not to expect decision capability. No explicit statement of when not to use it beyond that, so slightly short of a 5.

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

All Swarm 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.