tradingcalc

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

With no annotations provided, the description carries the full disclosure burden. It specifies the calculation method ('weighted'), implying quantity acts as the weight, but omits critical behavioral details: whether buys and sells negate each other, handling of zero-quantity fills, side effects (likely none for a 'primitive'), or return value format.

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 a single, densely informative sentence of 9 words. It leads with the verb ('Calculate'), wastes no words, and immediately conveys the tool's function without redundancy or filler.

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?

Given the lack of output schema and annotations, the description should disclose what the tool returns (the calculated price value). While it adequately describes the input domain (trading fills), it omits output format, precision handling, and validation rules (e.g., negative quantities for sells), leaving gaps for a financial calculation primitive.

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?

At 67% schema coverage, the description adds valuable semantic context beyond the schema. The phrase 'weighted average' explains the relationship between 'price' and 'quantity' parameters (weights), and 'fills' contextualizes the domain (trade execution data), which the raw schema entries ('Fill price', 'Fill quantity') do not convey.

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 clearly states the specific action ('Calculate') and resource ('weighted average entry price') with clear domain context ('buy/sell fills'). However, it does not explicitly distinguish from sibling 'primitive.hedge_ratio' or explain why to use this specific primitive versus others.

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?

While the phrase 'from multiple buy/sell fills' implies usage context (aggregate position calculations), there is no explicit guidance on when to use this versus alternatives, preconditions for the fills data, or when this calculation is appropriate versus other workflow tools.

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

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

No annotations provided, so description carries full burden. Compensates by disclosing return values (notional, margin, funding cost) which substitutes for missing output schema. However, fails to clarify if this performs account queries (reads) or is pure math, and omits safety profile (read-only vs trading operation).

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 sentences: first states operation, second states returns. Zero redundancy, appropriate length, information-dense with no wasted words.

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?

Strong compensation for missing output schema by enumerating return values. Complete parameter documentation via schema. Lacks operational details (error conditions, rate limits, account requirements) which annotations would ideally cover.

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 100% with clear descriptions for all 4 parameters (spotSize, leverage, hedgeRatio, fundingRatePct). Description provides conceptual context (spot holding, hedging) but adds no semantic detail beyond schema baseline.

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?

Clear verb (calculate) and specific resource (short perpetual futures position size for hedging). Explains the financial operation distinctly. Lacks explicit differentiation from sibling primitives like average_entry or workflow tools, though the naming convention helps.

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?

Contains functional description implying use case (hedging spot holdings), but provides no explicit guidance on when to select this over alternatives like workflow.run_position_sizing or primitive.average_entry, and no prerequisites or constraints mentioned.

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

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

No annotations provided, so description carries full burden. Adds useful scope ('all 12 calculators') and return format ('pass/fail report'), but omits safety profile (destructive vs safe), execution duration, or side effects that annotations would typically cover.

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 sentences, zero waste. First sentence front-loads action and output; second sentence provides usage context. Every word earns its place.

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?

Adequately complete for a zero-parameter tool. Compensates for lack of output schema by describing return value ('pass/fail report'). Mentions scope (12 calculators) providing necessary context. Could benefit from noting execution cost or duration, but sufficient for complexity level.

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?

Input schema has zero parameters. Per scoring rules, 0 params = baseline 4. Description appropriately requires no parameter explanation.

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?

Description uses specific verb 'Run' with clear resource 'test-vector suite against all 12 calculators' and specifies output 'pass/fail report'. Distinguishes from calculation siblings by positioning as verification/validation tool.

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?

Explicitly states when to use: 'Use this to confirm that calculator results are correct before trusting them.' Provides clear context for verification workflow. Lacks explicit 'when not to use' or named alternatives, preventing a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Calculate' implies a read-only operation, the description fails to specify the return format (scalar price vs. object), whether the calculation includes slippage, or any precision/constraints on the output.

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?

Extremely efficient at 9 words. Front-loaded with the action verb and specific resource. No redundant or wasted language; every word contributes to understanding the tool's singular purpose.

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?

