Boomerang

Add super connector

add_super_connector

Idempotent

Add a Super Connector to the workspace in one step — creates the platform user if needed, assigns the Super Connector role, and places them in the selected category (provisions category ledgers). Do NOT call create_workspace_member or add_role for this flow. For new Super Connectors: (1) call get_workspace_categories to populate a required Category dropdown (filter relationship_type SUPER_CONNECTORS), (2) render an add–Super Connector form with required fields Email, First Name, Last Name, LinkedIn ID, and Category — do NOT label any field optional, (3) on Submit call THIS tool with email, first_name, last_name, linkedin_id, and category_ids. first_name and last_name are ALWAYS required, even when promoting from an existing LinkedIn connection record — that record's name is not auto-filled server-side, so if you don't already have the person's first and last name, ask the user for them before calling; do not call this tool speculatively with required fields missing or blank. USER-FACING COPY after success: e.g. 'Jane has been added as a Super Connector.' — never expose tool or API names.

Use when: Use whenever an admin adds a new Super Connector. This is the ONLY tool for Super Connector onboarding — do NOT use create_workspace_member or add_role. Call get_workspace_categories first to load the Category dropdown. On form submit, call add_super_connector with all form values in a single call.

Behavior: idempotent

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] Super Connector category options must be loaded before rendering the form. Verify: Call get_workspace_categories and filter to relationship_type SUPER_CONNECTORS. User must select at least one category before submit.

Returns category_ledger_results[] with fields: category_id ledger_id ledger_created

IMPORTANT: If the response contains more than one record, always present the options to the user and ask them to choose before taking any follow-up action. Do not act on all results automatically.

Input Schema

Name	Required	Description	Default
`email`	No
`notes`	No
`last_name`	No
`first_name`	No
`linkedin_id`	No
`category_ids`	No
`super_connector_tier`	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.8/5.0

Behavior5/5

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

Annotations already declare idempotent/non-destructive/non-open-world, but the description adds substantial behavior beyond them: side effects (platform user creation, role assignment, ledger provisioning), a required prerequisite check, the ALWAYS-required name rule that is not auto-filled, and a warning not to call speculatively with blank fields.

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 core effect and structured into Use when / Behavior / Prerequisites / Returns sections, which is easy to scan. It loses a point for redundancy: the 'do NOT call create_workspace_member or add_role' prohibition appears twice, and the numbered form steps restate earlier content.

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?

An output schema exists, so return values need not be explained, and the description still summarizes category_ledger_results. Combined with annotations, prerequisite instructions, and the multiple-result handling rule, an agent has everything needed to invoke and follow up correctly.

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?

With 0% schema description coverage, the description carries the burden and does document five of seven params (email, first_name, last_name, linkedin_id, category_ids) including their required status and a warning about naming. However, notes and super_connector_tier are never mentioned, leaving two params completely uninterpretable.

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?

Names a specific verb+resource and elaborates the compound effect: 'Add a Super Connector... creates the platform user if needed, assigns the Super Connector role, and places them in the selected category'. It explicitly distinguishes itself from create_workspace_member and add_role, so an agent can route without opening sibling 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?

Explicit when-to-use ('Use whenever an admin adds a new Super Connector'), explicit when-not ('This is the ONLY tool... do NOT use create_workspace_member or add_role'), and an ordered pre-requisite (call get_workspace_categories first). Nothing 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 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?