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

The readOnlyHint says the tool is read-only, and the description reinforces this by describing a status query without mutation or side effects. It also adds valuable nuance beyond the annotation by specifying eligibility triggers (lifetime volume threshold or existing affiliate) and time-bound data (30d/all-time volumes, caps), which fills in what the agent should expect back in the absence of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description front-loads the main scope and then packs all relevant status details into one sentence. It is long but each item contributes meaning, so it is closer to a compact enumeration than an unnecessarily verbose description. A bulleted list could improve readability, but the content is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, this description must carry the full burden of explaining the tool's result, and it does: referral code, link, access unlock status, tier, fee share, volumes, earnings, referred-user stats, referrer, full tier table, and cap parameters. It concentrates almost every meaningful piece of referral state an agent might need to reason about or verify.

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

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

There are no parameters, and the schema already manages the empty property list completely. The description therefore adds nothing new about input needs, but it appropriately keeps the explanation focused on output instead of trying to invent parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: getting this account's referral/affiliate program status. It then enumerates a concrete set of returned fields (referral code, link unlock status, tier, fees, volume, earnings, referrer, tier table, parameters), making it unambiguous. There is no sibling tool covering referral/affiliate program data, so the scope already separates it from the trading/accounting tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The no-parameter, account-scoped 'status' wording gives a clear context: call this when the agent needs this account's referral program state. It does not explicitly document exclusion criteria, such as 'do not call before sign-up,' but there is no alternative sibling to consider, so the simple is adequate.

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