Despite high schema coverage, the absence of annotations and output schema creates significant gaps. For a calculation tool, the description should ideally specify the return value format and units, especially since no output_schema exists to document this.

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 80%, establishing a baseline of 3. The description mentions 'trading fees' which provides semantic context for the feeOpenPct and feeClosePct parameters, and implies the need for entry pricing, but does not explicitly clarify the 'side' or 'sizeBase' parameters or their relationship to the calculation.

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 uses a specific verb ('Calculate') and clearly identifies the output ('break-even exit price') and scope ('covers all trading fees'). However, it lacks explicit differentiation from siblings like 'workflow.run_exit_target' or 'workflow.run_pnl_planning' that also deal with exit calculations.

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?

No guidance provided on when to select this tool versus alternatives (e.g., when to use breakeven calculation vs. exit target planning). No mention of prerequisites or conditions where this tool would be unsuitable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies that the tool performs 'analysis' and returns specific financial metrics plus a verdict, but it does not explicitly state whether this is a simulation-only tool or if it executes actual trades, nor does it mention error handling or data sources.

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 consists of two efficiently structured sentences with zero wasted words, front-loading the strategy type and following with specific metrics and return values.

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?

Given the 100% input schema coverage and absence of an output schema, the description adequately compensates by enumerating the calculated outputs (net yield, ROI, verdict, etc.). It appropriately covers the tool's purpose for a calculation utility, though it could clarify the return data structure.

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 100%, establishing a baseline of 3. The description mentions 'transfer cost' and 'breakeven days' which loosely map to parameters, but does not add syntax details, validation constraints, or semantic context beyond what the schema already provides for each parameter.

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 clearly identifies the tool as performing 'Delta-neutral carry trade analysis' with specific outputs (net yield, gross/net profit, transfer cost, ROI, breakeven days). However, it does not explicitly differentiate this tool from the sibling 'workflow.run_funding_arbitrage', which likely involves similar funding rate calculations.

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 select this tool versus alternatives like 'run_funding_arbitrage' or 'run_funding_cost', nor does it mention prerequisites or conditions for use.

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

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

Strong disclosure given no annotations: 'Project' clearly signals this is a simulation/calculation tool (read-only, no execution). Also documents return values (final capital, APY, snapshot table) which compensates for missing output schema. Missing: error conditions, rate limiting, or caveats about calculation assumptions.

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 sentences, zero waste. First states purpose, second documents returns. Every element earns its place. Appropriate length for the complexity.

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?

Complete for a projection tool: describes intended function, documents outputs (compensating for no output schema), and leverages good schema coverage. Minor gap: lacks explicit confirmation of simulation-only behavior (though 'Project' implies this) and missing sibling contrast for the crowded workflow domain.

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 100%, establishing baseline 3. Description adds domain context (perpetual futures, reinvestment strategy) that semantically frames the parameter set as a cohesive calculation, but does not elaborate on individual parameter syntax or relationships beyond schema definitions.

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?

Excellent: 'Project capital growth from reinvesting perpetual futures funding income' provides a specific verb (project), clear resource (perpetual futures funding income), and distinguishes from siblings like run_funding_cost or run_funding_arbitrage through the 'reinvesting' and 'compound' aspect implied by the name and description.

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?

Implied usage through specificity (mentions 'reinvesting' which signals compounding use cases), but lacks explicit when-to-use guidance or differentiation statements like 'Use this instead of run_funding_cost when modeling reinvestment effects.' No alternatives or exclusions named.

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

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

With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It mentions what gets calculated (weighted average, breakeven) but fails to disclose whether the tool is read-only (likely), what format the response takes, or any computational limitations. It does not mention that fees are factored into the breakeven calculation despite fee parameters existing in the schema.

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 a single dense sentence with no filler text. The colon structure effectively separates the tool type from its outputs. While efficient, it borders on cryptic—it could benefit from slightly more elaboration to clarify the relationship between inputs (entries array) and outputs for better scannability.

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?

Given the tool has 4 parameters including a nested array structure (entries with price/size objects), no annotations, and no output schema, the description is insufficient. It omits constraints like the 2-20 entry level limit, does not describe the return value format (critical for a calculation tool), and fails to contextualize the fee parameters' role in the 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 description coverage is 50% (fee_open_pct and fee_close_pct are documented in schema, side and entries are not). The description adds semantic value by referencing 'multiple fill prices and sizes', which clarifies the purpose of the entries array parameter. However, it does not explain the 'side' parameter (long/short) or acknowledge the fee parameters, leaving gaps that the schema only partially covers.

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 clearly identifies the tool as a DCA (Dollar Cost Averaging) calculator that computes weighted average entry price, breakeven levels, and per-level contributions. It uses specific financial terminology that accurately describes the domain. However, it fails to differentiate from the similar sibling tool 'primitive.average_entry' or explain why to use this workflow version over the primitive.

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 use this tool versus alternatives like 'primitive.average_entry' or 'workflow.run_breakeven_planning'. It does not mention prerequisites, such as needing at least 2 entry levels (per schema constraints), nor does it clarify the trading context (long vs short) implications.

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

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

