Suggest Stops

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

Description goes well beyond the readOnlyHint/openWorldHint annotations: it discloses exact error behavior (MCP isError for unknown ticker vs. error object for thin markets), output price units, the entry default, the breakeven trigger rule, and the risk_reward formula. This is substantial behavioral detail that the annotations alone could not convey.

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 dense but every clause earns its place: purpose, formulas, defaults, error modes, and an example. The most important scoping (ATR-based risk plan) is front-loaded, and the worked example at the end makes the call format immediately clear without bloat.

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?

Nothing critical for invocation is missing: required params, defaults, error paths, output-value meaning, and an example are all covered. The presence of an output schema means the return shape does not need to be re-described, and the description still explains the key computational relationships. A complete, self-sufficient definition for this tool.

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 0% schema coverage, the description carries the parameter-documentation burden. It explains side via 'long/short entry', entry default via 'current oracle price', and atr_mult_sl/atr_mult_tp via the ATR(14) multiplier formula. Resolution is the only parameter left unexplained; the example does show ticker format and a typical call.

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 opens with a specific verb+resource: 'ATR-based risk plan' and names the concrete outputs (stop-loss, take-profit, breakeven trigger, trailing level). The example call further anchors it as a position-entry helper. This is clearly distinct from all sibling tools, which are market data, trader stats, or analytics tools.

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 phrase 'Agent-managed position helper' and 'for a long/short entry' give clear usage context, and error conditions (unknown ticker, missing ATR) tell the agent when the tool won't work. There are no explicit alternatives to compare against, but no visible sibling tool fills the same niche, so the absence of an explicit when/ when-not does not much hurt.

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