Skip to main content
Glama
Sign In

Dock

by ai.trydock
OverviewDiscussionsAdmin

remove_workspace_member

Remove a workspace member, or revoke a pending invite by passing its invite id as member_id. Editor role required; owner-tier removals require an owner caller. Sole-owner removal is blocked; promote someone else first. Note: if the workspace visibility is org, removing an explicit member of the same org leaves them with virtual editor access via the org-membership branch. Consent-gated for agents: the FIRST call returns { status: 'confirmation_required', confirm_token, message, expires_in }. Surface the message to your user and, if they say yes, re-call this tool within 60s with confirm_token set to the same token. User callers (cookie session) skip the consent step.

Input Schema

NameRequiredDescriptionDefault
slugYesThe workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace') as shown in the dashboard URL; both resolve to the same workspace.
member_idYesThe WorkspaceMember id to remove (from list_workspace_members), or a pending invite id to revoke (the `invite.id` that share_workspace returned).
confirm_tokenNoThe token returned by the first call as `confirm_token`. Omit on the first call; include on the second call to execute the removal. Single-use, 60s TTL. Agents only; user callers don't need this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / member_id / description
      Previous value: -"The WorkspaceMember id to remove. Get this from list_workspace_members."New value: +"The WorkspaceMember id to remove (from list_workspace_members), or a pending invite id to revoke (the `invite.id` that share_workspace returned)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / confirm_token / description
      Previous value: -"The token returned by the first call as `confirm_token`. Omit on the first call; include on the second call to execute the removal. Single-use, 60s TTL. Agents only — user callers don't need this."New value: +"The token returned by the first call as `confirm_token`. Omit on the first call; include on the second call to execute the removal. Single-use, 60s TTL. Agents only; user callers don't need this."
    • changedInput schema / properties / slug / description
      Previous value: -"The workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace') as shown in the dashboard URL — both resolve to the same workspace."New value: +"The workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace') as shown in the dashboard URL; both resolve to the same workspace."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: permission requirements, a non-obvious consequence in org-visibility workspaces (removal leaves virtual editor access via org membership), the sole-owner block, and the exact confirmation-required response shape with a 60s single-use token. It also states that cookie-session callers skip consent entirely.

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?

Front-loaded with the action and the invite-revocation scope, then permissions, then the consent protocol. It is dense and every sentence carries information, though the consent paragraph is long enough to be slightly sprawling.

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?

For a destructive, unannotated mutation with no output schema, the description covers permissions, the key edge case, and the confirmation handshake. It does not say what happens to resources the removed member owned, or whether removal can be undone by re-inviting, which would round out the picture.

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 coverage is 100%, so the schema already documents slug forms, member_id (including the invite-id case) and confirm_token semantics. The description reinforces the confirm_token workflow but adds little parameter detail the schema does not already contain, so the 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 and resource plus the dual scope: removing a member or revoking a pending invite via the same call. It is clearly separable from update_workspace_member, list_workspace_members and share_workspace, which appear as siblings.

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

Usage Guidelines5/5

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

Explicit conditions are given: Editor role for ordinary removals, owner caller for owner-tier removals, and sole-owner removal is blocked with the remedy (promote someone else first). The agent-vs-user-caller split and the two-call consent path are spelled out as the required procedure.

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

All Dock toolsInspect
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