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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description needn't repeat it. What the description does add is the referral economics ($5 per friend, friend gets $10 free) and the shape of the payload (link, sign-in count, credits), which is genuine context beyond the annotations. It stops short of stating whether the link is pre-existing or generated on call, which is the one behavioral detail that matters here.

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?

A single compact sentence that front-loads the most concrete element (the URL pattern with the placeholder code). It is slightly cryptic in phrasing — 'Your person's' and the colon-appended reward clause read awkwardly — but nothing is padding.

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?

With no output schema, the description carries the burden of explaining the return value, and it does so only partially: it names the three pieces (link, friend count, credits) but not their structure, units, or whether the count is lifetime or current. For a no-parameter read tool this is adequate but leaves the agent guessing at the response shape.

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?

The tool takes zero parameters, so there is nothing for the schema to document and nothing the description needs to compensate for; the baseline applies. The description correctly implies the tool is scoped implicitly to the calling user rather than accepting an identifier.

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 enumerates the resource's contents (invite link with code, number of signed-in friends, credits earned) but never states the operation — it reads as a noun-phrase data description rather than a verb+resource statement, so an agent must infer that calling it retrieves this information. It offers no differentiation from siblings like 'credits' or 'my_details', which plausibly overlap.

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?

No when-to-use guidance is given, and no alternative is named even though 'credits' and 'about' sit among the siblings and likely overlap with the credits-earned content. The agent is left to infer the trigger condition from the name alone.

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