Skip to main content
Glama
Referalli

@referalli/mcp

Official
by Referalli

roi_patterns

Read-only

Identifies customers/partners matching named credit-ROI patterns after their evidence window elapses, avoiding flags on new accounts.

Instructions

Customers or partners matching a named credit-ROI pattern: credit_only (used credit, never paid cash), churn_at_exhaustion (stopped paying once credit ran out), bonus_collector (partner collected credit without paying themselves), negative_partner (a partner whose referrals lose money overall). Only subjects whose evidence window has fully elapsed are listed, so a young customer is never flagged. Each entry has a subject and detail amounts in minor units.

Input Schema

NameRequiredDescriptionDefault
patternYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that — the rule that only subjects with a fully elapsed evidence window are listed, so young customers are never flagged, plus the shape of each entry. It does not mention result size limits or ordering, keeping it short of a 5.

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?

Front-loads the resource description, then the enum glosses, then the eligibility caveat in three tight sentences with no filler. The inline pattern definitions are dense but every clause carries semantic weight.

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 one-parameter read with no output schema, the description covers the enum meanings, the eligibility rule, and the per-entry fields (subject plus detail amounts in minor units). Only result limits/pagination are unaddressed, a minor gap.

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

Parameters5/5

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

Schema description coverage is 0% and the schema only lists bare enum strings, so the description carries the full semantic load — it defines what each of the four patterns actually detects, which is the single most important fact for selecting the right call. It also clarifies that amounts are in minor units.

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 ('Customers or partners matching a named credit-ROI pattern') and then defines every enum value in plain language, so an agent knows exactly what is being retrieved. It does not explicitly contrast with roi_summary or roi_trace, leaving sibling differentiation implicit.

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 only implied: the description explains what each pattern means, which hints at when an agent would pick one, but gives no explicit when-to-use, when-not-to-use, or pointer to alternatives like roi_summary, roi_trace, or list_fraud_cases.

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