Skip to main content
Glama
rawtreedb

RawTree MCP Server

Official
by rawtreedb

Remove Organization Member

remove-organization-member
Destructive

Remove an accepted member from a RawTree organization and revoke their access, using the organization and member user ID. Confirms removal; prevents removing the last admin.

Instructions

Purpose: Remove an accepted member from a RawTree organization and revoke their organization access.

Returns: Whether the member was removed.

NOT for: Revoking a pending invitation. Use list-organization-members to identify an accepted member and obtain their user ID.

Auth: Requires a user credential with organization admin access. Authorization is enforced by the RawTree API. RawTree prevents removing the last organization admin.

Safety: This revokes the member's access to the organization. You MUST confirm the exact organization and member with the user before calling this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userIdYesMember user ID returned by list-organization-members.
organizationYesOrganization containing the member.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and readOnlyHint=false; the description goes well beyond them by disclosing the authorization model (organization admin, enforced by the API), a server-side guard (RawTree prevents removing the last organization admin), and a required confirmation workflow. This is exactly the extra context a destructive mutation needs.

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?

Bold-labeled sections (Purpose/Returns/NOT for/Auth/Safety) front-load the action, then the exclusions, then the risk. Four short paragraphs, each carrying distinct information with no filler.

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?

With no output schema, the description compensates by stating the return ('Whether the member was removed'). Auth, safety, alternatives, and prerequisites are all covered for a 2-parameter destructive tool.

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, but the description adds real meaning: it clarifies that userId must belong to an *accepted* member (not a pending invite) and that organization is the container being affected. That constraint affects which value is valid and is not fully captured by the schema's terse 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?

States a specific verb and resource ('Remove an accepted member from a RawTree organization') plus the effect ('revoke their organization access'). It explicitly distinguishes itself from the sibling list-organization-members and from invitation revocation, so an agent can route correctly 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 Guidelines5/5

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

Gives an explicit exclusion ('NOT for: Revoking a pending invitation') and names the prerequisite tool (list-organization-members) needed to obtain the user ID. It also states the required credential level and a mandatory user-confirmation step, leaving no inference to the agent.

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