No annotations are provided, so the description carries full disclosure burden. While 'Calculate' suggests a read-only operation, the description fails to confirm this, describe the output format (critical since no output schema exists), or mention error conditions (e.g., impossible targets given leverage constraints).

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?

Single 12-word sentence delivers maximal information density. The sentence is front-loaded with the action verb and every word contributes to the functional definition without 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?

For a complex financial calculation tool with 8 parameters (including fee fractions) and no output schema, the description omits critical context: it does not mention that fees are factored into the calculation, does not describe the return value (presumably a price level), and provides no guidance on valid input ranges or constraint violations.

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 88% (high), establishing a baseline of 3. The description mentions 'PnL or ROE' which contextualizes targetMode/targetValue, but adds no semantic detail for feeOpenPct/feeClosePct despite their importance to the calculation, nor clarifies the 'sizeBase' unit expectations beyond the schema.

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 clearly states the specific calculation performed (exit price for target PnL/ROE) using a precise verb. It implicitly distinguishes from siblings like run_breakeven_planning by focusing on profit targets rather than breakeven, though it lacks explicit contrast with workflow.run_pnl_planning.

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 select this tool versus alternatives like run_pnl_planning or run_scenario_planning. It states what the tool does but offers no decision criteria for tool selection.

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

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

No annotations provided, so description carries full burden. Adds valuable output context (annualized yield, net profit, breakeven days), but missing critical safety disclosure: does not clarify whether this performs calculation-only or actually executes/managed trades—a crucial distinction for financial workflows that the agent needs to know.

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?

Single 23-word sentence with zero waste. Front-loaded verb ('Calculate'), immediately followed by outputs and domain context. Every clause earns its place—no redundancy with schema or tautology.

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?

Strong coverage given constraints: compensates for missing output schema by explicitly listing return values (annualized yield, net profit, breakeven days). Missing one element: explicit confirmation that this is a calculator (non-destructive) rather than trade executor, which would complete safety context given the 6-parameter complexity.

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 has 100% coverage (baseline 3). Description adds valuable semantic context linking parameters: 'long/short basis trade across two exchanges' explains the relationship between longFundingRate and shortFundingRate (different exchanges) and implies intervalHours governs both legs. Elevates above pure schema documentation.

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?

Excellent: specific verb 'Calculate' + resource 'funding rate arbitrage profit' + scope 'long/short basis trade across two exchanges'. Clearly distinguishes from siblings like 'run_funding_cost' (single-side cost) and 'run_breakeven_planning' (breakeven analysis) by specifying the arbitrage domain and dual-exchange context.

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?

Implied usage through specificity ('funding rate arbitrage' signals arbitrage opportunity analysis), but lacks explicit when-to-use guidance vs. alternatives like 'run_funding_cost' or 'run_compound_funding'. No explicit exclusions or prerequisites mentioned.

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

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

With no annotations provided, the description carries the full disclosure burden and effectively describes the return structure: 'Returns breakeven with and without funding, and required move as % of entry.' This clarifies the tool produces multiple calculated values (breakeven prices and percentage move), which is crucial given the lack of output schema. It does not disclose calculation methodology (e.g., funding compounding assumptions).

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 consists of two tightly constructed sentences with zero waste. The first sentence establishes the core calculation purpose; the second specifies the return values. Every phrase earns its place with no redundancy or generic filler.

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?

