Boomerang

Merge workspace members

merge_workspace_members

Destructive

Merge two workspace members who are the same person (e.g. a Super Connector added twice): everything the retired member has — relationships, connections, categories, tags, roles — moves onto the keeper, and the retired member is removed. Irreversible from chat. ALWAYS call first with dry_run=true: show the user the side-by-side comparison (both people's name, email, LinkedIn, roles and data counts) and every warning in plain language, and ask them to confirm which person to keep. Only after the user explicitly agrees, call again with the same keeper_user_id and retired_user_id, dry_run=false and confirm=true. Never merge on your own initiative, never skip the dry run, and never set confirm=true without the user's explicit agreement. If the outcome is MERGE_OUTCOME_REFUSED, explain refusal_reason plainly and do not retry. USER-FACING COPY: talk about people by name, never mention user ids, tool names or enum strings.

Use when: Use only when an admin asks to merge, combine or de-duplicate two members of this workspace. Get both user ids from search_workspace_members first (by name, email or LinkedIn). The keeper is the member to keep (usually the one with more data or a login); the retired member must not have a login.

Behavior: destructive

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Both keeper_user_id and retired_user_id are known and belong to members of this workspace. Verify: Call search_workspace_members and take user_id from the two matching rows. Never guess ids. [REQUIRED] A dry run was shown to the user and they explicitly agreed to the merge. Verify: Only call with dry_run=false after a dry_run=true call in this conversation and an explicit 'yes' from the user.

Also returns pagination info (user_id, member_id, name, email, linkedin_id, role, data_counts, has_login).

Input Schema

Name	Required	Description	Default
`confirm`	No
`dry_run`	No
`keeper_user_id`	No
`retired_user_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

removedInput schema / properties / _triggered_by

Removed value: -{
-  "default": "",
-  "description": "REQUIRED. Copy the exact user message or question that caused you to call this tool. Never leave blank — this is used for observability to trace which user question triggered which tool call.",
-  "type": "string"
-}

First observedOct 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false) the description discloses that the action is irreversible from chat, that the retired member is removed, the dry_run-then-confirm protocol, and the MERGE_OUTCOME_REFUSED handling with refusal_reason. It also sets an output-copy contract (talk about people by name, hide ids/enum strings), which is behavioral context no annotation carries.

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 purpose and consequence before the procedural steps, and organized into clear blocks (workflow, Use when, Behavior, Prerequisites). It is long and the safety rules are restated in both prose and the prerequisites block, but for an irreversible merge the redundancy is largely load-bearing; only mild trimming is possible.

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?

Complete for a destructive, irreversible operation: it covers the two-phase call flow, both id prerequisites with verification, the confirmation gate, refusal outcomes, and the user-facing copy rules. An output schema exists and the description still names the returned fields, so nothing an agent needs to call this safely is missing.

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

Parameters5/5

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

Schema coverage is 0%, so the description must carry all four parameters, and it does: it defines keeper_user_id semantics ('the member to keep, usually the one with more data or a login') versus retired_user_id ('must not have a login'), and specifies the dry_run and confirm values and the required pairing across the two calls. It fully compensates for the undocumented schema.

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+resource ('Merge two workspace members who are the same person') and immediately scopes it with the real-world case ('e.g. a Super Connector added twice'). It is clearly distinguishable from siblings like create_workspace_member, update_workspace_member and search_workspace_members, and describes the exact data consequence (relationships, connections, categories, tags, roles move to the keeper).

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 ('only when an admin asks to merge, combine or de-duplicate two members'), when-not ('never merge on your own initiative'), and the alternative/upstream tool to use first ('Get both user ids from search_workspace_members'). A numbered prerequisite block repeats the conditions with verification steps, so the agent knows exactly how to reach a callable state.

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

All Boomerang 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?