GrowSurf MCP Server

Official

by growsurf

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Get Program Emails

growsurf_get_campaign_emails

Read-onlyIdempotent

Fetch the complete email configuration for a GrowSurf program, including participant and admin templates. Target a specific program by passing a campaignId, or rely on the default campaign.

Instructions

Fetch the Emails tab configuration for your GrowSurf program (participant and admin email templates and settings). Returns the full object with every field and its current value — the same shape you send back on update. Targets campaignId if you pass it, otherwise GROWSURF_CAMPAIGN_ID.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`campaignId`	No	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.

Output Schema

TableJSON Schema

Name	Required	Description
`invite`	No	The invitation email a participant sends to friends. `useCompanyReplyTo` sets who receives replies.
`settings`	No	Sender (`sender`), physical contact address (`contact`), and shared design (`design`) settings. The design object includes `unsubscribeAffiliateInvite` for direct affiliate invitation emails.
`loginLink`	No	One-time sign-in link for returning participants. Transactional; its toggle cannot be changed.
`goalAchieved`	No	Sent when a participant unlocks a reward. Referral programs only.
`offerClaimed`	No	Sent when a referred visitor saves an offer through the Claim Offer Popup. Referral and affiliate programs. Promotional; its toggle can be changed.
`payoutPending`	No	Sent when a payout is on the way. Affiliate programs only.
`referredSignup`	No	Sent to a referrer each time someone signs up using their link. Referral and affiliate programs.
`taxInfoMissing`	No	Asks a participant to submit required tax information. Transactional; its toggle cannot be changed.
`inviteAffiliate`	No	Invites a prospective affiliate to join the program. Its body must keep `{{affiliateInviteLink}}`. Affiliate programs only. Promotional; its toggle can be changed.
`taxInfoApproved`	No	Tells a participant their tax form is complete and approved. Transactional; its toggle cannot be changed.
`taxInfoReceived`	No	Confirms submitted tax information was received. Transactional; its toggle cannot be changed.
`taxInfoRejected`	No	Tells a participant their tax information needs to be resubmitted. Transactional; its toggle cannot be changed.
`welcomeReferred`	No	Welcome email for someone who signs up through a referral link. Referral programs only.
`referralLinkUsed`	No	Sent to a referrer when they earn referral credit. Referral programs only.
`payoutSentSuccess`	No	Sent when a payout completes. Affiliate programs only.
`commissionAdjusted`	No	Sent when a commission is adjusted after a refund or chargeback. Affiliate programs only.
`welcomeNonReferred`	No	Welcome email for a participant who joins without being referred. Referral and affiliate programs.
`commissionGenerated`	No	Sent to an affiliate when they earn a new commission. Affiliate programs only.
`campaignEndedWinners`	No	Sent to reward winners when the program ends. Referral programs only.
`progressUpdateMonthly`	No	Month-end progress recap for participants. Referral and affiliate programs.
`campaignEndedNonWinners`	No	Sent to non-winners when the program ends. Referral programs only.
`payoutDestinationChanged`	No	Tells a participant their payout destination changed. Its body must keep `{{payoutDestinationMaskedEmail}}`. Referral and affiliate programs. Transactional; its toggle cannot be changed.
`affiliateApplicationDenied`	No	Tells an applicant their affiliate application was not approved. Affiliate programs only. Transactional; its toggle cannot be changed.
`referralLinkViewedFirstTime`	No	Sent the first time a participant's referral link is viewed. Referral and affiliate programs.
`affiliateApplicationApproved`	No	Tells an applicant their affiliate application was approved. Affiliate programs only. Transactional; its toggle cannot be changed.
`affiliateApplicationReceived`	No	Confirms an affiliate application was received and is under review. Affiliate programs only. Transactional; its toggle cannot be changed.
`payoutDestinationConfirmation`	No	Asks a participant to confirm the payout destination where they will receive payouts, such as a PayPal or Wise email address. Its body may use `{{payoutProvider}}` and must keep `{{payoutDestinationConfirmationLink}}`. Referral and affiliate programs. Transactional; its toggle cannot be changed.
`affiliateApplicationStatusLink`	No	Sends an applicant a secure link to view their application status. Its body must keep `{{applicationStatusLink}}`. Affiliate programs only. Transactional; its toggle cannot be changed.
`affiliateEmailChangeVerification`	No	Asks an affiliate to confirm a new account email address. Its body must contain `{{identityVerificationLink}}`. Affiliate programs only. Transactional; its toggle cannot be changed.
`affiliateApplicationEmailCorrection`	No	Asks an applicant to confirm a corrected email address. Its body must contain `{{identityVerificationLink}}`. Affiliate programs only. Transactional; its toggle cannot be changed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.14.0Sep 10, 2026

addedOutput schema / properties / offerClaimed

Added value: +{
+  "description": "Sent when a referred visitor saves an offer through the Claim Offer Popup. Referral and affiliate programs. Promotional; its toggle can be changed.",
+  "type": "object"
+}

First observedv0.12.2Aug 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it returns the full object with every field and current value, the shape matches the update payload, and the campaignId defaults to GROWSURF_CAMPAIGN_ID when omitted. No contradiction with annotations.

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

Conciseness5/5

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

Three tightly written sentences with no wasted words. The core action and scope are front-loaded, followed by the return shape and defaulting behavior. Every sentence adds necessary information.

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 simple read-only tool with one optional parameter, full schema coverage, an output schema, and safety-related annotations, the description is complete. It tells the agent what is returned, how the parameter behaves, and how the result relates to updates. Nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100% for the single campaignId parameter, and the schema already explains the default behavior and the relationship to growsurf_create_campaign. The description repeats the defaulting behavior but does not meaningfully add beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb ('Fetch') and a specific resource ('Emails tab configuration for your GrowSurf program'), and clarifies the scope as participant and admin email templates and settings. It clearly differentiates this read tool from related siblings like growsurf_get_campaign and growsurf_update_campaign_emails by naming the exact configuration area and noting the returned object is the same shape used on update.

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?

The description clearly establishes this tool is for reading the current Emails tab configuration, and the phrase 'the same shape you send back on update' implicitly points to growsurf_update_campaign_emails as the companion write tool. It does not explicitly name alternatives or list when not to use it, but the usage context is clear enough for an agent to select it correctly.

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

Deploy Server