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

Annotations already declare a read-only, idempotent, closed-world operation, and the description adds substantially beyond that: no enrollment step, membership-wide readability, eligibility expiry tied to the first Sandbox publication, bonus semantics (traffic not cash, no social post, does not consume the share bonus allowance but does consume active-campaign capacity). It even warns that reading or applying a code does not itself start traffic, which prevents a costly misreading of side effects.

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 return contents and the no-enrollment fact are front-loaded, and the sentences are dense but purposeful. A few clauses (the bonus-usage walkthrough naming three other tools) sit closer to start_sandbox_traffic's territory and lengthen the payload, so it is efficient rather than optimal.

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 describing returns and does so at a useful level: invitation.url to share, eligibility, aggregate counts, and traffic bonuses. Combined with the eligibility cutoff and the bonus-versus-cash clarification, an agent has everything needed to call it and interpret the result correctly.

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 description to disambiguate; the empty schema already fully specifies the call signature. The description correctly adds nothing about arguments and instead spends its space on behavior, which is the right allocation.

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 first sentence names a specific verb and the exact resources returned: stable invitation code/link, eligibility, aggregate invitation counts, and available traffic bonuses. It implicitly separates reading from the sibling apply_referral_code ('There is no enrollment step', 'Merely reading or applying a code does not start traffic'), but never names that sibling, so the routing signal is weaker than it could be.

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?

It states who may call it (every organization member), the preconditions (any time; acceptance is possible until first-ever Sandbox publication), and an explicit downstream procedure for spending a bonus: choose a game, read get_sandbox_traffic, ask the developer, then call start_sandbox_traffic with bonusId instead of postUrls. Alternatives and the boundary with related tools are spelled out rather than inferred.

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