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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavioral context beyond them: a plan-tier entitlement gate, the fact that the returned business name may be an auto-generated placeholder derived from email domain or first name, and that Stripe/payment connection is browser-only with connectLinks supplying the one-click URL. Nothing contradicts the annotations.

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?

Front-loaded with the resource and its contents before any conditional guidance, then ordered by actionability: when to call, placeholder-name handling, payment connection constraint, eligibility. The parenthetical step list and field names are dense but every clause carries information an agent would otherwise have to guess.

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?

There is no output schema, so the description carries the return-value burden and does it: it lists the returned sections, explains the meaning of the needsDetails flag and connectLinks, and discloses the plan prerequisite. An agent has enough to call it correctly and interpret the result without additional tools.

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 the baseline is 4 and there is no parameter syntax to disambiguate. The description instead spends its space on field-level semantics of the response (needsDetails, connectLinks), which is useful but not parameter documentation.

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?

Names a specific resource (account's affiliate-program setup state) and enumerates the concrete payload: business name/website, the five launch steps plus the next one, tracking script tag and whether it has been seen, and per-campaign join links. The phrase 'Call it first when helping someone set up or launch' separates it from siblings like get_program_overview or check_tracking.

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?

Explicitly says when to call it ('first when helping someone set up or launch'), states an eligibility precondition ('Requires Pro plan or higher, or a new account that has not picked a plan yet'), and gives branching guidance for the needsDetails flag and for payment connection, which can only be completed by the person in the browser.

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