TradingCalc MCP — Crypto Futures Math

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

No annotations are provided, so the description carries the burden. It discloses the return fields (averagePrice, totalSize, totalCost) and notes it is a weighted average calculation. It does not discuss side effects or auth needs, but for a calculation tool this is adequate.

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 only two sentences, front-loaded with the core action. Every sentence is informative and concise 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?

Given no output schema, the description lists return fields. It covers the core functionality (weighted average from fills) but lacks mention of constraints like same symbol for all fills. Overall fairly complete for a simple utility 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 description coverage is 67%, and the description adds no extra meaning beyond the schema's parameter descriptions. The schema already describes symbol, price, and quantity. No additional context for input or exchangeCode.

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 'Calculate the weighted average entry price from multiple buy/sell fills (DCA)', using a specific verb and resource. It distinguishes itself from sibling workflow tools by being a primitive calculation focused on average entry.

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 clear usage guidance: 'Use when user has filled at multiple prices and asks "what's my average entry?"'. It does not mention when not to use or explicit alternatives, but context is sufficient.

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. It discloses all return fields (hedgeNotional, requiredMargin, estimatedFundingCost) and the nature of the calculation. No hidden behaviors.

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 plus return line; no wasted text. Front-loaded with purpose and usage.

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 no output schema, the description clearly states what is returned. All 4 parameters are explained in schema and supplemented by defaults in description. Complete for a simple calculation 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 100%, but description adds defaults (leverage:1, hedgeRatio:100) and example usage for fundingRatePct. This adds value 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 uses a specific verb ('Calculate') and resource ('short perpetual futures position size needed to hedge a spot holding'), and includes example user queries. It clearly distinguishes from sibling tools, which are mostly 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?

Explicitly states when to use with example queries. Does not explicitly exclude cases or mention alternatives, but the context is clear and the tool is specific enough.

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, the description fully explains the tool's behavior: runs tests, returns report with counts and timestamp. It implies a read-only verification process, which is appropriate. No contradictions.

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, no fluff, front-loaded with action ('Run the full regression suite'), efficient and clear.

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?

Fully explains purpose, scope (22 test vectors, 12 calculators), output, and usage context. No gaps given no parameters or output schema.

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?

No parameters exist, so schema coverage is 100%. The description adds no parameter info, which is unnecessary. Baseline for 0 parameters is 4.

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 runs the full regression suite with specific details (22 test vectors across 12 calculators) and returns a pass/fail report. It distinguishes itself from sibling workflow tools that run individual 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?

Explicitly advises calling this before using results in production, providing clear usage context. Does not explicitly list alternatives, but siblings are distinct, so differentiation is implicit.

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. It reveals it's a calculation returning breakevenPrice and totalFees, but lacks details on input validation, edge cases, or whether it modifies state. Adequate but not rich.

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 purpose, second gives usage hint and return fields. Front-loaded, no 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?

Covers purpose and usage, but lacks detail on fees calculation, return format, or any prerequisites. No output schema, so more context would help. Moderate completeness.

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%, so schema does most of the work. Description adds little beyond purpose, not enhancing parameter meaning. Baseline 3 is appropriate.

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 it calculates the break-even exit price covering all trading fees, with a specific verb ('calculate') and resource ('break-even exit price'). It distinguishes from siblings by focusing on breakeven 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?

Explicitly says 'Use when user asks...', providing clear context for use. However, no mention of when not to use or alternatives among sibling 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 exist, so description carries full burden. It lists returned fields (netYieldPct, grossProfit, etc.) and states it's an analysis, implying no side effects. Could be more explicit about read-only nature, but current disclosure is adequate.

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 covering purpose, usage, and return values. No fluff, front-loaded with key concept. Highly efficient.

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 no output schema, description provides return field names. Though it omits explanation of interval_hours or transfer_fee_pct, schema covers these. Overall adequate for a straightforward analysis 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 100%, so baseline is 3. Description adds no extra parameter information beyond schema definitions. The brief strategy mention doesn't detail parameter usage.

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 clearly states 'Delta-neutral carry trade (funding arbitrage) analysis' and provides a specific user query scenario. It distinguishes from sibling tools like run_funding_arbitrage by focusing on the 'is it worth it?' question and defining the delta-neutral structure.

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 says 'Use when user asks "is this carry trade worth it?"', providing clear context. Does not include exclusions or alternatives, but the specificity compensates.

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 carries full burden. It explains the tool projects capital growth and lists outputs (finalCapital, totalEarned, apy, growthTable). However, it does not disclose key assumptions (e.g., constant funding rate, no fees/slippage) or the compounding mechanism beyond the intervalHours parameter.

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 concise (three sentences) and front-loaded with purpose. The output list could be formatted more cleanly, but it's efficient 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?

