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

Annotations already declare this a safe read (readOnlyHint, destructiveHint false), so the bar is lower. The description contributes real value beyond them by explaining the economics — 2 credits per style, 3 for songs over 3:30 — which the agent needs to interpret the returned balance. It omits error/fallback behavior for unconnected users.

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?

Two short sentences, front-loaded with the resource and scope, with the cost context placed after the core definition. No filler or restated schema content.

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?

For a zero-parameter read tool with no output schema, the description roughly covers the return ('their credit balance') and pricing context, but leaves the response shape and the not-connected case unspecified. Adequate but not complete.

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 to disambiguate; schema coverage is trivially 100%. Baseline 3 is appropriate since the description neither adds nor omits parameter meaning.

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 resource ('credit balance') and its scope ('for a connected Starchild member'), so an agent immediately knows what it retrieves. It is not a tautology of the name, though it doesn't name-differentiate from siblings, which it doesn't need to since the sibling set is unrelated.

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?

Implies usage by naming a precondition ('connected Starchild member') and by explaining credit costs, which suggests checking this before spending. However, it never says when to call it versus alternatives or what to do if the member is not connected.

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