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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds genuinely new context: the call is free, the data is scoped to 'the connected user', and it explains the pay-per-action pricing model (every tool works if balance covers it; plans are just a cheaper rate). It does not mention auth requirements or rate limits, keeping it below 5.

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 'Free.' then the payload, then the usage directive, then the pricing-model clarification. Sentences are dense and each carries content, though the trailing 'Typical costs' list and ALL-CAPS emphasis make it feel run-on rather than crisp.

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?

No output schema exists, so the description must describe return values — and it does, covering balance, plan, per-action pricing, plays, packs, and plans. The included example costs (campaign 1000, boost 200, discovery 10+12) make it self-sufficient, though hardcoded figures risk going stale and no format details (credits units vs dollars) are spelled out beyond 'dollar range'.

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?

Zero parameters, so the baseline is 4. The description does not need to explain inputs, but it usefully orients the agent to the response structure (pricing.plays, top-up packs, plans) rather than overclaiming parameter detail.

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 and resource (returns the connected user's credit balance and plan) and additionally enumerates the concrete payload: per-action credit costs, dollar ranges, plays priced at test/standard/scale, top-up packs and plans. An agent know exactly what this returns without opening anything else, and it is distinct from siblings like credit_history or get_earnings.

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?

Gives explicit invocation timing: 'Call it before planning or recommending any spend, and quote these prices — never guess or look them up.' That is clear, actionable guidance. It stops short of naming alternatives (e.g. credit_history for past transactions) or stating when-not to use it, so it lands at 4 rather than 5.

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