Given the tool's complexity (5 params, enum, no output schema), the description provides adequate context: purpose, usage examples, and output fields. It does not explain the growthTable structure, but the overall guidance is sufficient for an AI to select and invoke the 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 100%, so baseline is 3. The description does not add meaning beyond the schema; it merely restates an example query. Schema descriptions already explain each parameter sufficiently.

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's purpose: projecting capital growth from reinvesting perpetual futures funding income. It provides specific examples of user queries ('how much will I make compounding 0.01% funding for 90 days?') that distinguish it from sibling tools like workflow.run_funding_cost or workflow.run_carry_trade.

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 gives explicit use cases ('Use when user asks...') and example queries, but does not provide any when-not-to-use guidance or mention alternative tools. This is clear context for typical use, though excluding inappropriate scenarios would strengthen it.

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, so description carries full burden. It lists return fields but does not disclose calculation details, limitations, or side effects beyond the stated outputs.

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: purpose, usage, returns. No wasted words, front-loaded with key info.

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, description lists returns but omits details of per-level summary. Doesn't cover fee parameters or edge cases, leaving some gaps for a 4-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?

Schema coverage is 50% and description adds no explanation of parameters. The 'side' and 'entries' fields are not described, leaving meaning unclear despite enum and schema structure.

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 computes weighted average entry price, breakeven, and per-level contribution from multiple fill prices and sizes, with specific use cases. However, it does not explicitly differentiate from sibling tools like primitive.average_entry or workflow.run_breakeven_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?

Explicitly says 'Use when user bought at several prices and asks...' providing clear context. Does not mention when not to use or alternatives.

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 fails to disclose that fees are included in the calculation and does not indicate that the tool is read-only or synchronous. The return value is mentioned but not fully detailed.

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 two sentences plus a return note, all essential and front-loaded with no 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 8 parameters and no output schema, the description lacks details on fee handling, side support, and contrast with siblings like workflow.run_pnl_planning.

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% (7 of 8 parameters documented). The description adds no extra meaning beyond the schema, and the 'side' parameter lacks documentation in both the schema and 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?

The description clearly states the specific verb 'calculate' and resource 'exit price', and provides explicit user query examples that differentiate it from similar tools like 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 gives explicit when-to-use context with example user queries, but does not mention when not to use or contrast with sibling 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. It states the return values but does not disclose behavioral traits such as side effects, authentication requirements, rate limits, or edge cases (e.g., negative rates). For a calculation tool, these may be less critical, but more detail could improve transparency.

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: first states purpose and outputs, second gives usage examples, third lists return values. Each sentence adds value without redundancy. Front-loaded with the most important information.

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 (6 parameters, all documented in schema, no output schema), the description is mostly complete. It covers purpose, usage context, and outputs. However, it could mention assumptions like compounding frequency or fee handling to be fully self-contained.

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%, so baseline is 3. The description does not add new meaning beyond the schema; for example, 'intervalHours' enum values are already described in the schema. The description reiterates outputs but does not clarify parameter usage further.

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?

Purpose is stated clearly: calculates funding arbitrage profit including annualized yield, net profit, and breakeven days. Uses specific verb 'calculate' and lists outputs. However, does not explicitly differentiate from sibling tools like 'workflow.run_funding_breakeven' or 'workflow.run_funding_cost', which may overlap in scope.

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 explicit use cases: 'when user asks "is this funding arb worth it?" or "how many days to break even on transfer fees?"'. This gives clear guidance on when to invoke. Does not mention when not to use or alternatives, but the context is well-defined.

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. It states it returns three values but does not disclose whether it fetches live data, assumes current market conditions, or has side effects. Adequate but could be more transparent.

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 purpose, second provides use cases and return fields. No wasted words, front-loaded, and efficiently communicates key information.

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 calculation tool with no output schema, the description includes the return field names. It covers purpose, inputs, and output. Missing assumptions about funding rate periodicity but otherwise complete enough for an agent to use.

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 86%, so most parameters already have descriptions. The description adds context about funding rate period (per 8h) but doesn't significantly enhance meaning beyond the schema. Baseline of 3 is appropriate.

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 it calculates 'Price move needed to cover funding cost + fees over a holding period' and provides specific user queries. This distinguishes it from sibling tools like 'workflow.run_funding_cost' which likely only computes cost, not breakeven.

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 gives explicit use cases ('use when user asks...') and two example queries. It lacks explicit 'when not to use' but provides clear context for when to invoke, making it easy for an agent to decide.

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 fully discloses the tool's behavior: it calculates total funding cost, explains the sign convention (negative = pay, positive = receive), and names the two return fields. For a read-only calculation tool, this covers the essential behavioral traits.

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 extremely concise: two sentences with no filler. The first sentence states the main action, the second gives usage guidance, and the return value hint is naturally integrated. Every sentence serves a 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?

