ReferralHero MCP by usefulapi

Add subscriber

referralhero_add_subscriber

Destructive

WRITE: add a subscriber (or a referred person) to a campaign. Give the campaign's unique identifier (email, phone, wallet or custom id). By default ReferralHero sends the subscriber a confirmation (double opt-in) email and any welcome automation of the campaign: set double_optin=false to suppress the confirmation email. Set referrer (a referral code or the referrer's email) to credit a referral. POST /lists/{uuid}/subscribers.

Input Schema

Name	Required	Description
`name`	No	Subscriber name.
`tags`	No	Tags to assign.
`uuid`	Yes	Campaign (list) uuid, the 12-character id starting with MF (see referralhero_list_campaigns).
`email`	No	Subscriber email (when email is the campaign's unique identifier).
`device`	No	Device used to sign up, for analytics.
`domain`	No	URL used for the subscriber's referral link.
`points`	No	Starting points (contest campaigns only).
`source`	No	Source, for analytics.
`status`	No	custom_event_pending = set the referral status to pending (multi-step goals).
`confirm`	Yes	Must be true: the user has approved this change. It can unlock rewards and make ReferralHero email or text the subscriber or referrer (automations).
`referrer`	No	Referral code or email of the referrer to credit.
`extra_field`	No	Extra field value.
`double_optin`	No	false = do not send the confirmation email. Default: the campaign's setting (usually sends it).
`phone_number`	No	Subscriber phone number (when phone is the unique identifier).
`advocate_name`	No	Name of the advocate.
`extra_field_2`	No	Extra field 2 value.
`transaction_id`	No	Unique id of the purchase this referral came from.
`conversion_value`	No	Monetary value of the referral.
`stripe_customer_id`	No	Stripe customer id to link.
`conversion_category`	No	Subscriber type for reports and segments.
`self_reported_source`	No	Where the subscriber says they heard about the campaign.
`crypto_wallet_address`	No	Wallet address (when it is the unique identifier).
`other_identifier_value`	No	Custom identifier value (when a custom id is the unique identifier).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare destructive=true, non-idempotent, and open-world. The description adds important behavioral context beyond annotations: by default ReferralHero emails the subscriber a confirmation and may trigger welcome automations, with double_optin=false to suppress the email. It does not discuss duplicate-subscriber behavior, but the external communication side effect is clearly surfaced.

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 front-loaded with 'WRITE' and four compact sentences, with no wasted filler. The parenthetical identifier list is confusing, but overall structure is efficient.

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 23-parameter mutation tool with no output schema, the description covers the critical operational details: default email/automation behavior, how to suppress it, and how to credit a referrer. The missing duplicate/idempotency guidance and the misleading identifier sentence keep it from being fully complete.

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

Parameters2/5

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

Schema coverage is 100%, so the schema already documents all 23 parameters thoroughly. The description adds little beyond the schema and contains a confusing/misleading statement: it calls email, phone, wallet, or custom id the 'campaign's unique identifier', while the schema says uuid is the 12-character campaign id and those other values are subscriber identifiers. This could lead an agent to misuse the uuid parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'WRITE: add a subscriber ... to a campaign', which clearly distinguishes it from read, update, or delete operations. It does not explicitly contrast with siblings such as update_subscriber or confirm_referral, so it is clear but lacks sibling differentiation.

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

Usage Guidelines3/5

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

It gives useful default context: confirmation emails are sent unless double_optin=false, and referrer can be set to credit a referral. However, it does not say when to use this instead of update_subscriber or how to handle existing subscribers, leaving alternatives implicit.

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

All ReferralHero MCP by usefulapi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Add subscriber

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources