avanza_stoplosses

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

No annotations are provided, so the description carries the full burden. It adds some behavioral context by indicating this is a read-style listing operation that audits missing/mismatched metadata, but it does not disclose how the 'refresh' parameter alters behavior, whether any side effects occur, pagination, or session/auth requirements.

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 sentence with the verb and resource front-loaded, containing no filler. The phrase 'durable strategy intent and missing/mismatch metadata audit' is dense but compact; it could be clearer without being longer.

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 tool with 10 params, no required params, no output schema, no annotations, and multiple overlapping siblings, the description is far from complete. It does not clarify output shape, describe the audit result, disambiguate from avanza_instrument_stoplosses, or explain the ambiguous param names — an agent would be guessing on critical invocation details.

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?

With only 20% schema description coverage, the description must compensate, and it only maps three params (instrument, side, status) to filter semantics. Seven of ten params remain unexplained, including the ambiguous orderbook_id/order_book_id pair and the meaningful compact/refresh flags, leaving the agent to guess.

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 names a specific verb and resource ('List stop-loss orders') plus a distinctive scope ('durable strategy intent and missing/mismatch metadata audit') and filter options. This mostly separates it from the sibling avanza_instrument_stoplosses, though the jargon phrase 'durable strategy intent' is vague and the dual list+audit framing blurs the tool's primary purpose slightly.

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 when-to-use guidance, exclusions, or alternative tool names are given. Given a sibling list containing closely overlapping tools like avanza_instrument_stoplosses, avanza_stoploss_strategy_audit, and avanza_open_orders, an agent has no way to decide which one to invoke.

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