Crypto futures math: PnL, liquidation, position sizing, carry trade. 19 tools. Not AI estimates.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 23 of 23 tools scored. Lowest: 3.1/5.
Most tools have distinct purposes, but there is some functional overlap (e.g., primitive.average_entry and workflow.run_dca_entry both calculate average entry price). However, descriptions clearly differentiate them by use case and output, minimizing confusion.
Naming follows a consistent pattern: prefix (primitive, system, workflow) followed by descriptive verb_noun (e.g., workflow.run_breakeven_planning, primitive.hedge_ratio). All workflow tools use 'run_' making the convention predictable and clear.
23 tools is on the higher side but appropriate for a comprehensive crypto futures math server. Each tool targets a specific calculation or analysis, justifying the count. A slight reduction might improve simplicity, but current scope is reasonable.
The tool set covers a wide range of essential crypto futures workflows: position sizing, risk/reward, liquidation, funding costs, DCA, breakeven, market profile analysis, and scenario planning. No obvious gaps for the intended domain.
primitive.average_entryAInspectCalculate the weighted average entry price from multiple buy/sell fills (DCA). Use when user has filled at multiple prices and asks "what's my average entry?" Returns: averagePrice, totalSize, totalCost.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| symbol | Yes | Trading pair symbol, e.g. BTCUSDT | |
| exchangeCode | No | Exchange identifier (optional) |
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 mentions the tool returns values (averagePrice, totalSize, totalCost) but does not disclose behavioral traits such as read-only status, side effects, permissions, or rate limits. This is a significant gap for a tool that likely performs a computation without 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 consists of two efficient sentences. The first sentence states the core purpose, and the second adds usage context and return values. Every word earns its place, with no 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 the tool's complexity (nested objects, array input, no output schema, no annotations), the description covers the basic functionality but misses details like how the average is weighted, handling of mixed buy/sell fills, and the role of optional parameters. It is adequate but leaves gaps for edge cases.
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% (2 of 3 parameters have descriptions). The description adds context by explaining the purpose of the 'fills' parameter (multiple buy/sell fills for DCA) but does not elaborate on 'symbol' or 'exchangeCode' beyond the existing schema descriptions. It provides marginal added value.
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 'Calculate the weighted average entry price from multiple buy/sell fills (DCA)', providing a specific verb ('calculate'), resource ('weighted average entry price'), and context ('DCA'). It clearly distinguishes this primitive from sibling workflow tools like workflow.run_dca_entry, which handle full DCA execution.
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 has filled at multiple prices and asks "what's my average entry?"', giving clear when-to-use guidance. While it doesn't mention when not to use or alternatives, the sibling context implies this is a helper primitive, not a full workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
primitive.hedge_ratioAInspectCalculate the short perpetual futures position size needed to hedge a spot holding. Use when user asks "how much should I short to hedge my BTC?" or "what margin do I need for a 100% hedge?". Returns: hedgeNotional, requiredMargin, estimatedFundingCost.
| Name | Required | Description | Default |
|---|---|---|---|
| leverage | No | Leverage on the perp short. Default 1. | |
| spotSize | Yes | Spot position value in USDT | |
| hedgeRatio | No | Percentage of spot to hedge, e.g. 100 for full hedge, 50 for half. Default 100. | |
| fundingRatePct | No | Current 8h funding rate as percentage, e.g. 0.01. Used for cost estimate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses what the tool computes and returns (hedgeNotional, requiredMargin, estimatedFundingCost) and lists input parameters. However, it lacks details on behavioral traits like idempotency, computational constraints, or error handling, which are 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?
Extremely concise: two sentences front-loading the purpose and usage examples. Every word earns its place; no redundancy or irrelevant details.
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 4 parameters (1 required, no output schema), the description explains what the tool does, what it returns, and provides example queries. It adequately covers the core functionality but could mention potential limitations or assumptions for 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 100%, so the input schema already documents all parameters. The description adds minimal extra meaning beyond example usage (e.g., 'Default 1' for leverage is already in schema). Therefore, baseline score 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?
Clearly states the tool calculates the short perpetual futures position size for hedging a spot holding, with specific verb 'Calculate' and resource 'hedge ratio'. Examples like 'how much should I short to hedge my BTC?' directly convey the purpose, distinguishing it from sibling 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?
Provides explicit use cases via example queries (e.g., 'how much should I short to hedge my BTC?'). While it doesn't explicitly say when not to use or list alternatives, the examples give clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
system.verifyAInspectRun the full regression suite — 22 canonical test vectors across all 12 calculators — and return a pass/fail report with counts and timestamp. Call this before using results in production workflows to confirm the computation layer is operating correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool runs a regression suite and returns a report, implying a read-only operation. However, it does not explicitly state that no state is modified or that it is safe to call repeatedly.
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, front-loaded with the action, no unnecessary words. 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?
Given no parameters and no output schema, the description is fairly complete. It covers purpose, output, and usage timing. Could add more detail on report format, but not necessary for agent 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?
The input schema is empty with 0 parameters, and schema coverage is 100%. The description adds value by explaining what the tool does, which is sufficient since no parameters need documenting.
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 verb (run), resource (regression suite), scope (22 test vectors across 12 calculators), and output (pass/fail report with counts and timestamp). It distinguishes itself from siblings which are individual workflow or primitive 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 says 'Call this before using results in production workflows to confirm the computation layer is operating correctly,' providing clear when-to-use guidance. It does not list alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_breakeven_planningAInspectCalculate the break-even exit price that covers all trading fees. Use when user asks "what price do I need to just break even?" Returns: breakevenPrice, totalFees.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| sizeBase | Yes | Position size in base asset | |
| entryPrice | Yes | Entry price (positive) | |
| feeOpenPct | No | Opening fee fraction, default 0.0002 | |
| feeClosePct | No | Closing fee fraction, default 0.0005 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. The description indicates it is a read-only calculation (no side effects) by stating it 'calculates' and 'returns' values, but it does not explicitly state that it does not modify any state or require special permissions. For a simple computation tool this is adequate but not exceptional.
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 containing only essential information. The first sentence states the purpose, and the second provides usage cue and return fields. No unnecessary words or repetition. Well-structured for quick comprehension.
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 simplicity (calculation with 5 parameters, no output schema), the description covers the core purpose and return values adequately. It lacks mention of edge cases or default behaviors (e.g., default fee values), but for typical use it is sufficient. The presence of an output schema would have been helpful but is not required.
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 out of 5 parameters have descriptions). The description does not add any additional meaning beyond the schema for the parameters. Since coverage is high, the baseline is 3; the description provides no extra semantic value for parameters, so the score remains at 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 states the tool's purpose: calculate the break-even exit price covering all trading fees. It specifies the exact user query to use it for ('what price do I need to just break even?') and lists the outputs (breakevenPrice, totalFees). This distinguishes it from sibling workflow tools that focus on different calculations or strategies.
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 an explicit usage trigger ('Use when user asks...') that helps the agent decide when to invoke this tool. However, it does not mention when not to use it or provide alternatives, such as the sibling 'workflow.run_funding_breakeven' which might be more appropriate for funding-specific scenarios. Still, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_breakout_acceptanceBInspectMarket Profile breakout acceptance — did price accept (hold) beyond the value area / range, or reject back inside (fakeout)? Optional buy/sell delta. Use for "did the break above VAH get accepted?".
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Exchange to fetch candles from when candles[] not supplied | |
| candles | No | Optional OHLCV for the session — omit to fetch from venue (reproducible + 0 COGS when supplied) | |
| timeframe | No | Candle timeframe (default 15m) | |
| instrument | Yes | Symbol, e.g. BTCUSDT | |
| prev_candles | No | Optional OHLCV for the previous session | |
| session_date | Yes | Session date YYYY-MM-DD (UTC) | |
| include_delta | No | Include buy/sell delta analysis (default true) | |
| value_area_rule | No | Value-area fraction 0.5–0.9 (default 0.70) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions optional buy/sell delta but does not disclose if tool is read-only, modifies state, requires permissions, or what the output represents. Minimal behavioral context beyond the core question.
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 succinct with key concept front-loaded. Two concise sentences with no waste. Slightly more detail on output would improve, but overall 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?
No output schema and no annotations; description does not explain return values (e.g., boolean, score, delta details). For an analytical tool, this leaves the agent guessing about what the tool provides, making it incomplete.
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 each parameter already has a description. The tool description adds the high-level concept of breakout acceptance but does not add further meaning to parameters beyond what the schema provides. Baseline score 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?
Description clearly states the tool evaluates breakout acceptance in Market Profile context with specific verb+resource ('did price accept/hold beyond value area'). It is distinct from sibling tools like run_session_structure, but does not explicitly differentiate.
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 a concrete use case ('Use for did the break above VAH get accepted?') but does not specify when not to use or list alternative tools. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_carry_tradeAInspectDelta-neutral carry trade (funding arbitrage) analysis. Use when user asks "is this carry trade worth it?" — long on exchange A, short on exchange B, collect the funding rate spread. Returns: netYieldPct, grossProfit, netProfit, breakevenDays, verdict (profitable/marginal/loss).
| Name | Required | Description | Default |
|---|---|---|---|
| notional | Yes | Position notional in USDT | |
| hold_days | Yes | Hold duration in days | |
| interval_hours | No | Funding interval: 1 or 8 hours (default 8) | |
| transfer_fee_pct | No | One-way transfer fee % (default 0.1) | |
| funding_rate_long | Yes | Funding rate on long exchange per interval (decimal) | |
| funding_rate_short | Yes | Funding rate on short exchange per interval (decimal) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists return fields (netYieldPct, grossProfit, etc.) which hints at the analysis nature. However, it does not disclose whether the tool performs any side effects, requires permissions, or has assumptions (e.g., no slippage). The description is adequate but not rich in behavioral context.
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 three sentences: purpose, usage trigger, and return fields. It is concise, well-structured, and front-loaded with the most important information. Every sentence adds value 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 the return fields, which is helpful. It covers the core purpose, usage context, and returns. However, it could mention potential error conditions or limitations (e.g., not accounting for exchange-specific fees beyond transfer fee). Overall, it is complete enough for an analytical 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 100%, so the baseline is 3. The description adds context by linking parameters to the scenario (e.g., long exchange funding rate), but it doesn't provide details beyond what the schema already describes. No significant added meaning.
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 'Delta-neutral carry trade (funding arbitrage) analysis' and specifies the exact use case: 'Use when user asks 'is this carry trade worth it?' — long on exchange A, short on exchange B, collect the funding rate spread.' This provides a specific verb+resource and distinguishes it from sibling tools like workflow.run_funding_arbitrage and workflow.run_funding_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 context for when to use the tool ('Use when user asks...') and describes the scenario (long/short on different exchanges). However, it does not explicitly state when not to use it or mention alternative tools among the many siblings. The differentiation from similar tools like workflow.run_funding_arbitrage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_compound_fundingAInspectProject capital growth from reinvesting perpetual futures funding income (compounding carry). Use when user asks "how much will I make compounding 0.01% funding for 90 days?" or "what's my APY on this carry position?". Returns: finalCapital, totalEarned, apy, growthTable.
| Name | Required | Description | Default |
|---|---|---|---|
| reinvestPct | No | Percentage of earnings reinvested each interval. 100 = full compounding, 0 = no reinvestment. Default 100. | |
| durationDays | Yes | Number of days to project | |
| intervalHours | No | Funding interval: 8 (standard) or 1 (Hyperliquid) | |
| fundingRatePct | Yes | Funding rate per interval as percentage, e.g. 0.01 for 0.01% | |
| initialCapital | Yes | Starting capital in USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the full burden. It does not disclose that this is a simulation assuming constant funding rates, nor does it mention limitations or assumptions. It lists output fields but lacks depth on behavior.
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 examples, output fields. No wasted words, 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?
Without an output schema, listing return fields is helpful. The examples clarify typical inputs. However, missing details like growthTable structure or assumption of constant funding rate slightly reduce 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 100%, so the baseline is 3. The description adds example usage that implies parameter roles, but does not provide significant additional meaning 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 'project' and identifies the resource 'capital growth from reinvesting perpetual futures funding income'. It provides example user queries that distinguish this tool from sibling tools like workflow.run_carry_trade and workflow.run_funding_arbitrage.
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 the tool with two example user queries. It does not mention when not to use or suggest alternatives, but the examples make the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_dca_entryBInspectDCA entry planner: weighted average entry price, breakeven, and per-level contribution from multiple fill prices and sizes. Use when user bought at several prices and asks "what's my average entry?" or "where is my DCA breakeven?". Returns: averageEntry, breakeven, per-level summary.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| entries | Yes | ||
| fee_open_pct | No | Open fee rate (default 0.0002) | |
| fee_close_pct | No | Close fee rate (default 0.0005) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavioral traits. It states returns (averageEntry, breakeven, per-level summary) but does not mention side effects, permissions, rate limits, or error handling. Insufficient for a tool with no annotation safety net.
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 a returns line. Front-loaded with purpose, then usage, then output. No wasted words. 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?
Adequate for a calculator with 4 parameters and no output schema. Returns fields are mentioned, but no details on per-level summary structure, fee application, or edge cases like invalid entries. Could provide more context.
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% (fee params described), but description adds little: only rephrases entries as 'multiple fill prices and sizes' and side as long/short. No extra detail on fee parameters or how they are used. Missing parameter descriptions are not compensated.
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 it calculates weighted average entry price, breakeven, and per-level contribution from multiple fill prices and sizes. It specifies it's for DCA entry planning but does not explicitly contrast with sibling primitive.average_entry, so not fully distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use cases: 'when user bought at several prices and asks what's my average entry? or where is my DCA breakeven?' However, it does not mention when not to use it or alternatives like primitive.average_entry for simpler queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_exit_targetAInspectCalculate the exact exit price needed to hit a target PnL or ROE percentage. Use when user asks "at what price do I take profit to make $500?" or "where should I set TP for 20% ROE?". Returns: targetExitPrice.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| leverage | Yes | Leverage multiplier | |
| sizeBase | Yes | Position size in base asset | |
| entryPrice | Yes | Entry price | |
| feeOpenPct | No | Opening fee fraction, default 0.0002 | |
| targetMode | Yes | "pnl" = target in USDT, "roe" = target in % | |
| feeClosePct | No | Closing fee fraction, default 0.0005 | |
| targetValue | Yes | Target value (USDT or %) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states it calculates and returns a price, but does not mention that fees (feeOpenPct, feeClosePct) are incorporated, nor does it discuss edge cases like unattainable targets or side effects. These are important gaps for a financial 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?
The description is two sentences long, front-loads the core purpose, and includes a return type hint. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and a financial calculation context, the description covers the basic use case but lacks details on fee handling, validation, error states, and output format. It is functional but not comprehensive.
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 (88%), so the description adds only modest value. The examples help clarify targetMode and targetValue usage, but the description does not explain how parameters like side, leverage, or fees interact in the calculation. It leans heavily on 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 exact exit price for a target PnL or ROE, provides concrete user query examples, and names the return value. This makes the purpose very specific and actionable, distinguishing it from other planning tools like breakeven or 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 explicitly says 'Use when user asks...' with representative queries, giving clear context for when to invoke the tool. However, it does not provide negative examples or explicitly name alternative sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_funding_arbitrageAInspectCalculate funding rate arbitrage profit: annualized yield, net profit, and breakeven days for a long/short basis trade across two exchanges. Use when user asks "is this funding arb worth it?" or "how many days to break even on transfer fees?". Returns: netProfitUsdt, annualizedYieldPct, breakevenDays.
| Name | Required | Description | Default |
|---|---|---|---|
| durationDays | Yes | Holding period in days | |
| positionSize | Yes | Position size in USDT | |
| intervalHours | No | Funding interval: 8 (standard) or 1 (Hyperliquid) | |
| transferFeePct | No | One-time transfer/setup fee as percentage, e.g. 0.1 for 0.1% | |
| longFundingRate | Yes | Funding rate on long side (% per interval, positive = you pay) | |
| shortFundingRate | Yes | Funding rate on short side (% per interval, positive = you receive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields (netProfitUsdt, annualizedYieldPct, breakevenDays) but does not state whether the tool is read-only, idempotent, or has 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?
Three sentences: first defines purpose, second gives use cases, third lists returns. 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?
Adequately explains the tool's function and returns. Could mention assumptions like constant funding rates or no slippage, but for a calculation tool the current level is 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 descriptions cover all 6 parameters (100% coverage), so description does not need to add param details. It does not, which is acceptable; 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 funding rate arbitrage profit including annualized yield, net profit, and breakeven days. It distinguishes from siblings like workflow.run_funding_breakeven by focusing on arbitrage across two exchanges.
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 funding arb worth it?' or 'how many days to break even?'. Provides clear context but does not mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_funding_breakevenAInspectPrice move needed to cover funding cost + fees over a holding period. Use when user asks "how much does BTC need to move for me to profit after funding?" or "is funding killing my edge on this trade?". Returns: breakevenWithFunding, breakevenWithoutFunding, requiredMovePct.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| size | Yes | Position size in base currency | |
| hold_hours | Yes | Hold duration in hours | |
| entry_price | Yes | Entry price | |
| fee_open_pct | No | Open fee rate (default 0.0002) | |
| funding_rate | Yes | Funding rate per 8h period (decimal, e.g. 0.0001) | |
| fee_close_pct | No | Close fee rate (default 0.0005) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return fields (breakevenWithFunding, etc.), but does not mention behavioral traits such as idempotency, no side effects, or prerequisites like wallet connection. It is adequate but could be more explicit.
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 very concise, using three sentences to cover purpose, usage examples, and return values. Every sentence adds value with 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?
Given the tool is a simple calculation with no output schema, the description covers the return fields adequately. It could mention the output is for a single period but overall is complete for its 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 coverage is 86% (high), so baseline is 3. The description mentions 'funding cost + fees' but does not add meaning beyond what the schema already provides for each parameter. No additional parameter details are given.
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 the price move needed to cover funding costs and fees over a holding period, matching the name and providing concrete user queries. However, it does not explicitly differentiate from sibling tools like workflow.run_funding_cost.
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 specific user questions ('how much does BTC need to move for me to profit after funding?') that trigger this tool, giving clear context. It lacks guidance on when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_funding_costAInspectCalculate the total funding cost (or income) for holding a perpetual futures position. Use when user asks "how much funding will I pay holding X days?" or "is funding eating my profit?". Returns: totalFundingUsdt (negative = you pay, positive = you receive), perIntervalUsdt.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | Number of days to hold | |
| side | Yes | ||
| sizeBase | Yes | Position size in base asset | |
| entryPrice | Yes | Entry price | |
| fundingRate | Yes | Funding rate per 8h period as fraction, e.g. 0.0001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the return format and sign convention (negative = pay, positive = receive). It also mentions 'perIntervalUsdt'. For a calculation tool, this is sufficient behavioral 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: purpose, usage, returns. No unnecessary words. Front-loaded with the core function. 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?
With 5 required parameters and no output schema, the description explains the return structure and sign convention. It provides enough context for an agent to understand inputs and outputs without additional documentation.
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%, and the description adds value by explaining the funding rate as 'per 8h period as fraction'. It also contextualizes the 'days' parameter in the usage examples. The return values are explained 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 verb 'Calculate' and the resource 'total funding cost (or income) for holding a perpetual futures position'. It also specifies the return values and differentiates from sibling tools by focusing on cost for holding rather than arbitrage or 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?
Explicit usage examples are given: 'how much funding will I pay holding X days?' and 'is funding eating my profit?'. While it doesn't explicitly state when not to use or list alternatives, the context is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_liquidation_safetyAInspectCalculate the liquidation price for an isolated-margin futures position. Use when user asks "where will I get liquidated?" or "how close is my liq price?". Returns: liquidationPrice, distancePct (how far from entry).
| Name | Required | Description | Default |
|---|---|---|---|
| mmr | No | Maintenance margin rate, default 0.005 (0.5%) | |
| side | Yes | ||
| leverage | Yes | Leverage multiplier, e.g. 10 for 10x | |
| entryPrice | Yes | Entry price (positive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. it states return values (liquidationPrice, distancePct) but lacks disclosure of potential errors, edge cases, or that it is a read-only calculation. Adequate but not comprehensive.
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 with no wasted words. Purpose, usage hints, and returns are 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?
No output schema but return fields are mentioned. Parameter explanations are in schema. Could explain the formula or assumptions, but for a simple calculation it is 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 75% with descriptions for each parameter. Description does not add meaning beyond the schema, so 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 liquidation price for isolated-margin futures positions and gives example user queries. While specific, it does not explicitly distinguish from sibling tools, but the context of siblings suggests no overlap.
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 when to use ('when user asks...'), providing clear usage context. No mention of when not to use or alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_max_leverageAInspectCalculate the maximum safe leverage based on account size, max acceptable drawdown, and asset daily volatility. Use when user asks "what's the max leverage I should use on BTC?" or "how much leverage is safe given 3% daily volatility?". Returns: maxLeverage, marginAtRisk.
| Name | Required | Description | Default |
|---|---|---|---|
| mmr | No | Maintenance margin rate, default 0.005 (0.5%) | |
| accountSize | Yes | Total account size in USDT | |
| volatilityPct | Yes | Expected daily price volatility as percentage, e.g. 3 for 3% | |
| maxDrawdownPct | Yes | Maximum acceptable drawdown as percentage, e.g. 10 for 10% |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool calculates a value and returns specific fields (maxLeverage, marginAtRisk), implying a read-only computation. It does not mention safety, permissions, or side effects, but the nature of a 'calculate' tool is transparent enough.
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 'Returns:' line, front-loaded with the main action. It is concise and contains no unnecessary 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 adequately covers purpose, inputs, and return fields. It could mention if it relies on real-time data or assumptions, but the provided inputs suggest a self-contained calculation. Overall, it is nearly 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?
Schema description coverage is 100%, so the description does not need to elaborate on parameters. It mentions parameters in the overall purpose but adds no detail beyond the schema's descriptions. 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 the tool calculates maximum safe leverage using account size, drawdown, and volatility. It provides concrete example queries ('what's the max leverage I should use on BTC?') that differentiate it from sibling tools like liquidation safety or risk-reward analysis.
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...' and gives two examples, providing clear context for when to invoke this tool. However, it does not specify when not to use it or mention alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_open_analysisAInspectMarket Profile open analysis — where and how price opened vs the prior session value area. Returns open location, open type (OD/OTD/ORR/OAIR), key levels (VAH/VAL/VPOC/IB), and bullish/bearish/neutral scenario framing. Use for "how did BTC open today?" / "what does the open imply for the session?".
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Exchange to fetch candles from when candles[] not supplied | |
| candles | No | Optional OHLCV for the session — omit to fetch from venue (reproducible + 0 COGS when supplied) | |
| timeframe | No | Candle timeframe (default 15m) | |
| instrument | Yes | Symbol, e.g. BTCUSDT | |
| prev_candles | No | Optional OHLCV for the previous session | |
| session_date | Yes | Session date YYYY-MM-DD (UTC) | |
| value_area_rule | No | Value-area fraction 0.5–0.9 (default 0.70) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes outputs (open type, levels, scenario) but does not disclose side effects, data freshness, or authorization requirements. Adequate for a read-only analysis tool but leaves behavioral assumptions unstated.
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, front-loaded sentences. Every word adds value: purpose, outputs, example queries. No redundancy or fluff.
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 adequately explains return values (open location, type, key levels, scenario) but lacks precise structure or data types. Sufficient for a workflow tool with extensive sibling list; minor gaps in depth.
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 covers all 7 parameters with descriptions (100% coverage). The description adds no new parameter-level meaning beyond the schema; e.g., 'value_area_rule' details are already in schema. Credit for schema coverage keeps baseline at 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?
Description clearly states tool performs 'Market Profile open analysis' and lists specific outputs (open location, open type, key levels, scenario framing). Provides concrete use examples ('how did BTC open today?'), establishing a distinct purpose from sibling tools like run_session_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 states use cases ('Use for...') and provides example queries. Does not explicitly state when not to use or list alternatives, but context implies differentiation from siblings. Lacks explicit exclusion criteria, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_pnl_planningAInspectCalculate net PnL, ROE, fees and gross profit/loss for a futures trade. Use when user asks "what's my profit/loss on this trade?" Returns: grossPnl, fees, netPnl, netPnlUsdt, roe (%).
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | Trade direction | |
| size | Yes | Position size in base asset | |
| exitPrice | Yes | Exit price (positive) | |
| entryPrice | Yes | Entry price (positive) | |
| feeOpenPct | No | Opening fee as fraction, e.g. 0.0002 = 0.02% | |
| feeClosePct | No | Closing fee as fraction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a calculation operation with no side effects, but does not explicitly state it is non-destructive or read-only. The return fields are listed, adding some 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?
The description is concise: two sentences covering purpose, usage, and return values. Every word contributes meaning, and it is front-loaded with the core action.
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 6 parameters and no output schema, the description is fairly complete. It specifies what is computed and when to use it. A minor gap is the lack of explicit formula details, but it is adequate.
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 all parameters have descriptions. The tool description adds no additional parameter details beyond what is in the schema, but it does list return values. 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 the tool's function: 'Calculate net PnL, ROE, fees and gross profit/loss for a futures trade.' It uses a specific verb and resource, and the context distinguishes 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?
The description provides a clear usage scenario: 'Use when user asks "what's my profit/loss on this trade?"' While it does not explicitly mention when not to use or alternatives, the guidance is sufficient for typical agent scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_position_sizingAInspectCalculate the correct position size given a maximum risk in USDT and a stop-loss price. Use when user asks "how many coins should I buy?" or "size my position so I risk exactly $X". Returns: positionSize (base), positionUsdt, marginRequired.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| leverage | No | Leverage, default 1 | |
| riskUsdt | Yes | Maximum acceptable loss in USDT | |
| stopLoss | Yes | Stop-loss price | |
| entryPrice | Yes | Entry price | |
| feeOpenPct | No | Opening fee fraction, default 0.0002 | |
| feeClosePct | No | Closing fee fraction, default 0.0005 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description mentions the return values (positionSize, positionUsdt, marginRequired). It does not disclose any side effects or permissions, but since this is a calculation tool, the behavior is transparent enough. It could note that no trade is executed.
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 very concise: two sentences plus a return line. It front-loads the core purpose, then usage guidance, then returns. 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?
The tool has 7 parameters (4 required) and no output schema. The description covers essential inputs and returns. It could optionally explain how leverage and fees affect the calculation, but overall it is adequate for the agent.
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 86% (6 of 7 parameters described). The description only references riskUsdt and stopLoss beyond the schema, adding little extra meaning for other parameters like leverage and fees. 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 the tool calculates position size given a max risk in USDT and stop-loss price, with specific verb 'calculate' and resource 'position size'. It provides example user queries like 'how many coins should I buy?' which distinguishes it from 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 description explicitly says when to use it: when user asks about sizing a position with a risk amount. It does not mention when not to use or alternatives, but the usage cues are clear and effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_pre_trade_checkAInspectFull pre-trade decision card: orchestrates position sizing, breakeven, liquidation, and funding cost in one call. Use when user describes a full trade setup and asks "should I take this trade?" or "run the numbers on this setup". Provide exchange+symbol to fetch live funding rate automatically. Returns: positionSize, breakeven, liquidationPrice, fundingCost, overnightBreakevenShift, verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| mmr | No | Maintenance margin rate, default 0.005 | |
| side | Yes | ||
| symbol | No | Perpetual symbol, e.g. "BTCUSDT". | |
| exchange | No | Exchange code, e.g. "binance" or "bybit". Used to fetch live funding rate if funding_rate is omitted. | |
| leverage | Yes | Leverage multiplier | |
| risk_pct | Yes | Risk as % of balance, e.g. 1.0 = 1% | |
| stop_loss | Yes | Stop-loss price (positive) | |
| hold_hours | No | Expected hold time in hours for overnight shift calc. Default 8. | |
| entry_price | Yes | Entry price (positive) | |
| fee_open_pct | No | Opening fee fraction, default 0.0002 | |
| funding_rate | No | Funding rate per 8h as decimal, e.g. 0.0001. If omitted, fetched live from exchange. | |
| fee_close_pct | No | Closing fee fraction, default 0.0005 | |
| account_balance | Yes | Total account balance in USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and clearly states the tool orchestrates calculations, fetches live funding rate if omitted, and returns specific fields (positionSize, breakeven, etc.). No side effects are mentioned, but it is likely read-only.
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 list, front-loaded with the key purpose. 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?
The description covers the tool's purpose, usage triggers, and return values. Given the complexity (13 parameters, composite tool), it is adequate but could mention error conditions or prerequisites more explicitly.
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%), and the description adds minor context about exchange+symbol usage. Baseline is 3, and the description does not significantly add 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 tool orchestrates multiple calculations (position sizing, breakeven, etc.) into one call, and provides specific use cases like 'should I take this trade?'. It distinguishes itself from sibling tools that focus on individual components.
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 advises when to use the tool (full trade setup) and recommends providing exchange+symbol for automatic funding rate fetch. However, it does not explicitly mention when not to use it or list alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_risk_rewardAInspectFull risk:reward analysis — the single best tool when user describes a trade with entry, stop, and target. Calculates R:R ratio, position size, liquidation price, breakeven, and P&L at both stop and target. Returns a verdict: strong (3:1+) / good (2:1+) / marginal / poor. Use when user asks "is this trade worth taking?" or "what's my risk reward on this setup?".
| Name | Required | Description | Default |
|---|---|---|---|
| mmr | No | Maintenance margin rate (default 0.005) | |
| side | Yes | ||
| leverage | Yes | Leverage multiplier | |
| risk_pct | Yes | Max risk as % of account | |
| stop_loss | Yes | Stop-loss price | |
| entry_price | Yes | Entry price | |
| take_profit | Yes | Take-profit price | |
| fee_open_pct | No | Open fee rate (default 0.0002) | |
| fee_close_pct | No | Close fee rate (default 0.0005) | |
| account_balance | Yes | Account balance in USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it calculates and returns R:R, position size, liquidation price, breakeven, P&L, and a verdict. No mention of side effects, but as a calculation tool, no destructive actions are expected.
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, front-loaded with purpose and key outputs. Every sentence is necessary and free of fluff, achieving maximum conciseness.
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 10 parameters and no output schema, the description covers essential return values and verdict criteria. It omits parameter ranges or examples, but provides sufficient context for an agent to understand the tool's purpose and results.
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-100%), so baseline is 3. The description adds context by explaining outputs derived from parameters, but does not expand on individual parameter meanings beyond what the schema already 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 full risk:reward analysis, listing specific outputs (R:R ratio, position size, liquidation price, breakeven, P&L) and a verdict. It distinguishes itself as 'the single best tool' for trades with entry, stop, and target, differentiating from sibling 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 tells when to use the tool: 'when user describes a trade with entry, stop, and target' and 'when user asks "is this trade worth taking?" or "what's my risk reward on this setup?"'. It implies alternatives exist but does not explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_scale_outAInspectScale-out planner: P&L, ROI, and cumulative P&L for each partial exit level. Use when user wants to take profit at multiple targets — "close 30% at $90k, 30% at $95k, 40% at $100k — what's my total P&L?". Returns: per-level pnl, weightedAvgExitPrice, totalRoi.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| exits | Yes | ||
| total_size | Yes | Total position size in base currency | |
| entry_price | Yes | Entry price | |
| fee_open_pct | No | Open fee rate (default 0.0002) | |
| fee_close_pct | No | Close fee rate (default 0.0005) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It lists output fields (per-level pnl, weightedAvgExitPrice, totalRoi) and implies a read-only planning operation, but it lacks details on side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with purpose, and includes a practical example and clear return list. No extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return values and parameter usage through an example. However, it lacks mention of error conditions, edge cases, or limits on number of exits beyond what schema provides.
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 description coverage, the description adds value by providing a usage example that clarifies the 'exits' parameter structure (array of price and pct objects). This compensates for the schema's missing descriptions on optional fee parameters and reinforces parameter semantics.
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 defines the tool as a scale-out planner computing P&L, ROI, and cumulative P&L for each partial exit level. Includes a concrete example showing multiple exit targets, which distinguishes it from related sibling tools like workflow.run_exit_target or 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 explicitly states when to use ('Use when user wants to take profit at multiple targets'). However, it does not mention when not to use or explicitly contrast with alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_scenario_planningAInspectRun a scenario analysis: compute PnL for multiple price-change percentages at once. Use when user asks "show me my P&L if BTC moves -10%, -5%, +5%, +10%". Returns: array of { deltaPct, exitPrice, netPnl, roe }.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| size | Yes | Position size in base asset | |
| deltasPct | Yes | List of price change percentages, e.g. [-10, -5, 0, 5, 10] | |
| entryPrice | Yes | Entry price | |
| feeOpenPct | No | Opening fee fraction | |
| feeClosePct | No | Closing fee fraction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the return format and the multi-scenario computation. However, it does not discuss side effects, permissions, or edge cases (e.g., how fees are handled, output precision).
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. The action is front-loaded and every sentence adds value. 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?
For a tool with 6 parameters and no output schema, the description explains the purpose and return format adequately. It lacks parameter usage guidance but is sufficient for an AI agent to understand the core functionality.
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 (83% or effectively 100%), so baseline is 3. The description does not add meaning beyond the schema, e.g., it mentions 'deltasPct' as percentages but schema already includes that 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 verb 'compute PnL for multiple price-change percentages' and describes the resource 'scenario analysis'. It distinguishes from sibling tools like run_pnl_planning by specifying multiple scenarios at once, backed with a concrete example query.
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 when-to-use with a direct user query example ('show me my P&L if BTC moves -10%, -5%, +5%, +10%'). Does not state when not to use or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_session_structureAInspectMarket Profile day-type classifier — trend / balance / neutral_trend / normal / normal_var, from TPO, initial balance, range extension and value migration. Use for "is this a trend day or a balance day?".
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Exchange to fetch candles from when candles[] not supplied | |
| candles | No | Optional OHLCV for the session — omit to fetch from venue (reproducible + 0 COGS when supplied) | |
| timeframe | No | Candle timeframe (default 15m) | |
| instrument | Yes | Symbol, e.g. BTCUSDT | |
| prev_candles | No | Optional OHLCV for the previous session | |
| session_date | Yes | Session date YYYY-MM-DD (UTC) | |
| value_area_rule | No | Value-area fraction 0.5–0.9 (default 0.70) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the algorithm sources (TPO, initial balance, etc.) and the output categories, but does not explicitly state safety (e.g., read-only, no side effects) or any limitations. 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?
The description is two concise sentences: the first explains what the tool does and its output, the second provides a usage question. No redundant information, 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?
With 7 parameters all documented in schema and no output schema, the description lists the possible day-types, which is helpful. It lacks details on return structure or error conditions, but the given information is sufficient for most use cases.
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%, with each parameter well-documented (e.g., venue enum, candles optional, timeframe defaults). The tool description adds minimal parameter insight beyond the schema, so 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 is a 'Market Profile day-type classifier' and lists the specific categories (trend, balance, neutral_trend, normal, normal_var). It distinguishes from siblings by focusing on day-type classification using TPO, initial balance, etc., which is unique among the 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 description explicitly provides a usage question: 'Use for "is this a trend day or a balance day?"', giving clear context. While it does not mention when not to use or alternatives, the explicit usage case suffices for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.run_value_migrationAInspectMarket Profile value-area migration across sessions — is value migrating up, down, or overlapping (directional conviction vs balance)? Use for "is value moving higher day over day?".
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Exchange to fetch candles from when candles[] not supplied | |
| candles | No | Optional OHLCV for the session — omit to fetch from venue (reproducible + 0 COGS when supplied) | |
| timeframe | No | Candle timeframe (default 15m) | |
| instrument | Yes | Symbol, e.g. BTCUSDT | |
| prev_candles | No | Optional OHLCV for the previous session | |
| session_date | Yes | Session date YYYY-MM-DD (UTC) | |
| value_area_rule | No | Value-area fraction 0.5–0.9 (default 0.70) | |
| lookback_sessions | No | Sessions to compare, 1–5 (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains the computation (value-area migration) but does not mention that if 'candles' are not supplied, the tool fetches data from the venue (which may involve latency or costs). The description hints at the output (direction) but omits side effects or auth requirements.
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 core concept ('Market Profile value-area migration across sessions') and ends with a practical use case. 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?
Given no output schema, the description should convey the return value. It implies the output is a directional assessment ('up, down, or overlapping') but does not specify format or additional details. With 8 parameters, the description lacks guidance on parameter interactions or workflow steps, leaving gaps for an agent.
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 each parameter having a clear description. The tool description adds no parameter-specific details beyond the schema, so the baseline score of 3 applies. The description provides context for the 'lookback_sessions' parameter by mentioning 'across sessions', but no extra semantic meaning.
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 analyzes Market Profile value-area migration across sessions to determine direction (up/down/overlapping). It provides a concrete use case question, 'is value moving higher day over day?', making the tool's specific purpose unambiguous and distinguishable from sibling 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 description gives a clear use case ('Use for is value moving higher day over day?'), implying when to apply the tool. It does not explicitly exclude alternatives or contrast with sibling tools, but the context of multi-session migration is sufficiently clear for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.