GrowSurf MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

growsurf_create_campaign

Create a new GrowSurf program in draft status, pre-populated with starter content for design, emails, and settings. Only the program type is required; include goal and rewards only when specified.

Instructions

Create a new GrowSurf program (campaign) pre-populated with type-appropriate starter content, optionally with inline rewards. Starter content includes Design, Emails, Options, Installation, and GrowSurf Window defaults. Only type is required; the program is created in DRAFT status owned by the credential's bound team. currencyISO sets the program's currency (defaults to USD) and is immutable after creation. Pass goal so the share settings suit the audience; it is set here or not at all. Ask the person for the incentive rather than choosing one: leave rewards out unless they named an amount, and tell them the program starts with GrowSurf's starter rewards switched off so it awards nothing yet. Editor-tab config (design, emails, options, installation) is not accepted here. Fetch and review those config sub-resources after creation, then patch only what needs to change. Does NOT require GROWSURF_CAMPAIGN_ID. The response includes the new program id; pass it as campaignId to the other tools (or set GROWSURF_CAMPAIGN_ID) to configure and operate the program.

Input Schema

TableJSON Schema

Name	Required	Description
`goal`	No	What the program is for, which seeds share settings that suit that audience. Programs selling to businesses (`CUSTOMERS`, `USERS`, `B2B_SAAS_SELF_SERVICE`, `B2B_SAAS_ENTERPRISE`) start with the LinkedIn share button visible. Consumer, financial, education, insurance, newsletter, and waitlist programs (`B2C_SUBSCRIPTIONS`, `FINANCIAL_SERVICES`, `ONLINE_EDUCATION`, `ONLINE_INSURANCE`, `SUBSCRIBERS`, `WAITLIST`) start with it hidden. Omit `goal` and every share button keeps its standard default. Change any of it afterward with `growsurf_update_campaign_design`. Set only at creation; `growsurf_update_campaign` does not accept it.
`name`	No
`type`	Yes
`rewards`	No	Rewards to create with the program. Include this only when the person told you the amount and who funds it. Omit it and the program is seeded with starter rewards that are switched off, awarding nothing until the customer enables one. Send `[]` to start with no rewards at all.
`companyName`	No
`currencyISO`	No
`companyLogoImageUrl`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.14.0Sep 10, 2026

addedInput schema / properties / goal

Added value: +{
+  "description": "What the program is for, which seeds share settings that suit that audience. Programs selling to businesses (`CUSTOMERS`, `USERS`, `B2B_SAAS_SELF_SERVICE`, `B2B_SAAS_ENTERPRISE`) start with the LinkedIn share button visible. Consumer, financial, education, insurance, newsletter, and waitlist programs (`B2C_SUBSCRIPTIONS`, `FINANCIAL_SERVICES`, `ONLINE_EDUCATION`, `ONLINE_INSURANCE`, `SUBSCRIBERS`, `WAITLIST`) start with it hidden. Omit `goal` and every share button keeps its standard default. Change any of it afterward with `growsurf_update_campaign_design`. Set only at creation; `growsurf_update_campaign` does not accept it.",
+  "enum": [
+    "CUSTOMERS",
+    "USERS",
+    "SUBSCRIBERS",
+    "WAITLIST",
+    "B2B_SAAS_SELF_SERVICE",
+    "B2B_SAAS_ENTERPRISE",
+    "B2C_SUBSCRIPTIONS",
+    "FINANCIAL_SERVICES",
+    "ONLINE_EDUCATION",
+    "ONLINE_INSURANCE"
+  ],
+  "type": "string"
+}

addedInput schema / properties / rewards / description

Added value: +"Rewards to create with the program. Include this only when the person told you the amount and who funds it. Omit it and the program is seeded with starter rewards that are switched off, awarding nothing until the customer enables one. Send `[]` to start with no rewards at all."

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?

The annotations are all false, so the description carries the full burden of disclosing effects. It does this well: the program is created in DRAFT status, owned by the bound team, starts with GrowSurf's starter rewards switched off, custom currency is immutable after creation, and no GROWSURF_CAMPAIGN_ID is required. It also says the response includes the new program id and how to use it, which is exactly the operational behavior an agent needs.

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 description is longer than the MCP norm, but nearly every sentence earns its place by preventing a common mistake: leaving rewards to renting behavior, passing too much bulk because currency immutable, or expecting it is a patch tool. It is front-loaded with the core purpose and only later moves to workflow details. It does not have any fluff, but a bullet or paragraph break could help an agent scan it quickly, so it loses one point on structure.

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 creation tool, the description gives all the context needed to invoke it correctly: defaults, required vs optional behavior, what is not accepted, what the response supplies, and how to chain the id into the rest of the GrowSurf toolset. Since an output schema exists, the description does not need to inventory the return fields. There are no major gaps that would cause a placeholder execution besides unclear user-provided values, which no static text can resolve.

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 parameter-based schema coverage only 29%, guidance needed to compensate, and the description does that for the most important fields: `type` is mandatory, `goal` is set only at creation and configures sharing, `currencyISO` defaults to USD and is immutable, and `rewards` has clear inclusion rules plus the `[]` distinction. `name`, `companyName`, and `companyLogoImageUrl` are left to their self-evident names and simple schema labels, so the description does not document every param but it does add high-value semantics for the ones that matter most.

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: 'Create a new GrowSurf program (campaign)' and immediately states the main behavior—pre-populating the program with starter content and optionally adding rewards. It also distinguishes this creation tool from related configuration tools by explicitly saying editor-tab config is not accepted here and that the resulting id is used by other tools.

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 gives clear guidance on when valid, including 'Only type is required', when to omit or send rewards, and why to pass goal. It states that editor-tab configuration is not handled here and should be fetched and patched afterward. It does not explicitly name sibling alternatives like growsurf_create_campaign_reward or growsurf_update_campaign_design, but it points the agent to the correct post-creation workflow using config sub-resources, so the guidance is strong but not fully explicit on alternative tool names.

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

Deploy Server