finance_investment_trading_signal

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, and the description does not contradict them. It adds useful scoping context (auth via JWT, tenant, company scope) but discloses nothing about side effects — for a destructive finance/trading tool, the absence of any consequence or gating note is a gap, though the annotation coverage prevents a lower score.

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 compact and well-structured, with a short routing preamble followed by a clear Args list, and no filler. The opener is somewhat redundant with the tool name, which costs the top score.

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 buried among hundreds of siblings, the description is incomplete: an agent cannot determine what outcome the investment_trading_signal action produces or when it is appropriate, and the 0% schema coverage leaves inputs entirely convention-based. The output schema covers return values, but the tool's domain purpose and side-effect profile remain opaque.

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 compensates by documenting both parameters: 'message: Free-text objective' and 'inputs: Optional JSON string of structured inputs for the action.' The meanings are generic — no guidance on what keys the inputs JSON accepts or what a valid objective looks like — yet they still add semantic value beyond the schema's bare titles and defaults.

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 'Run the finance domain agent action `investment_trading_signal`', which restates the tool name rather than explaining what an investment trading signal action actually does. It adds routing mechanics ('domain-agent dispatcher under your JWT, tenant, and company scope') but never states the tool's outcome, so an agent cannot distinguish it from siblings like finance_investment_trading_agent or finance_investment_trade_execution_gate.

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 provides no guidance on when to invoke this tool versus the many finance trading siblings. It mentions the routing path but offers no use cases, conditions, or exclusions that would help an agent choose it over finance_investment_trading_agent, finance_investment_portfolio_backtest, or finance_investment_trade_execution_gate.

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