Cello

cello_get_referrers

Read-only

Finds referrers of your product and returns aggregated engagement and performance metrics, optionally filtered and sorted. Returns up to 10 referrers per page. Use when a user wants to find a specific referrer by email, UCC, product user id, or referrer id — or when they want referrers ranked by a specific metric like signups, revenue, or sharing activity.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number (1-indexed; page 1 returns the first 10 referrers, page 2 the next 10, etc.). Only specify when more than 10 referrers are needed. Omit for the first 10.
`sort`	No	Sort referrers by engagement or performance metrics (descending). Available options: daysActive (number of days the referrer has been active), daysSharing (number of days the referrer has been sharing), lastActive (when the referrer was last active), referralAnnualRecurringRevenue (Net New Annual Recurring Revenue generated), referralRecurringPurchases (total number of purchases), referralRevenue (total revenue amount), referralSignups (total number of signups), referralViewsUnique (number of unique views from new users).
`filter`	No	Filter by email, UCC, product user id, or referrer id

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`total`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare read-only and non-destructive behavior. The description adds pagination details (up to 10 per page) and mentions aggregated metrics. No contradictions; the description supplements annotations well.

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 sentences, front-loaded with the core action, followed by usage guidance. No fluff, every word earns its place.

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 an output schema present, the description does not need to detail return values. It covers pagination, sorting, filtering, and a typical use case. Slightly missing could be a warning about sorting metric names, but overall adequate.

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 baseline is 3. The description adds minor context for the `page` parameter (when to specify) and reiterates filter criteria, but does not significantly deepen understanding beyond the schema.

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 clearly states the tool finds referrers and returns aggregated metrics, optionally filtered and sorted. It distinguishes itself from siblings like `cello_get_top_referrers` by covering both specific search and ranked lists, making its purpose 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?

The description explicitly says when to use: when a user wants to find a specific referrer by criteria or when they want referrers ranked by a metric. It does not explicitly state when not to use or name alternatives, but the context is clear enough for correct selection.

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

All Cello tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct aspect of the Cello platform: events, integration status, metrics, recommendations, referrers (general and top), and documentation search. No two tools have overlapping purposes; descriptions clearly differentiate them.

Naming Consistency5/5

All tools follow a consistent pattern with 'cello' prefix, verb (get or search), and snake_case noun. The verb choice is appropriate for each operation, and the naming is predictable and uniform.

Tool Count5/5

With 7 tools, the set is well-scoped for a referral program analytics and diagnostics server. Each tool fills a necessary role without being excessive or too sparse.

Completeness4/5

The tool set covers all key read-only diagnostics: events, integration health, metrics, recommendations, referrers, and documentation. However, it lacks any write or configuration tools, which may be expected for a comprehensive integration server, but the surface is complete for its apparent diagnostic purpose.

Resources

Need Help?