The tool has 5 parameters and no output schema. The description provides the return field names and sign convention, which is sufficient. It doesn't include the formula or edge cases, but for a funding cost calculation, the description is complete enough for an AI to invoke correctly.

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?

The schema has 80% coverage, so most parameters are already described. The description adds clarity on the 'fundingRate' parameter by specifying it is 'per 8h period as fraction' and the 'side' parameter is implicitly explained through the sign of the result. This adds value 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 uses a specific verb phrase 'Calculate the total funding cost (or income)' and identifies the resource as 'holding a perpetual futures position'. It provides example user queries that clearly distinguish this tool from siblings like workflow.run_funding_arbitrage or workflow.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?

The description explicitly tells when to use the tool by citing common user questions ('how much funding will I pay holding X days?' or 'is funding eating my profit?'). It doesn't state when not to use or list alternatives, but the context is clear enough for an AI agent to select the correct tool among siblings.

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 must cover behavioral traits. It only states the calculation and output fields, without disclosing whether the tool is read-only, has side effects, or requires specific permissions. For a tool that performs calculations on user-provided data, more transparency about safety and constraints is needed.

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 extremely concise: two sentences plus a one-line output description. No unnecessary words, and key information is front-loaded.

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?

The tool lacks an output schema, so the description should fully explain the return format. While it mentions 'liquidationPrice, distancePct', it does not define how distancePct is calculated (e.g., percentage of entry price) or the role of the mmr parameter. For a calculation tool with multiple parameters, this leaves gaps in understanding.

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%, and the description does not add significant meaning beyond the schema. The mmr parameter is not explained in the description, and no parameter-specific guidance is given. Baseline of 3 is appropriate.

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 'Calculate the liquidation price for an isolated-margin futures position', specifying a clear verb and resource. The tool name 'liquidation_safety' combined with the description distinguishes it from siblings like 'run_breakeven_planning' or 'run_position_sizing'.

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?

Explicit use cases are provided: 'Use when user asks "where will I get liquidated?" or "how close is my liq price?"'. This helps an AI agent decide when to invoke the tool, but no when-not-to-use or alternatives are 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. It explains the computation and lists return values, but does not disclose whether the tool is read-only, requires authentication, or has side effects. Adequate but not thorough.

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?

Description is two sentences plus a returns line, no redundancy, front-loaded with purpose and usage. Every sentence adds 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?

For a calculation tool with full schema coverage and no output schema, the description explains purpose, usage, inputs, and outputs completely. No gaps for an agent to invoke correctly.

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, so parameters are well-documented. Description adds no additional detail beyond schema; it only mentions the overall calculation. Baseline 3 is appropriate.

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 clearly states the tool calculates maximum safe leverage using account size, drawdown, and volatility. Includes example user queries that distinguish it from sibling tools like run_position_sizing or run_liquidation_safety.

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 says 'Use when user asks...' with two concrete examples, providing clear context. Does not mention when not to use or alternatives, but the examples sufficiently guide 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. It accurately describes a pure calculation with no side effects, and lists return fields. No misleading statements.

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 concise sentences: first defines purpose and outputs, second gives a usage trigger. No wasted words; front-loaded with key information.

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 simple calculation tool with no output schema, the description covers inputs, purpose, and outputs adequately. Could mention potential edge cases, but not necessary for basic usage. Sibling tools are diverse enough that purpose is clear.

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 with descriptions for all parameters. Description adds value by contextualizing the calculation for futures trades and enumerating the return fields (grossPnl, fees, netPnl, etc.), which goes 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?

Description clearly states verb 'Calculate' and resource 'net PnL, ROE, fees and gross profit/loss for a futures trade'. Provides usage example and lists returns, distinguishing it from sibling tools like breakeven or funding 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?

Explicitly says 'Use when user asks "what's my profit/loss on this trade?"' – clear context. Does not mention when not to use or alternatives, but the context is sufficient given the specific purpose.

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, the description carries the full burden. It discloses the return values (positionSize, positionUsdt, marginRequired) and implies a safe, non-destructive calculation. No side effects or auth needs are mentioned, but this is acceptable for a pure computation 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 succinct sentences: purpose first, then usage context and return values. No filler words, perfectly front-loaded.

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 calculation tool with 7 parameters and no output schema, the description explains what it does and what it returns. It lacks examples or edge case handling, but is otherwise sufficient.

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%), so the description adds limited parameter-level detail beyond restating 'maximum risk in USDT' for riskUsdt. Baseline of 3 is appropriate as the schema does most of the work.

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's purpose: calculating position size based on risk and stop-loss. It provides specific use cases ('how many coins should I buy?') and distinguishes from sibling tools in the workflow namespace.

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 gives explicit when-to-use cues via user queries. It doesn't mention when not to use or alternatives, but the context is clear for a calculation tool.

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, the description carries the full burden. It clearly states what the tool does (orchestrates calculations) and lists the return values (positionSize, breakeven, liquidationPrice, fundingCost, overnightBreakevenShift, verdict). There is no indication of destructive behavior or side effects, and no contradiction with annotations.

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 only two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence 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?

