Skip to main content
Glama
growsurf

GrowSurf MCP Server

Official

Recommend Program Design

growsurf_program_design_advisor
Read-onlyIdempotent

Generate referral or affiliate program designs, benchmarks, rewards, and metric definitions. Returns a read-only draft, configuration plan, and unresolved decisions.

Instructions

Generate program designs, benchmarks, typical rewards, and metric definitions, including participant-to-referral and lead-to-referral ratios. Read-only. Returns a short draft, complete benchmarkFacts, a proposed configurationPlan, and unresolved decisions. Incentive amounts and qualifying actions remain unresolved unless supplied by the customer. detail: summary returns a configuration draft and reward structure; detail: full adds detailed benchmark tables. Hosted figures describe GrowSurf's high-performing programs; without a bundle, guidance is documentation-based. programType: AFFILIATE selects affiliate advice. industry: other covers local services, pets, hospitality, and agencies. All inputs are optional.

Input Schema

NameRequiredDescriptionDefault
goalNoWhat 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 advisor goal differs from the program creation goal included in `configurationPlan`.other
detailNoUse 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
audienceNoWho refers whom.
industryNoClosest 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
companyNameNoUsed in the heading and proposed program name; omit it when unknown.
currencyISONoISO 4217 code. Non-USD advice omits the dollar reward bands. No exchange rate or equivalent-currency benchmark is available.
programTypeNoREFERRAL
salesMotionNoUse `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.
includeRulesNoAppend guidance on applying the recommendations. Off by default.
businessModelNoOne line on what the business sells and how. Also set `salesMotion` when the buying process is known.
qualifyingActionNoThe action a referred friend must complete, in the customer's words.
rewardBudgetPerReferralNoThe 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

NameRequiredDescriptionDefault
markdownNoThe requested summary or full advice, including the same configuration calls and their conditions.
decisionsNoUse one qualifying action throughout the draft. Unresolved choices require a customer decision before configuration.
benchmarkFactsNoComplete benchmark statements with metric units, median, Q1, Q3, sample, and source. Quote each statement intact. Empty when no suitable figures are available.
configurationPlanNoProposed 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.

  1. Changed1 schema field changedv0.19.9
    • changedInput schema / properties / goal / description
      Previous value: -"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`."New value: +"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 advisor goal differs from the program creation goal included in `configurationPlan`."
  2. Addedv0.14.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description confirms read-only. Beyond that it discloses meaningful behavior: incentive amounts and qualifying actions remain unresolved unless supplied, the response shape (draft, benchmarkFacts, configurationPlan, decisions), that hosted figures describe GrowSurf's high-performing programs, and that guidance is documentation-based without a bundle. It doesn't mention rate limits or auth, but adds substantial context beyond the annotations.

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?

Dense but front-loaded, leading with outputs and read-only status before parameter notes. Most sentences carry distinct information (detail modes, programType, industry:other), though the accumulation of parenthetical notes makes it slightly list-like rather than sharply prioritized.

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?

For a 12-parameter, zero-required advisory tool with an output schema, the description supplies enough: it enumerates the return artifacts, flags unresolved fields (incentive amounts, qualifying actions), and clarifies the detail-mode tradeoff. Since an output schema exists it needn't describe return values in depth, so the added detail is a bonus rather than a gap.

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 92%, so the schema already documents nearly every parameter, including enum meanings for industry and goal. The description mostly restates these (programType AFFILIATE, industry other) rather than adding new semantics, so the baseline 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?

States a specific verb and resource set: generate program designs, benchmarks, typical rewards, and metric definitions, including named ratios. It clearly distinguishes itself from the sibling creation/mutation tools (create_campaign, update_campaign, etc.) by being an advisory generator, and specifies the exact output artifacts (benchmarkFacts, configurationPlan, decisions).

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?

Gives concrete selection guidance: `detail: summary` for a first draft, `detail: full` only for detailed benchmark tables, `programType: AFFILIATE` for affiliate advice, and `industry: other` for local services/pets/hospitality/agencies. It stops short of explicitly stating when to prefer this tool over sibling design tools like get_campaign_design or agent_program_creation_eval, but the context is clear.

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

Deploy Server

Other Tools