avanza_stoploss_strategy_register_batch

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

With no annotations at all, the description carries full behavioral burden. It clearly discloses that the write is local-only, never touches Avanza, and that confirm=true is the atomic commit gate. It also flags the authorization distinction (MCP R/W but not live-trading). It does not disclose failure/rollback behavior on partial items, but it says 'atomically,' which implies all-or-nothing.

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 dense sentences with no wasted words. The first sentence states the operation and scope; the second provides the crucial safety/authorization guardrail. Key decision-relevant facts are front-loaded.

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 nontrivial batch tool, the description explains the operation, its local side effect, confirmation semantics, and authorization. Given the rich schema that already documents required item fields, and the absence of an output schema, a brief note about return/success reporting would round it out, but the essential calling context is present.

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%, but the description names the key conceptual parameters: dry-run vs confirm, strategy metadata, exact active broker stop rows, and prune_stale is implied by 'exact active broker stop rows.' It does not add details about session_id or tenant_session_id semantics, which remain ambiguous for an agent selecting which session context to use.

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 very specific verb ('register'), resource ('strategy metadata for exact active broker stop rows'), and scope ('dry-run or atomically... batch'). It explains it only changes the local registry, never Avanza, which sharply distinguishes it from live-trading mutation siblings like avanza_stoploss_set_batch or avanza_order_set.

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 tells the agent when confirmation is needed ('confirm=true') and what prerequisites it carries ('requires MCP R/W but not live-trading authorization'). It clearly implies a dry-run default for safe validation. It doesn't explicitly say 'use this instead of avanza_position_strategy_register_batch when...' but its local-only registry framing makes the batch-level use case apparent.

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