provider_status

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

No annotations are provided, so the description must carry the burden; it does disclose one key behavioral fact (credentials are not returned, framing it as a non-sensitive read). It does not state whether this counts as a read-only operation, whether it can fail or time out, or what the status output shape is, though the output schema covers the return value.

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 sentences, no waste, and the credential-safety note is front-loaded with the core action. Nothing extraneous to trim.

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 parameterless status tool with an output schema available to describe returns, the description is adequate: it names the adapter, the subject of the status, and the credential guarantee. It is missing only sibling disambiguation and a hint of failure behavior.

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 there is nothing to document and the schema is trivially complete; baseline is 4. The description correctly describes a parameterless call.

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 (report) and resource (official-provider account status), and the sensitivity note 'No credentials are returned' sharpens the scope. However, it does not differentiate from the sibling status tools (gimp_status, triforce_status) or the sibling provider_models, so the agent cannot tell without opening it whether 'provider' overlaps those.

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?

Usage is implied by the name and the phrase 'through the shared AICoder adapter', but there is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling status tools it might be confused with. Minimum viable.

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