Get account

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds critical behavioral context beyond that: it warns that the response includes sensitive data (billing address, email, phone, verifyUrl with a live key) and instructs not to echo or store the full response. This goes beyond annotations and is valuable for safe usage, though it doesn't describe other behaviors like pagination or error handling.

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 extremely concise: two sentences. The first states the purpose and key fields, the second delivers the sensitive-data warning. There is no filler or redundant information. The most critical information (purpose) is front-loaded, and the warning follows logically.

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?

The description is adequate for a simple getter with one optional parameter and no output schema. It lists the main response fields and highlights the sensitive nature, which is essential for proper handling. It does not detail the structure of nested objects like billing profiles, but that is likely covered by the response schema (not provided). Given the simplicity and the annotations covering safety, this is sufficiently complete.

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 100% coverage for the single parameter userId, which is fully described with a default and explanation. The description does not add any additional parameter semantics beyond listing the fields in the response, which is not tied to the parameter. Since the schema already documents the parameter adequately, the baseline of 3 is appropriate.

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 clearly states the tool's function: retrieving the account record and lists specific fields (id, contact details, billing profiles, market, currency). The verb 'get' plus the resource 'account' distinguishes it from sibling tools like ws_auth_check, which checks authentication, and other ws_*_get tools for different resources.

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?

The description does not explicitly name an alternative or state 'use this when...', but the context is clear: this is the only tool for retrieving account data. It does provide handling guidance for the sensitive response, which is a form of usage instruction. There is no explicit exclusion of other tools, but the domain makes it obvious, so it earns a 4 rather than 5.

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