Skip to main content
Glama
Sign In
pathiel

pathiel

by Julian-dev28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

size_trade

Read-only

Calculate a trade's size, notional, leverage, margin, stop risk, target payoffs, and liquidation price before placing a bracketed order, plus the maximum margin available.

Instructions

Size one trade before placing it, with the rules place_bracket uses: size, notional, leverage, margin, dollars at risk at the stop, payoff at each target and the liquidation price, plus the most this account's margin allows on the coin. The side follows the levels: stop below entry is a long, above is a short. targets adds a payoff per target price; leverage overrides the default (capped by the profile); equity_usd sizes a what-if account and skips the margin check. Use before every place_bracket; never size a trade by hand. Places nothing. Needs a configured account unless equity_usd is given. Returns {sizing: {side, size, notional_usd, leverage, margin_usd, risk_usd, risk_pct, targets[], liq_px, reason, warnings[]}, max_by_margin}, or the sizing alone for a what-if. A trade that cannot be sized (stop at the entry, equity too small) comes back can_trade false with size null and the reason.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "coin": "<coin>",
      "entry_px": "<entry_px>",
      "stop_px": "<stop_px>"
    },
    "name": "size_trade"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesCoin: a main-dex perp by name (BTC, ETH) or a HIP-3 perp as dex:SYMBOL (xyz:GOLD, xyz:BRENTOIL).
stop_pxYesPlanned stop: below entry for a long, above for a short.
targetsNoTarget prices to report the payoff for.
entry_pxYesPlanned entry price.
leverageNoLeverage to size at (capped by the profile).
equity_usdNoWhat-if equity in USD instead of the account's own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description reinforces this ('Places nothing') rather than contradicting it, and adds real behavioral context: the margin check is skipped when equity_usd is supplied, leverage is capped by the profile, and the side is inferred from stop vs entry. It also discloses the return shape and the failure mode (can_trade false, size null, reason). No output schema exists, so this disclosure is doing genuine work, though the two return descriptions (sizing object vs can_trade false) could be reconciled more tightly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the place_bracket relationship, then constraints, then return shape. It is dense with semicolon-joined clauses and runs long, but every clause carries information an agent needs (side inference, margin bypass, failure case); little is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-input simulation tool with no output schema, the description covers prerequisites, what-if behavior, the full return payload, and the un-sizeable-trade case. Nothing essential to calling it correctly or interpreting its result appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond it: targets yields a payoff per price, leverage overrides the default and is capped, and equity_usd both switches to a what-if account and bypasses the margin check. It also explains the coin/side relationship ('stop below entry is a long'). That is meaningful semantics layered on top of an already-documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Size one trade before placing it') and immediately scopes it against a named sibling by saying it uses the same rules as place_bracket. An agent can distinguish this sizing/simulation tool from the execution tool place_bracket without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing guidance: 'Use before every place_bracket; never size a trade by hand,' plus the negative case ('Places nothing') and the prerequisite ('Needs a configured account unless equity_usd is given'). It also names the what-if path via equity_usd, so both the normal and bypass modes are described.

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

Deploy Server

Other Tools