Skip to main content
Glama

Your affiliate code and earnings

affiliate_me

Requires a JWT. The affiliate program: your code (your page handle — share rokha.ai/?ref=) and what it earned. You get 25% of what a buyer you referred pays for their first Studio month (once per buyer); anything else Rokha sells on the site joins the same rule. Unlocked by a claimed page on the Network. Crypto sales pay at settle, card sales after a 30-day hold, in USDC to your page's payout address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=false/destructiveHint=false, so the description carries most of the burden and delivers useful context: JWT auth requirement, the claimed-page prerequisite, payout mechanics (crypto at settle, card after a 30-day hold), 25% revenue share, and USDC payout. It adds real operational context beyond the bare annotations.

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?

Four tight sentences, front-loaded with the auth requirement, then the resource, then the earning/payout rules. Every sentence conveys actionable domain context and there is no filler.

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 params and no output schema, the description needs to convey what comes back, and it does: the affiliate code, earnings, and payout status/destination. It could be more explicit about the response shape, but it is sufficient for a zero-input read tool.

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

Parameters4/5

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

There are zero parameters, so the baseline is 4. Nothing about input syntax needs explaining, and the description introduces no misleading parameter details.

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 title and description communicate that this returns 'your code ... and what it earned', a clear verb+resource for a 'me' endpoint. It doesn't differentiate itself from sibling referral tools (referrals_me, network_referral), but the resource is identifiable.

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 states a prerequisite ('Unlocked by a claimed page on the Network') and an auth requirement ('Requires a JWT'), which gives implied usage context. However, it never says when to call this versus alternatives like referrals_me or network_referral, so selection guidance is incomplete.

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.