Given high input schema coverage (86%) and the description's disclosure of return values (compensating for no output schema), the description is adequate. However, for a financial calculation tool with no annotations, it lacks methodological context (e.g., fee calculation logic, funding intervals) and usage prerequisites that would make it fully complete.

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 86% schema description coverage, the baseline is 3. The description adds semantic value by grouping parameters into business concepts ('holding period,' 'funding cost,' 'fees') but does not elaborate on specific formats, constraints, or relationships beyond what the schema already provides (e.g., it does not explain the per-8h funding rate logic mentioned in the schema).

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 clearly states the tool calculates the 'Price move needed to cover funding cost + fees over a holding period,' specifying the exact financial metric (breakeven price move) and cost components (funding + fees). It implicitly distinguishes from siblings like run_funding_cost (which calculates cost only) and run_breakeven_planning (general vs funding-specific).

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 explicit guidance on when to use this tool versus alternatives like run_funding_cost, run_breakeven_planning, or run_pre_trade_check. While the specificity of 'funding cost + fees' implies usage context, there are no 'when to use' or 'when not to use' statements.

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

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

No annotations provided, so description carries full disclosure burden. Acknowledges bidirectional nature of funding ('cost or income') which is critical behavioral context for perpetual futures. However, lacks disclosure on output format, currency units (quote vs base), or calculation methodology (simple vs compound) given no output schema exists.

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?

Single sentence, 14 words. Front-loaded with action verb. No redundancy or filler. Appropriate density for the complexity level.

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?

With no output schema and no annotations, the description should specify the return value format/units (e.g., 'returns total cost in quote currency'). Currently implies output through 'Calculate' but leaves ambiguity on currency denomination and granularity.

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 80% (4/5 params documented; 'side' lacks description). Description adds domain context ('perpetual futures position') but does not clarify parameter relationships (e.g., how 'days' interacts with 'fundingRate' which is per 8h period) or compensate for the missing 'side' description.

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?

Clear specific verb ('Calculate') and resource ('total funding cost or income' for perpetual futures). Scopes to perpetual futures specifically, which inherently distinguishes from siblings like run_breakeven_planning or run_funding_arbitrage. However, does not explicitly clarify when to use this versus run_compound_funding.

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?

Provides no guidance on when to select this tool versus the many sibling workflow calculators (e.g., run_compound_funding, run_funding_arbitrage). No mention of prerequisites or assumptions (e.g., whether fundingRate should be annualized or per-period).

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

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

No annotations provided, so description carries full burden. 'Calculate' implies read-only computation, but doesn't explicitly clarify this returns a planning value rather than triggering actual liquidation. No disclosure of calculation methodology, precision, or what happens with extreme leverage inputs.

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?

Single sentence, front-loaded with action verb. No redundant words. Every element serves purpose: 'Calculate' (action), 'liquidation price' (output), 'isolated-margin futures position' (scope). Zero waste.

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, yet description doesn't specify return format (price number, currency, precision). With 75% schema coverage and clear domain terminology, adequately complete for a calculation tool, but gap remains on output specification and whether result includes additional safety metrics implied by 'safety' in name.

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 75% (3 of 4 params described), which is above the 80% threshold baseline. Description adds no parameter details beyond schema, but 'isolated-margin' in description hints at why 'side' matters (long vs short). Maintains baseline 3 as schema does heavy lifting.

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?

Description uses specific verb 'Calculate' with clear resource 'liquidation price' and scope 'isolated-margin futures position'. Distinguishes from siblings like run_breakeven_planning or run_exit_target by focusing specifically on liquidation price calculation rather than general planning.

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?

No guidance on when to use this tool versus other calculation/planning siblings (run_breakeven_planning, run_scenario_planning, etc.). No mention of prerequisites like needing established position parameters or when this calculation is needed (e.g., pre-trade risk assessment).

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

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

With no annotations, description carries full disclosure burden. It compensates partially by documenting return values ('recommended leverage and margin at risk') since no output schema exists. However, it omits idempotency, side effects, or execution constraints expected for a calculation tool.

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 sentences with zero waste. First sentence establishes inputs and purpose; second sentence discloses return values. Perfectly front-loaded and sized.

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?

Given 100% schema coverage and no output schema, the description adequately covers the tool's scope by mentioning both input logic and return values. Sufficient for a stateless calculation tool, though could explicitly note it is a read-only analysis operation.

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 100%, establishing baseline 3. Description adds semantic grouping by labeling the required parameters as 'account size, max acceptable drawdown, and asset daily volatility'—providing financial context beyond raw parameter names. Does not mention the optional 'mmr' parameter, but this is acceptable given schema coverage.

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?

Excellent specificity: verb 'Calculate' + resource 'maximum safe leverage' + key inputs. Clearly distinguishes from siblings like run_position_sizing (which sizes specific trades) and run_liquidation_safety (which checks existing positions).

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?

