GrowSurf

Email Participant

growsurf_email_participant

Destructive

Send an email to a participant (by GrowSurf participant ID or email). Provide EITHER emailType to trigger one of the program's configured email templates, OR subject + body for a free-form email (optionally preheader). For programs with settings.design.layoutMode set to INLINE, body must include {{emailFooter}}; {{emailHeader}} is optional. Free-form emails are sent with the same compliance handling (company name, postal address, and an unsubscribe link are added automatically, and unsubscribed participants are suppressed). Sending requires the team to be verified by GrowSurf and a verified custom email domain on the program (set up in Program Editor > 3. Emails > Email Settings). Returns 400 until one is verified. The email is accepted for delivery. Targets campaignId if you pass it, otherwise GROWSURF_CAMPAIGN_ID.

Input Schema

Name	Required	Description
`body`	No	Free-form HTML body. You can personalize it with dynamic text, inserting `{{...}}` tokens like `{{firstName}}` or `{{shareUrl}}`. See [Guide to using dynamic text in GrowSurf emails](https://support.growsurf.com/article/213-guide-to-using-dynamic-text-in-growsurf-emails).
`subject`	No	Free-form subject. Supports dynamic text (`{{...}}` tokens), the same as the body.
`emailType`	No	The program email template to trigger. Send the camelCase key; the available types depend on the program type. The template's `isEnabled` setting controls automatic sends only, so this tool can trigger any sendable template. System and transactional types (login link, payout destination confirmation, tax) and the invite email cannot be sent. `welcomeNonReferred` can only be sent to advocates or approved, enrolled affiliates in a program that has not ended. Referral programs: `welcomeNonReferred`, `referralLinkViewedFirstTime`, `referralLinkUsed`, `referredSignup`, `welcomeReferred`, `goalAchieved`, `campaignEndedWinners`, `campaignEndedNonWinners`, `progressUpdateMonthly`. Affiliate programs: `welcomeNonReferred`, `referralLinkViewedFirstTime`, `referredSignup`, `commissionGenerated`, `commissionAdjusted`, `payoutPending`, `payoutSentSuccess`, `progressUpdateMonthly`.
`preheader`	No
`campaignId`	Yes	Target program (campaign) id for this call. Defaults to GROWSURF_CAMPAIGN_ID when omitted. Program IDs also identify newly created programs without restarting the server.
`participantId`	No
`participantEmail`	No

Output Schema

Name	Required	Description	Default
`status`	No	The email was accepted for delivery.
`success`	No	Whether the email request was accepted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only give generic flags (destructive, openWorld, non-idempotent); the description adds real operational context: auto-injected compliance footer, suppression of unsubscribed participants, the team-verification / verified-domain prerequisite, and that HTTP 400 is returned until verification exists. It also discloses the async nature ("accepted for delivery"), which the annotations do not.

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 action, then progressively adds constraints and prerequisites. It is dense and long, but nearly every sentence carries actionable constraint information; the inline enumeration of email types is verbose yet genuinely useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 restated, and the description still explains the delivery semantics and 400-failure condition. Gaps are minor: it never warns that retries may produce duplicate sends (consistent with idempotentHint=false), nor how participantId vs participantEmail resolve when both are passed.

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 57%, and the description meaningfully compensates: `emailType` must be the camelCase key, valid values are enumerated per program type, `body` must include `{{emailFooter}}` under INLINE layout mode, and `campaignId` defaults to `GROWSURF_CAMPAIGN_ID`. It does not clarify precedence if both participantId and participantEmail are supplied.

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?

Starts with a specific verb+resource: "Send an email to a participant (by GrowSurf participant ID or email)." This clearly distinguishes it from config-oriented siblings like get_campaign_emails and update_campaign_emails, which manage templates rather than send mail.

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?

Explicitly states the two mutually exclusive modes ("Provide EITHER `emailType` ... OR `subject` + `body`") and enumerates when each applies. It also lists which template types cannot be sent and the `welcomeNonReferred` eligibility rule, so an agent knows the boundaries before invoking.

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

All GrowSurf 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.