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

No annotations exist, so the description carries the burden and does reasonably well: it discloses that the tool is free, that it returns the full plan as Markdown, that an equivalent HTTP endpoint (GET /plans/{platform}) exists, and which platforms are supported. It omits what happens for an unsupported platform and any rate/auth constraints, but for a read-only free retrieval that gap is minor.

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 usage trigger, then the payload contents, then the mechanics, so the most decision-relevant information comes first. The trailing platform enumeration duplicates the schema enum and is the one mildly wasteful element.

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 and no annotations, the description steps in to describe the return format (Markdown) and the substance of the returned plan, which is exactly what an agent needs before calling. Only the semantics of preview_only and unsupported-platform behavior are left unaddressed.

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?

Schema description coverage is 100%, so both parameters are already documented, and the description's platform list merely echoes the schema's 'One of:' enumeration. The 'Free: returns the full plan' phrasing gestures at preview_only but never explains that the parameter restricts output to a preview, so no meaning is added beyond the schema.

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?

States a specific verb+resource ('get the executable step-by-step plan') and enumerates the plan's contents (bot/human split, human minutes, order, ban-reason checklist, DE tax/payout notes). It also names the platform set, which lets an agent distinguish it from get_platform, list_platforms, recommend, and can_i_earn_here without opening schemas.

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?

'Use when you decided on a platform' gives a clear trigger condition and implicitly excludes the pre-decision phase, where a sibling like get_platform or recommend would apply. It never names those alternatives explicitly, so routing is inferred rather than stated.

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