Skip to main content
Glama

posterly

by ly.poster
OverviewDiscussionsAdmin

manage_workspace_member

Destructive

Invite, update, or remove a workspace colleague. This SENDS EMAILS and CHANGES WHO CAN ACCESS the workspace. Works with an API key that has the Manage team permission or an OAuth connection; the user must be a workspace owner or admin. ALWAYS preview first: call without confirm, show it, and call again with confirm: true and the preview_id only after the user explicitly approves. action=invite: email and role required (publisher, editor or viewer), optional brand_ids and resend; always sends a pending invite email, never adds anyone instantly. action=update: member_id or invite_id (from list_workspace_members) plus role and/or brand_ids; or member_id plus api_access (true or false, on its own) to turn API and AI app access on or off for that teammate, which lets them use the workspace API plan from their own keys and AI apps (off by default; you cannot change your own; only the owner can change it for an admin; turning it off stops their keys, AI app connections and webhooks for this workspace). action=remove: member_id (removes the teammate and revokes their API keys for this workspace) or invite_id (cancels a pending invite). Admin seats can only be granted in the posterly dashboard. The workspace owner is emailed about every change. For action=invite with confirm, reuse idempotency_key if the response is lost.

Input Schema

NameRequiredDescriptionDefault
roleNoaction=invite (required) or action=update: publisher, editor, or viewer.
emailNoaction=invite only: the colleague email address.
actionYesinvite, update, or remove.
resendNoaction=invite only: email an unchanged pending invite again.
confirmNoLeave out to get a preview. Set true only after the user explicitly approved it, with the preview_id.
brand_idsNoaction=invite or action=update: limit the seat to these brand IDs (from list_brands). Empty array means every brand. Omit on update to keep the current brands.
invite_idNoaction=update or action=remove: a pending invite ID from list_workspace_members.
member_idNoaction=update or action=remove: a member ID from list_workspace_members.
api_accessNoaction=update with member_id only, on its own: true turns API and AI app access on; false turns it off.
preview_idNoThe preview_id returned by the preview call. Required with confirm: true.
workspace_idYesWorkspace ID (from whoami).
idempotency_keyNoaction=invite with confirm: reuse this key if the response is lost. If omitted, an identical confirm within about 10 minutes replays the first result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "action=invite with confirm: reuse this key if the response is lost. If omitted, an identical confirm within about 10 minutes replays the first result.",
+  "maxLength": 255,
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / api_access / description
      Previous value: -"action=update with member_id only, on its own: true lets the teammate use this workspace's API plan from their own keys and AI apps; false turns it off."New value: +"action=update with member_id only, on its own: true turns API and AI app access on; false turns it off."
    • changedInput schema / properties / confirm / description
      Previous value: -"Leave out to get a preview. Set true only after the user explicitly approved the preview, together with preview_id."New value: +"Leave out to get a preview. Set true only after the user explicitly approved it, with the preview_id."
    • changedInput schema / properties / role / description
      Previous value: -"action=invite (required) or action=update: publisher, editor, or viewer. Admin is dashboard-only."New value: +"action=invite (required) or action=update: publisher, editor, or viewer."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/non-idempotent, but the description adds substantive consequences: emails are sent, access changes, invites never add instantly, removal revokes API keys, api_access=false kills keys, AI app connections and webhooks, owner is emailed on every change, and self/admin edits are restricted. It also discloses the ~10 minute replay window, which nuances rather than contradicts idempotentHint=false.

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-loading is excellent — the email/access warning and preview protocol come before any parameter detail. However it is a single dense block of semicolon-clause sentences running ~330 words, and significant portions duplicate schema descriptions verbatim (email/role required, member_id or invite_id sources), which bloat rather than add.

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?

For a 12-parameter destructive multi-action tool with no output schema, the description covers preconditions, side effects, the preview_id it returns, the confirm workflow, and the idempotency replay behavior. Nothing an agent needs to call it safely is missing.

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 baseline is 3; the description goes beyond it by encoding cross-field rules the schema does not state as rules — member_id plus api_access 'on its own', cannot change your own api_access, only the owner can change an admin's, and idempotency_key reuse advice for lost responses. It still largely restates the per-action applicability that the schema descriptions already carry, so it stops short of a 5.

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?

Opens with a specific verb triad and resource: 'Invite, update, or remove a workspace colleague.' It also implicitly separates itself from the read-only sibling by pointing agents to list_workspace_members as the source of member_id/invite_id, so the agent can pick correctly without reading schemas.

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?

Gives explicit when-to-use per action (invite/update/remove), the preconditions (Manage team permission or OAuth, must be workspace owner or admin), the mandatory preview-then-confirm loop, and the exclusion that admin seats can only be granted in the dashboard. Nothing about selection is left to inference.

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

All posterly 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