GrowSurf MCP Server

Official

by growsurf

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Email Participant

growsurf_email_participant

Destructive

Send an email to a GrowSurf participant by ID or email using a program template or custom subject and body, with compliance details added automatically.

Instructions

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). 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 Campaign 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

TableJSON 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. Referral programs: `welcomeNonReferred`, `referralLinkViewedFirstTime`, `referralLinkUsed`, `referredSignup`, `welcomeReferred`, `goalAchieved`, `campaignEndedWinners`, `campaignEndedNonWinners`, `progressUpdateMonthly`. Affiliate programs: `welcomeNonReferred`, `referralLinkViewedFirstTime`, `referredSignup`, `commissionGenerated`, `commissionAdjusted`, `payoutPending`, `payoutSentSuccess`, `progressUpdateMonthly`.
`preheader`	No
`campaignId`	No	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

TableJSON 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.

Changed1 schema field changedv0.19.9Oct 3, 2026

changedInput schema / properties / campaignId / description

Previous value: -"Target program (campaign) id for this call. Defaults to GROWSURF_CAMPAIGN_ID when omitted. Pass the `id` returned by growsurf_create_campaign to configure or operate a program you just created, without restarting the server."New value: +"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."

First observedv0.12.2Aug 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (destructive, non-idempotent, open-world), the description discloses real behavior: automatic compliance injection (company name, postal address, unsubscribe link), suppression of unsubscribed participants, the verification prerequisite with a 400 failure mode, and that delivery is only 'accepted' rather than confirmed. This is meaningful context an agent could not infer from structured 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?

The action is front-loaded in the first clause, then mode selection, then compliance/prerequisites, then targeting default. Dense but every sentence carries information; it reads as a single long paragraph rather than clearly separated clauses.

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?

For a 7-parameter, no-required-field mutation tool with an output schema, the description covers the required pieces: mode selection, addressing, defaults, prerequisites, error behavior, and post-send semantics. Return-value documentation is correctly left to the output schema.

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 only 57%, and the description compensates: it explains the emailType/subject+body exclusivity in prose, clarifies participantId vs participantEmail as alternatives, mentions the optional preheader that has no schema description, and confirms the campaignId fallback to GROWSURF_CAMPAIGN_ID.

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?

The description opens with a specific verb and resource ('Send an email to a participant') and immediately names the two addressing options (participant ID or email), which clearly separates it from sibling participant tools like get_participant or update_participant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

It gives strong context for the two mutually exclusive modes ('Provide EITHER emailType ... OR subject + body') and states the prerequisites for sending (verified team, verified custom email domain, 400 until verified). It stops short of explicit when-not-to-use exclusions in the description itself, since the unsendable template list lives in the schema.

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

Deploy Server