Moby

My AI Trading invite codes

get_my_invite_codes

Read-only

The user's AI Trading (AGENT-) invite codes with share links, the friends who redeemed them and the USDC earned from their trading fees. Read-only. Use for "my invite codes", "invite a friend", "how much have my referrals earned".

codes[]: each AGENT- code with status (unused / redeemed / activated), share_url (the https invite link) and share_text (the app's share message, code and link filled in). share_text / invite_link at the top are the NEXT unused code's: hand that text to the user to send to a friend, one code per friend; unused_count is how many are left (Moby tops them up).
friends[]: who redeemed a code (joined_at, activated, earned_usdc from them, their agent_wallets and agent_trades_count).
pending_usdc (not yet swept), swept_usdc (paid to the agent wallet), earned_usdc (all time), fee_share_pct (the share of each friend's trading fees the user earns), sweep_threshold_usdc. Never Copy Trading (COPY-) codes: those are a different product and are not on this surface. enabled: false = the referral program is off; say so instead of sharing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_my_invite_codes"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026
- removedInput schema / title
```
Removed value: -"get_my_invite_codesArguments"
```
AddedNov 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true/destructiveHint=false, and the description reinforces this with "Read-only." It adds behavior the annotations do not: share_text/invite_link refer to the NEXT unused code, Moby tops up codes, and enabled: false means the program is off and the agent should say so rather than share. No auth or freshness/rate-limit context, which keeps it below 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first two sentences, but the bulleted walkthrough of codes[], friends[], and the USDC fields largely restates a response shape that an output schema already covers. Some of that text earns its place (share_text is the next unused code; unusued_count meaning), but the section is longer than needed.

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 a zero-parameter, read-only, output-schema-backed tool, the description covers edge cases (enabled: false, exhausted code inventory, COPY- exclusion) that an agent actually needs. The only meaningful gap is not clarifying when to prefer get_my_invite_payouts for payout history.

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?

The tool takes zero parameters, so the baseline is 4 and there is nothing parameter-wise for the description to compensate for. The narrative field notes describe response semantics rather than input semantics.

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 opening sentence names the specific resource (AI Trading AGENT- invite codes) and enumerates its content: share links, redeeming friends, and USDC earned. It explicitly excludes COPY- codes as a different product, so the agent can separate this tool from adjacent concepts without opening the schema.

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?

It gives concrete user-phrase triggers ("my invite codes", "invite a friend", "how much have my referrals earned") plus the one-code-per-friend operating rule and the COPY- exclusion. It does not route to the sibling get_my_invite_payouts even though payouts (pending/swept USDC) are directly relevant there, leaving a genuine ambiguity unaddressed.

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

All Moby tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?