get_account_health

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

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description adds meaningful behavioral context beyond them: it never starts a browser, a config failing validation is REPORTED rather than raised, unknown evidence earns no points, and it does not predict X enforcement or establish live authentication. These are important traits for an agent interpreting the result.

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 definition front-loads the snapshot contents and then qualifies semantics efficiently. It is somewhat dense (two long sentences plus a fragment about config validation), but every clause adds information and nothing is wasted.

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?

An output schema exists, so return-value structure is covered elsewhere, and the description appropriately focuses on interpretation caveats. However, with 0% schema coverage on the only parameter, it leaves identifier format unaddressed, and offers no usage routing among the many account-related siblings.

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 description coverage is 0% for the single account parameter, so the description must carry the load. It implies the account is the subject of the health check but adds no detail on identifier format (handle vs. ID vs. email). Baseline for the low-coverage single-param case is 3; the description does not fully compensate.

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 enumerates exactly what the snapshot contains (config presence, cookie-file validity, metrics counters, warm-session state, queue depth, pending drafts, readiness score) and states the verb (read-only health snapshot for one account). This clearly distinguishes it from siblings like get_runtime_info, get_account_safety, and get_account_analytics.

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?

No explicit when-to-use or when-not-to-use guidance. The description contrasts with X enforcement prediction and live authentication, but never says when an agent should call this versus get_account_safety, get_session_status, or get_runtime_info. There is implied context (diagnosing account readiness) but no routing guidance.

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