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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description goes far beyond that by disclosing subtle behaviors: zero balance does not block live traffic, free-tier projects are exempt, only the testing pool refuses with a specific 402 error, and overage fields appear only on Pro/Scale plans. It also clarifies that invoiceable accounts show empty credits by design. This is exemplary transparency for a read-only tool.

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 description is lengthy but every sentence adds value: it covers the core function, billing model semantics, edge cases, overage fields, and throttling. It is front-loaded with the main purpose and then logically expands into details. The structure is organized by concepts (billing model, zero balance, overage) rather than rambling. Given the complexity of the returned data, this level of detail is justified and concise in its own right.

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 is the only source of return semantics. It thoroughly documents the fields (billingModel, credit balances, overage object with usedCredits, overageCredits, amount, currency, windowEndsAt, throttled, throttledUntil) and their conditional presence. It also explains interpretation pitfalls (invoiceable empty credits, zero balance not blocking). An agent can fully understand the response without further documentation. This is complete for a 0-parameter, no-output-schema tool.

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 input schema has zero parameters, so schema description coverage is trivially 100%. Per the rubric, a 0-parameter tool gets a baseline of 4. The description appropriately does not discuss parameters since there are none, and it focuses on the output instead. No additional parameter semantics are needed.

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 description opens with a precise verb and resource: 'Get the project's credit balances (paid + testing) and which ledger it settles on.' It clearly distinguishes this tool from siblings like get_receipts or get_subscription by focusing on credit balance and billing model. The detailed explanation of billingModel further sharpens the purpose.

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 provides explicit guidance on when to consult this tool ('Read this before concluding from any other field that a project cannot send'), which is a strong usage directive. It also contrasts with the sibling set_overage_billing for modifying overage settings, and explains edge cases (free-tier exemption, invoiceable accounts) that inform correct usage. This is more than most tools offer.

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