avanza_accounts

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the key trait that results are scoped by what is 'currently visible to the authenticated TUI session,' which is genuinely useful and non-obvious. However, it does not state what happens when no session is authenticated, whether the operation is read-only, or anything about the return structure.

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?

A single 10-word sentence with zero filler. The verb and resource are front-loaded, and the scoping constraint is delivered immediately rather than buried in later clauses. Every word earns its place.

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 simple list tool with two optional parameters and no output schema, the description is almost sufficient, but it leaves gaps: it does not describe the expected return shape (list of account IDs, names, types?), nor behavior when no authenticated session exists. Given zero annotations and no output schema, some expectation-setting about failure modes would round it out.

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 50%, with tenant_session_id documented in the schema while session_id is not. The phrase 'authenticated TUI session' indirectly gives meaning to session_id by tying it to the session whose account visibility is being listed, adding some value beyond the bare property name. However, the description does not directly explain either parameter or their optionality, so it only partially compensates for the coverage 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 states a specific verb ('List') and resource ('Avanza accounts') with a scoping qualifier ('currently visible to the authenticated TUI session'). This clearly distinguishes it from siblings like avanza_select_account and avanza_account_performance, though it does not name them explicitly. The only shortfall is the lack of an explicit sibling differentiation statement.

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 gives no guidance on when to use this tool versus alternatives such as avanza_select_account or avanza_account_performance. The session-scoping phrase obliquely implies it is for enumerating session-visible accounts, but there are no explicit when/when-not conditions or alternative routing. An agent would have to infer the intended use case from the name alone.

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