The tool has 13 parameters and no output schema. The description lists the return fields but does not explain their meaning, units, or how they relate (e.g., what 'verdict' indicates). For a complex tool, this leaves some gaps in understanding the full behavior.

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 (92%), so the schema already documents most parameters. The description adds minor value by noting that exchange+symbol fetch live funding rate, but this is also in the schema. Baseline 3 is appropriate as the description does not significantly extend understanding 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 it is a 'Full pre-trade decision card' that orchestrates multiple calculations (position sizing, breakeven, liquidation, funding cost) in one call, distinguishing it from sibling tools which are more specific primitives or targeted workflows.

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 explicitly tells when to use the tool: 'Use when user describes a full trade setup and asks "should I take this trade?" or "run the numbers on this setup."' It also advises providing exchange+symbol to fetch live funding rate. While it doesn't explicitly mention when not to use it, the sibling tool names provide clear alternatives for specific cases.

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 must carry the full burden. It reveals the tool computes and returns results (R:R, position size, etc.) but doesn't explicitly state whether it modifies data or requires authentication. The description implies a read-only computation, but it could be more explicit about being non-destructive or any side effects.

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 two sentences with no wasted words. It front-loads the purpose ('Full risk:reward analysis') and then lists outputs and usage cues efficiently. Every sentence adds 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?

The tool has no output schema, so the description must explain return values. It states 'Returns a verdict: strong (3:1+) / good (2:1+) / marginal / poor' and lists computed items, but does not detail the full output structure (e.g., whether all computed values are returned as a JSON object). For a 10-parameter tool, this is moderately complete but could be improved by outlining the return format.

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 high (90%), so the baseline is 3. The description does not add new per-parameter details but contextualizes the overall purpose (entry, stop, target, account balance, risk%, leverage). This is sufficient but not exceptional 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 states 'Full risk:reward analysis' and specifies it calculates R:R ratio, position size, liquidation price, breakeven, and P&L, returning a verdict. It clearly identifies the tool as the best for trades with entry, stop, and target, distinguishing it from sibling tools like workflow.run_breakeven_planning or workflow.run_position_sizing.

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 explicitly says 'Use when user asks "is this trade worth taking?" or "what's my risk reward on this setup?"' and calls it 'the single best tool when user describes a trade with entry, stop, and target.' This provides clear context, but it does not explicitly state when not to use it or name alternatives, though the sibling list implies other tools for other scenarios.

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 must carry the transparency burden. It describes outputs (per-level pnl, average price, ROI) but does not explicitly state that the tool is non-destructive or disclose authorization requirements. For a pure computation tool, this is adequate but not exemplary.

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 concise: two sentences plus a returns list. It front-loads the purpose and uses no filler. Every sentence is informative.

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?

Without an output schema, the description compensates by listing return fields. It covers the main outputs, but lacks details on error conditions or edge cases. For a parameter-rich tool (6 params), this is mostly sufficient.

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 67% (4 of 6 parameters documented). The description adds value via a concrete example showing the exits array structure (price and pct). This supplements schema documentation, raising it above the baseline 3.

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 specifies it's a scale-out planner for computing P&L, ROI, and cumulative P&L at multiple partial exit levels, with a concrete example. This distinguishes it from siblings like single-exit 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 description explicitly states when to use it ('when user wants to take profit at multiple targets') and provides a query example. It does not mention when not to use or compare with alternatives, but the usage context is clear.

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 the burden. It explains that the tool computes PnL and returns an array of objects with specific fields. It does not mention side effects, read-only nature, or prerequisites, but as a computation tool, the behavior is reasonably clear.

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 two sentences: one for purpose and usage, one for return format. Every word earns its place with no fluff. It is front-loaded with the core action and then provides a concise example and output specification.

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 absence of an output schema, the description explicitly lists the return fields (deltaPct, exitPrice, netPnl, roe), which is essential. It covers the basic workflow, though it could mention how fees are applied (since feeOpenPct and feeClosePct are parameters). Overall, it is sufficiently complete for a computational 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 description coverage is high (83%), so the description adds minimal extra meaning beyond parameter names and types. It clarifies the deltasPct parameter through an example, but does not elaborate on feeOpenPct or feeClosePct 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 computes PnL for multiple price-change percentages, using a specific verb 'compute' and resource 'scenario analysis'. It provides an example user query, distinguishing it from sibling tools like run_pnl_planning or run_breakeven_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 includes a concrete usage example ('show me my P&L if BTC moves...'), effectively telling the agent when to invoke it. However, it does not explicitly state when not to use it or name alternative tools, missing a full 'when-not' guideline.

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