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

With readOnlyHint=false the agent knows mutations exist, and the description pinpoints them: logout 'revoga a chave no servidor e apaga o token local', login persists a local session valid 90 days that auto-renews. It also discloses auth requirements (start works without login, version doesn't require login) and that action=api is strictly read-only and never returns the key or its hash. It doesn't describe rate limits or error behavior, keeping it at 4 rather than 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?

It is one unbroken paragraph dense with nested parentheses covering 13 actions, so per-action density is high but scannability is poor and the front-loaded summary is thin. Every clause carries information, yet the run-on formatting makes it harder to parse than a short bulleted mapping would be.

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 13-action, 4-parameter tool with no output schema, the description does substantial work: it sketches expected returns (balance/tier, plan+status+per-bucket balance with low/critical warnings, dollar balance, day spend, key names and caps) and flags which actions need login. The only real gap is that formats, health, app_url and pontes are mentioned in a phrase or not at all.

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 coverage is 75%, and the description still adds meaning on top: it maps each action value to an outcome, explains that midia narrows the price table to one medium and that omitting it returns image/video/music/voice while text only appears with midia=texto, and that busca filters engine/model names accent- and case-insensitively. The code parameter's origin is only restated from the schema, but the dominant parameter (action) is fully explained.

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?

Each of the 13 actions is named with a concrete verb/outcome (start teaches connecting, login connects the account, logout revokes the key, whoami returns tier+balance+email, version reports the actually-running version), so an agent can pick an action without opening the schema. The umbrella framing ('Utilitários transversais') is vague, but it clearly separates this account/utility tool from the content-generation siblings. It stops short of 5 only because the opening line alone doesn't tell you what the tool is for.

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 concrete routing rules: use version to check whether the client picked up the new build or is stuck on npx cache, use credits/subscription before generating images to warn about overspend, use action=api for dollar balances. It also states an explicit exclusion: subscribing, moving money, changing wallet limits, enabling auto-recharge and creating keys must be done on the site, not here. No guidance on when to prefer start over login is spelled out explicitly, but it is strongly implied.

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