Skip to main content
Glama

ReferralHero MCP by usefulapi

Mark referral unqualified

referralhero_unqualify_referral
DestructiveIdempotent

WRITE: mark a referral as unqualified (for example fraud or a refund), so it no longer counts toward the referrer's rewards. POST /lists/{uuid}/subscribers/{id}/unqualify.

Input Schema

NameRequiredDescriptionDefault
uuidYesCampaign (list) uuid, the 12-character id starting with MF (see referralhero_list_campaigns).
confirmYesMust be true: the user has approved this change. It can unlock rewards and make ReferralHero email or text the subscriber or referrer (automations).
subscriber_idYesSubscriber id, e.g. sub_2bad325a25d7 (the id field of a subscriber).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds the domain-level effect that matters most: the referral stops counting toward the referrer's rewards. It stops short of stating reversibility (whether qualify_referral can undo this) or what happens to already-awarded rewards.

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?

Two tight sentences: the action and its effect first, the endpoint second. Nothing is redundant and the key constraint is front-loaded.

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 3-required-param write tool with full schema coverage, no output schema and rich annotations, the description covers purpose, motivation and effect adequately. The one meaningful gap is irreversibility/re-qualification guidance, which an agent deciding between unqualify and delete would want.

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%, and the schema itself explains uuid, subscriber_id and the confirm gate including its side effects. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.

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+resource ('mark a referral as unqualified') and immediately names the consequence ('no longer counts toward the referrer's rewards'), which cleanly separates it from referralhero_qualify_referral and from deletion tools like delete_subscriber. The 'WRITE:' prefix plus the endpoint make the operation type unambiguous.

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 triggering cases ('fraud or a refund'), which is clear usage context. It does not, however, say when not to use it or point to sibling alternatives such as qualify_referral for reversal or delete_subscriber for hard removal.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.