Boomerang

Request intro

request_intro

Create a new warm intro request in DRAFT state. DO NOT call until every required input is collected — if anything is missing, stop and ask the user to provide it (render a labeled form UI when helpful); never call with null, empty, or guessed UUIDs. REQUIRED: target_id (contact to introduce) and requester_id (who is asking — usually the current user). STRONGLY RECOMMENDED before calling: intro_request_meta.context (why the intro is needed — business reason, goal, talking points) and target_account_id when the contact belongs to a known account. OPTIONAL intro_request_meta: is_time_sensitive, recommended_sc (preferred super connectors / referrers with keycloak_user_id + order + note), opportunity_details, form_instance_id. Creating the draft does NOT submit the request — it only starts the workflow. AFTER SUCCESS (mandatory, same turn): immediately call get_draft_by_type three times (GHOSTWRITTEN_EMAIL, FORWARDABLE_EMAIL, TEXT) with intro_request_id from the response, render editable email/text UI, and present drafts to the user — do NOT ask 'Want me to pull those up?' or wait for confirmation; fetching drafts is automatic. USER-FACING: confirm creation in plain language (person names, connector name) — never read intro_request_id UUIDs, tool names, or enum state names aloud.

Use when: Use when a user wants to request a warm introduction to a target contact AND you already have target_id and requester_id. Before calling, confirm the target contact (search_contacts or relationship tools if needed), confirm requester_id (from X-User-ID context or explicit user choice), and collect intro_request_meta.context from the user ('Why do you want this intro?'). After success: save intro_request_id internally, tell the user the intro was created, then IMMEDIATELY fetch all three drafts and show the editable UI in the same response — never stop to ask whether to fetch drafts.

workspace_id / user_id are injected from request headers.

Prerequisites (check before calling this tool): [REQUIRED] target_id (contact UUID) must be confirmed before calling. Verify: If the user named a person but did not provide a UUID, search contacts or use relationship_intelligence tools to find the target, present the best match (name, title, company), and get explicit confirmation ('Is this the person you want an intro to?') before using their contact UUID as target_id. [REQUIRED] requester_id (workspace user UUID) must be known before calling. Verify: Prefer the authenticated user from request context (X-User-ID). If acting on behalf of someone else, resolve via search_workspace_members and confirm with the user before calling. [REQUIRED] intro_request_meta.context should be collected from the user before calling. Verify: Ask: 'Why do you want this introduction?' or 'What's the goal / context for this intro?' Capture a clear business reason in intro_request_meta.context. Do not invent context — if the user has not provided it, ask before calling request_intro.

Next steps (after this tool succeeds): [REQUIRED] [ACTION] → call get_draft_by_type: IMMEDIATELY after request_intro returns — same turn, no permission prompt — call get_draft_by_type for GHOSTWRITTEN_EMAIL, FORWARDABLE_EMAIL, and TEXT using intro_request_id from the response, then render editable email/text UI. Do not ask 'Want me to pull those up?' [optional] [ACTION] → call update_draft: If the user edits any draft in the UI and clicks Save, call update_draft with is_manually_edited=true and the full edited content. [REQUIRED] [ACTION] → call intro_request_send_state_change_event: After the user has reviewed (and optionally saved edits to) all drafts, submit the intro request for admin review by firing INTRO_REQUESTED_EVENT.

Also returns pagination info (context, opportunity_details, is_time_sensitive, form_instance_id, recommended_sc, meeting_status, meeting_attribution, email_enrichment_job_id, assigned_sc, routing).

Input Schema

Name	Required	Description	Default
`target_id`	No
`requester_id`	No
`target_account_id`	No
`intro_request_meta`	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.6/5.0

Behavior4/5

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

Well beyond what readOnlyHint=false/destructiveHint=false/openWorldHint=false convey: it discloses draft-vs-submit semantics, header-injected workspace_id/user_id, the mandatory three get_draft_by_type follow-ups in the same turn, and user-facing output constraints (no UUIDs or enum states read aloud). Minor deduction for the closing sentence 'Also returns pagination info (context, opportunity_details, ...)' — a create call returns the created request, not pagination, so that tail mischaracterizes the response and could prime the agent to look for paging that isn't there.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and sectioned, but the same guidance is delivered three times: the mandatory post-success get_draft_by_type sequence appears in the main paragraph, again in 'Use when', and again under 'Next steps'; likewise target/requester/context confirmation is stated in the body and then restated in Prerequisites. The 'render editable UI' / 'never ask Want me to pull those up?' instruction is repeated verbatim twice. Roughly a third of the text is redundant.

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 spelled out, and everything an agent must know to call this correctly — required IDs, how to resolve them, what meta to gather, the draft-does-not-submit boundary, and the mandatory same-turn follow-up chain through update_draft to intro_request_send_state_change_event — is present. No blocking gap remains.

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 description coverage is 0%, so the description carries the whole burden and does so: target_id is 'contact to introduce', requester_id is 'who is asking — usually the current user', target_account_id applies 'when the contact belongs to a known account', and every nested intro_request_meta key is enumerated (context, is_time_sensitive, recommended_sc with keycloak_user_id + order + note, opportunity_details, form_instance_id). It also correctly states that workspace_id/user_id come from headers rather than the caller.

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, resource and resulting state: 'Create a new warm intro request in DRAFT state', and immediately clarifies the state boundary ('does NOT submit the request'). That single clause separates it from siblings like intro_request_send_state_change_event, update_draft and search_intro_request without opening their 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?

There is an explicit 'Use when' with a positive condition (user wants a warm intro AND target_id and requester_id are known), a negative condition ('DO NOT call until every required input is collected'), and named alternatives for the resolution step (search_contacts, relationship_intelligence tools, search_workspace_members). The when/when-not/alternative triad is fully covered.

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?