No explicit guidance on when to select this over similar workflow tools like run_position_sizing or run_pre_trade_check. The specific input requirements provide implicit context, but lacks explicit 'when to use/when not to use' direction.

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

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

No annotations provided, so description must carry full disclosure burden. While it lists calculated outputs (net PnL, ROE, fees), it fails to disclose whether this is a read-only calculation or triggers side effects, expected response format, error conditions, or whether inputs are validated (e.g., exitPrice > 0 constraint mentioned in schema but not behavioral implications).

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?

Single sentence, densely packed with specific calculation targets. No redundancy or filler. Front-loaded with action verb and subject. Appropriate length for the complexity level.

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?

With 100% schema coverage and no output schema, description adequately covers inputs but only enumerates expected return values (net PnL, ROE, etc.) without specifying structure. Given it's a workflow tool (typically implying process execution) with no annotations, description should clarify it's a deterministic calculation engine, not a state-changing operation, to be complete.

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?

Input schema has 100% description coverage (all 6 parameters documented), establishing baseline 3. Description adds 'futures trade' context which semantically frames entryPrice/exitPrice for derivatives, but does not elaborate parameter interactions (e.g., how feeOpenPct interacts with size) or provide format examples beyond what schema already contains.

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?

Specific verb (Calculate) and resource (futures trade) clearly stated. Lists specific outputs (net PnL, ROE, fees, gross profit/loss) which distinguishes it from sibling workflow tools like run_breakeven_planning or run_exit_target. However, lacks explicit differentiation text (e.g., 'use this when you need realized PnL vs breakeven analysis'), preventing 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?

Description states what the tool does but provides no guidance on when to invoke it versus sibling workflow tools (e.g., run_breakeven_planning, run_exit_target, run_scenario_planning). No prerequisites, triggering conditions, or exclusion criteria mentioned.

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

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

With no annotations provided, the description carries full disclosure burden but fails to state this is a pure calculation (read-only), doesn't explain the calculation methodology, and omits mention of optional fee/leverage adjustments despite their presence in the schema.

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?

Extremely efficient at 12 words with front-loaded action verb. However, may err toward under-specification given the tool's complexity (7 parameters, financial domain) and lack of supporting annotations or output schema.

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?

Inadequate for a financial calculation tool with 7 parameters and no output schema. Omits critical context: that it handles both long/short sides, accounts for optional fees/leverage, and critically—what value it returns (position size in units, margin required, etc.).

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 high (86%), establishing baseline 3. The description adds semantic context linking 'riskUsdt' and 'stopLoss' parameters to the calculation purpose, but provides no additional color for side, entryPrice, leverage, or fee parameters beyond the schema.

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 clearly states the specific action ('Calculate') and resource ('position size'), and implicitly distinguishes from siblings by specifying the unique input combination of 'maximum risk in USDT' and 'stop-loss price' required for this particular calculation.

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?

No guidance provided on when to use this tool versus siblings like 'run_pre_trade_check' or 'run_pnl_planning', nor any mention of prerequisites such as requiring valid entry/exit prices or risk parameters.

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

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

Without annotations, the description must carry full burden. It successfully discloses the composite nature (orchestrates multiple tools) and output structure (decision card contents). However, it fails to mention significant behavioral traits: live exchange data fetching dependency (funding rate) mentioned only in parameter schema, network failure modes, or calculation latency.

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?

Single dense sentence front-loaded with purpose ('Composite pre-trade check'), immediately followed by inputs, internal mechanics, and outputs. Zero redundancy; every clause adds distinct value.

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?

Strong compensation for missing output schema by detailing the 'structured decision card' contents (position size, breakeven, etc.). Minor gap: no mention of error conditions given the external exchange data dependency, which is relevant for a 13-parameter workflow 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?

Schema coverage is 92%, so baseline 3 applies. Description mentions 'given a single trade setup' as generic context but does not augment specific parameter meanings, formats, or cross-parameter relationships beyond the excellent schema documentation.

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?

Excellent clarity: 'Composite pre-trade check' establishes the verb and scope, while 'orchestrates risk_sizer + breakeven + liquidation + funding_cost' explicitly distinguishes this composite from siblings like workflow.run_position_sizing and workflow.run_funding_cost by listing the specific components it unifies.

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?

