Capable

Manage workspace members

manage_members

Destructive

Admin-only membership controls. list returns members and pending invites. invite adds/renews an email invite (default member; existing members refused); email_sent reports best-effort delivery. resend_invite renews by invite_id; revoke_invite withdraws. set_role supports admin/manager/member/viewer, never demotes the last admin. set_manager sets/clears a manager, rejecting self-reporting and cycles. set_read_scope uses own/team/all/null (role default), optionally include_reports; cannot restrict admins. remove cannot target yourself or the last admin; records remain. Except list/revoke_invite, actions preview the person/change until confirm:true. This connection is bound to one membership; leave/switch your own workspace in the browser.

When to use: An admin manages membership, invitations or an individual's access.

Example: Invite sara@brightside.example as a manager.

Input Schema

Name	Required	Description
`role`	No	invite (default member) and set_role: admin, manager, member or viewer.
`email`	No	invite: the address to invite (lower-cased and trimmed).
`action`	Yes	list, invite, resend_invite, revoke_invite, set_role, set_manager, set_read_scope or remove. One of: list \| invite \| resend_invite \| revoke_invite \| set_role \| set_manager \| set_read_scope \| remove.
`confirm`	No	invite / resend_invite / set_role / set_manager / remove: true carries the change out; omitted or false returns the preview and changes nothing.
`user_id`	No	set_role / set_manager / remove: the member's user_id from a list call.
`invite_id`	No	resend_invite / revoke_invite: the pending invite's id from a list call.
`manager_id`	No	set_manager: the manager's user_id, or null to clear the reporting line.
`read_scope`	No	set_read_scope: own, team, all, or null to follow the role's setting.
`include_reports`	No	set_read_scope: also everyone reporting up to this member.

Output Schema

Name	Required	Description	Default
`note`	No
`action`	No
`invite`	No
`member`	No
`applied`	No
`invites`	No
`members`	No
`email_sent`	No
`requires_confirm`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 24, 2026

changedInput schema / properties / action / description

Previous value: -"list, invite, resend_invite, revoke_invite, set_role, set_manager or remove. One of: list | invite | resend_invite | revoke_invite | set_role | set_manager | remove."New value: +"list, invite, resend_invite, revoke_invite, set_role, set_manager, set_read_scope or remove. One of: list | invite | resend_invite | revoke_invite | set_role | set_manager | set_read_scope | remove."

addedInput schema / properties / include_reports

Added value: +{
+  "description": "set_read_scope: also everyone reporting up to this member.",
+  "type": [
+    "boolean",
+    "string",
+    "number"
+  ]
+}

addedInput schema / properties / read_scope

Added value: +{
+  "anyOf": [
+    {
+      "description": "One of: own | team | all.",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "set_read_scope: own, team, all, or null to follow the role's setting."
+}

changedOutput schema / properties / action / enum

Previous value: -[
-  "list",
-  "invite",
-  "resend_invite",
-  "revoke_invite",
-  "set_role",
-  "set_manager",
-  "remove"
-]New value: +[
+  "list",
+  "invite",
+  "resend_invite",
+  "revoke_invite",
+  "set_role",
+  "set_manager",
+  "set_read_scope",
+  "remove"
+]

Changed2 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"
+]

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed10 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 / invite / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / invite / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / invites / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / invites / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / member / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / member / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / members / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / members / 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?

The description adds substantial behavior beyond the annotations: list returns members and pending invites, invite refuses existing members, email delivery is best-effort, set_role never demotes the last admin, set_manager rejects self-reporting and cycles, set_read_scope cannot restrict admins, remove cannot target self or last admin, and destructive actions preview until confirm:true. These are meaningful mutation and constraint details for a destructive tool.

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?

The description is dense but appropriately sized for a nine-parameter, multi-action administrative tool, and it front-loads the admin-only scope before enumerating action behavior. The semicolon-heavy action list is efficient but slightly reduces scanability, so it is strong rather than perfect.

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?

Given the tool's complexity, destructive annotations, 100% schema coverage, and output schema, the description covers the essential admin restrictions, action semantics, confirmation preview behavior, and workspace-bound limitation. An agent has enough context to select and invoke the correct action without needing return-value details in the description.

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 schema already defines all parameters; the description still adds action-level semantics such as invite defaulting to member, manager_id null clearing a reporting line, read_scope null following role defaults, and confirm returning a preview unless true. This is useful cross-parameter guidance, though much of it is also present in the schema descriptions.

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 description states a specific resource and verb set: admin-only membership controls, with each action named (list, invite, revoke, set_role, set_manager, set_read_scope, remove). It clearly distinguishes this as membership/invitation/access management rather than generic record or billing management.

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?

It gives clear usage context: "When to use: An admin manages membership, invitations or an individual's access," plus an example invite. It does not explicitly compare alternatives or exclusions, but the admin-only scope and action list make the intended context clear.

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?