Skip to main content
Glama

ReferralHero MCP by usefulapi

Get campaign leaderboard

referralhero_get_leaderboard
Read-only

The leaderboard of a campaign: its top subscribers (10 to 100) with referral counts, points and position. GET /lists/{uuid}/leaderboard.

Input Schema

NameRequiredDescriptionDefault
uuidYesCampaign (list) uuid, the 12-character id starting with MF (see referralhero_list_campaigns).
countNoHow many top subscribers, 10-100 (default 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds useful context that the result is a bounded top-N slice (10-100) with three specific fields, but says nothing about ordering, tie handling, or behavior when the campaign has fewer than 10 subscribers.

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 short sentences, zero padding, with the payload contents front-loaded and the endpoint appended as a compact identifier. Nothing to trim.

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?

With no output schema, the description carries the return-shape burden and does so reasonably: it enumerates the returned fields and the size bound. It falls short only on ordering of the ranking and small-campaign edge cases, which are minor for a read-only lookup tool.

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%, so both uuid and count are already documented in the schema, including the 10-100 bounds and default. The description only restates the count range, adding no format or semantics the schema lacks. Baseline 3 applies.

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?

States a specific resource (campaign leaderboard) and specifies exactly what it contains: top subscribers with referral counts, points and position, plus the range 10-100. It's clear this is a ranking view rather than the flat roster returned by referralhero_list_subscribers, though no sibling is named explicitly.

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?

Usage is implied by the content: you call this when you want a ranked top-N view for a campaign rather than a full subscriber list. However, there is no explicit when-to-use statement, no exclusion, and no pointer to referralhero_list_subscribers or referralhero_get_subscriber for other lookups.

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.