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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds context the annotations cannot: that the returned organisation is the billing entity for every other tool, which tells the agent the call has downstream accounting relevance. It does not discuss the failure mode of an invalid or expired credential, which is the main remaining gap.

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?

Three short sentences, front-loaded with what is returned, followed by when to call it and the billing consequence. Nothing is repeated from the title or annotations, and no sentence could be removed without losing a distinct fact.

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, non-destructive identity tool with no output schema, the description covers all the pieces an agent needs: what comes back (org, user, plan, balance), when to invoke it, and why the result matters. Since no output schema exists, naming the returned fields is exactly the right compensation.

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 and the schema is an empty object with additionalProperties false, so there is no parameter semantics to clarify. The baseline of 4 applies, and the description's enumeration of returned fields is a bonus rather than compensation for a schema gap.

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 gives a specific verb-plus-resource statement: it returns the organisation, user, plan, and remaining balance bound to the active credential. That is clearly distinct from every sibling tool in the list, which deal with media, jobs, glossaries, or subtitle processing rather than account identity.

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 states two concrete triggers: call it first when the account to be charged is uncertain, and call it after a report that work hit the wrong account. It does not name a when-not condition or an alternative tool, but no sibling appears to serve this purpose, so the guidance is effectively unambiguous.

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