plan_entry

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

Goes well past the annotations: it discloses the data source and resolution (Yahoo daily bars, latest trade only for KRX), explicit exclusions surfaced as warnings (no options levels, SEC filings, consensus, earnings date), the KRX tick-grid rounding rule and whole-share constraint, and the error contract (ok=false is a tool error naming the problem). It also clarifies staleness semantics — spot is the latest trade from any session and indicators include today's provisional bar unless confirmed_only=true — which is exactly the behavioral context annotations cannot express.

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 critical constraints (not an order, no account access, symbol formats, currency mismatch) are front-loaded and the rest is grouped by concern — sources, return shape, detail levels. It is dense and the detail-level paragraph substantially restates the schema's own enum description, which is the main wasted space.

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 read-only analytical tool with an output schema, this covers everything an agent needs to call it correctly: accepted symbol markets, currency coupling, error signaling, and how detail levels change payload shape (meta.detail_note, dropped_levels formats, style_parameters only in full). No material unknown is left for a 7-parameter, market-scoped calculation.

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 only 14%, so the description carries most of the load, and it does: symbol syntax (US tickers, KRX codes with .KS then .KQ fallback, explicit 000660/005930 examples), currency defaulting and the USD-on-KRX / KRW-on-US CURRENCY_MISMATCH failure, amount as the required input, and confirmed_only's effect on bars and spot. Gaps remain: style and horizon_days get no explanation at all beyond a passing mention that style constants exist.

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 opening clause names a specific computation ('Scaled entry calculation') and immediately disqualifies the most likely misreading ('not an order; no account access'), which separates it from execution-style tools in the sibling list. It also names the concrete artifact produced (tranches with price, percent, amount, touch probability). It stops short of naming an actual sibling to route away from, so it lands at a clear-but-not-exemplary 4.

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?

Usage is only implied: the reader must infer 'call this when you want a tranche plan rather than an order or a raw indicator dump.' The negatives ('not an order', 'no account access') are framing, not when-to-use guidance. The one real routing hint is that RSI/MACD/ATR/MAs come from the same bars as get_technical_indicators, but it never says to prefer that tool for indicators alone.

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