GrowSurf MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

growsurf_program_design_advisor

Read-onlyIdempotent

Design referral or affiliate programs with benchmarks, reward structures, and configuration plans. Provide program details to get a draft with metrics, decisions, and next steps.

Instructions

Use for program designs, benchmarks, typical rewards, and metric definitions, including participant-to-referral and lead-to-referral ratios. Read-only; call with known context before asking questions. Returns a short draft, complete benchmarkFacts to quote, exact configurationPlan tool calls, and unresolved decisions. Preserve the calls and leave unresolved incentives open. Use the default summary for first designs and configuration drafts; use detail: full when the user requests detailed benchmark tables or a specific figure absent from the summary. Hosted figures describe GrowSurf's high-performing programs; without a bundle, guidance is documentation-based. Use programType: AFFILIATE for affiliates and industry: other for local services, pets, hospitality, or agencies. All inputs are optional.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`goal`	No	What a successful referral means for the business. `paid_conversions` and `leads` imply a qualifying action; `signups`, `subscribers`, and `waitlist` count the signup unless a separate `qualifyingAction` needs clarification. This is the advisor's goal enum; use the separate creation goal returned in `configurationPlan` for `growsurf_create_campaign`.	other
`detail`	No	Use summary for a first design or configuration draft, including a reward structure recommendation. Use full only for requested detailed benchmark tables or specific figures absent from the summary, such as reward amounts, share channels, or integration proportions.	summary
`audience`	No	Who refers whom.
`industry`	No	Closest industry segment: `financial_services_fintech` (banking, lending, investing, insurance, payments, crypto), `saas_ai` (software sold to businesses, developer tools, AI products), `media_newsletters` (newsletters, podcasts, publishers, content brands), `healthcare_wellness` (clinics, telehealth, fitness, nutrition, mental health, supplements), `education_workforce` (courses, bootcamps, tutoring, hiring and job platforms), `consumer_subscriptions_commerce` (consumer apps, e-commerce, marketplaces, subscription boxes). Use `other` when no segment clearly fits (local services, pets, hospitality, agencies) rather than stretching one; `other` returns the platform-wide figures.	other
`companyName`	No	Used in the heading and proposed program name; omit it when unknown.
`currencyISO`	No	ISO 4217 code. Non-USD advice omits the dollar reward bands. No exchange rate or equivalent-currency benchmark is available.
`programType`	No		REFERRAL
`salesMotion`	No	Use `sales_led` for demos, sales calls, negotiated pricing, or signed contracts; use `self_service` when customers buy directly. This selects the reward structure. Omit when unknown.
`includeRules`	No	Append guidance on applying the recommendations. Off by default.
`businessModel`	No	One line on what the business sells and how. Also set `salesMotion` when the buying process is known.
`qualifyingAction`	No	The action a referred friend must complete, in the customer's words.
`rewardBudgetPerReferral`	No	The customer's spending limit per successful referral, in major currency units. A budget does not select an incentive amount or commission rate. Budget comparisons omit the mixed-currency reward amount bands.

Output Schema

TableJSON Schema

Name	Required	Description
`markdown`	No	The requested summary or full advice, including the same configuration calls and their conditions.
`decisions`	No	Use one qualifying action throughout the draft. Unresolved choices require a customer decision before configuration.
`benchmarkFacts`	No	Complete benchmark statements with metric units, median, Q1, Q3, sample, and source. Quote each statement intact. Empty when no suitable figures are available.
`configurationPlan`	No	Proposed calls using the listed tools' argument shapes. Preserve each tool and arguments object when presenting the plan; replace <new-program-id> with the creation response's id before execution.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.14.0Sep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description adds meaningful behavioral detail beyond the annotations: it is read-only, returns exact tool calls that the caller must preserve, leaves unresolved incentive decisions open, and depends on a bundle vs documentation-based guidance. These details are not available in annotations and shape how the caller must handle the result.

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 dense but front-loaded with purpose, mode, and parameter-choice guidance. It is longer than necessary because some detail is already covered by the schema, but each sentence adds behavioral or selection context, making the extra length largely justified.

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 tool with 12 optional parameters, output schema, and complex how-to-use decisions, the description covers behavior, return shape, parameter selection, and data-source variation. It also flags preservation rules for the generated configurationPlan calls and unresolved decisions, making it fully operational for the agent.

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 92% schema coverage, most parameter meaning is already available, but the description adds value by explicitly mapping programType AFFILIATE and industry other to practical scenarios, and by prescribing summary vs full detail usage. Some instructions repeat schema parameter descriptions, so it does not fully exceed the schema, but it still improves selection and usage.

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 states a specific verb and resource: it is a read-only program design advisor for benchmarks, reward structures, metric definitions, and with output that includes a draft, benchmarkFacts, configurationPlan calls, and unresolved decisions. This clearly differentiates it from the many create/update action tools in the sibling set.

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 clear context for when to use the tool, such as using summary mode for first drafts and full mode for requested benchmark tables, and it maps programType/industry values to common user cases. It does not explicitly name sibling alternative tools to exclude or state when-not-to-use though, so it stops short of a 5.

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

Deploy Server