Evaluate a strategy against current live market data to check if entry or exit signals are active — read-only signal check, does NOT place any orders. Returns the current asset price and any order intents the signals would produce. Use this when the user asks whether a strategy should be entering or exiting right now, or wants to know the live signal state for a specific strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it declares the operation read-only, states no orders are placed, and describes the return payload (current asset price plus order intents). Gaps remain around auth/permission needs, behavior when strategy_id is invalid, and rate limits.
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?
Three sentences, front-loaded with the core action and the critical read-only disclaimer, then the return shape, then the usage trigger. No filler or redundancy.
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?
No output schema exists, so the description appropriately summarizes the return values (asset price and order intents), which is the key missing piece otherwise. The only remaining gap is sourcing/format of strategy_id, which is a minor omission for a single-parameter 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?
Only one parameter, strategy_id, and schema description coverage is 0% — the schema supplies no explanation of what the value should be. The description refers to "a specific strategy" but never says strategy_id is the identifier obtained from list_strategies/list_playground_datasets or what format it takes.
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?
States a specific verb and resource ("Evaluate a strategy") plus scope ("against current live market data"), and explicitly disclaims order placement. It distinguishes itself semantically from signal-level siblings like evaluate_signal and backtest siblings like run_backtest, but never names an alternative, so it falls short of a 5.
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?
Gives an explicit trigger: "Use this when the user asks whether a strategy should be entering or exiting right now, or wants to know the live signal state for a specific strategy." That is clear context for invocation. It does not state when NOT to use it or name a sibling (e.g., evaluate_signal for a single signal, run_backtest for historical analysis) as the preferred alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.