Provides implied usage through the orchestration list (suggests this is the 'all-in-one' option), but lacks explicit when-to-use guidance versus individual primitive checks or whether it should be called before every trade vs. only for high-risk setups.

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

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

With no annotations provided, the description carries full burden. It discloses functional outputs (calculated values and verdict) but lacks behavioral context: no mention of side effects, validation errors for impossible price combinations (e.g., stop-loss beyond entry for wrong side), computational complexity, or whether results are deterministic calculations.

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?

Single sentence efficiently structured as '[Scope]: [Specific outputs]. [Return value].' Front-loads 'Full R:R analysis' immediately establishing domain. Zero redundant text; every clause specifies distinct calculations or the verdict return type.

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?

With 10 parameters and no output schema, the description adequately compensates by detailing return values (verdict categories and intermediate calculations). Could improve by noting parameter validation rules or edge cases (e.g., liquidation price below stop-loss), but sufficiently complete for invocation.

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 90% with clear parameter descriptions. The description adds semantic context by framing 'risk_pct' as driving 'position size' and implying the analytical relationship between inputs (entry, stop, target) and outputs, meeting the baseline for high-coverage schemas.

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?

Uses specific verb 'analysis' with comprehensive scope (position size, liquidation price, breakeven, P&L) and distinguishes from siblings by emphasizing the 'verdict' rating output (strong/good/marginal/poor) that aggregates these calculations into a qualitative assessment.

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?

No explicit guidance on when to use this versus siblings like 'run_position_sizing', 'run_breakeven_planning', or 'run_liquidation_safety' which appear to do subsets of these calculations. The term 'Full R:R analysis' implies comprehensiveness but doesn't state when holistic vs. specific analysis is preferred.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure; it indicates the tool is a planner that returns calculated metrics (weighted average exit price, overall ROI), suggesting it is read-only, but omits details about validation logic, side effects, or whether results are cached. The behavior is partially inferred as computational rather than destructive.

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 two-sentence structure efficiently front-loads the tool's purpose (scale-out planner) and specifies return values without redundancy, though the colon-prefixed label 'Scale-out planner:' partially echoes the tool name. Every sentence contributes distinct information about functionality and outputs.

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?

Given the tool's complexity (nested exit structures, fee calculations) and absence of an output schema or annotations, the description adequately covers primary outputs but omits validation constraints (e.g., whether exit percentages must total 100%) and provides minimal detail on parameter interdependencies. It meets baseline needs but leaves operational gaps.

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 67% schema coverage, the description adds crucial semantic context by associating the exits array with 'partial exit level' planning and explaining that fees factor into the P&L calculations mentioned. It clarifies the financial domain purpose of parameters that might otherwise appear as abstract numbers.

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 identifies the tool as a 'Scale-out planner' and specifies it calculates 'P&L, ROI, and cumulative P&L for each partial exit level,' clearly distinguishing it from entry-focused siblings like run_dca_entry or single-exit tools. The explicit mention of 'partial exit level' precisely defines the resource being modeled.

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?

While the term 'Scale-out' implies usage for multi-level exit strategies, the description provides no explicit guidance on when to prefer this over run_exit_target or run_breakeven_planning, nor does it mention prerequisites like ensuring exit percentages sum to 100%. Usage must be inferred from domain terminology.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the computational purpose (calculating PnL for various deltas) but omits operational details like output format, side effects, idempotency, or error handling.

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 a single, efficient sentence that front-loads the core concept ('scenario analysis') and immediately specifies the operation ('compute PnL'). No words are wasted.

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?

Given the well-documented schema (83% coverage) and lack of output schema, the description adequately covers the tool's purpose. However, for a financial calculation tool with 6 parameters and no annotations, it could benefit from hints about output structure or valid percentage ranges.

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 83% schema description coverage, the baseline is 3. The description adds semantic context by clarifying that 'deltasPct' represents price-change percentages for scenario analysis, but does not elaborate on the optional fee parameters or the 'side' enum beyond what the schema provides.

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 clearly states the tool performs 'scenario analysis' and 'compute PnL' for 'multiple price-change percentages at once,' providing specific verb and resource context. However, it does not explicitly differentiate from the similar sibling 'workflow.run_pnl_planning' or other workflow 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 'at once' implies this is for batch scenario processing, but there is no explicit guidance on when to use this tool versus alternatives like 'run_pnl_planning' or 'run_breakeven_planning', nor when to avoid it.

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