AlgoVault — Crypto Quant Trade Calls

pre_trade_check

Read-only

Returns a pre-trade check of a crypto perpetual futures order against your own rules: each passes or fails with its numbers, then GO, CAUTION or WAIT. Adds isolated liquidation distance, whether it hits before your stop, fees, accuracy needed to break even over your hold, funding by venue (cross-venue) and the regime. Read-only: places no orders.

Input Schema

Name	Required	Description	Default
`coin`	Yes	Asset symbol, e.g. BTC, ETH, SOL.
`side`	Yes	Direction of the order you intend to place: long or short.
`rules`	No	Your rules, each key optional. Saved rules apply too; a failed one returns WAIT.
`sizeUsd`	Yes	Order notional in USD, e.g. 10000.
`stopPct`	No	Stop-loss distance from entry in percent, e.g. 2.
`leverage`	No	Isolated leverage you will use, e.g. 10. Enables the liquidation checks.
`equityUsd`	No	Account equity in USD. Enables the percent-of-equity rules.
`exchanges`	No	Only compare these venues (default: every supported venue).
`holdHours`	No	Expected holding time in hours (default 8); sets the funding cost window.
`orderType`	No	market (taker entry) or limit (maker entry). Default market.	market
`targetPct`	No	Target distance from entry in percent, e.g. 4.
`timeframe`	No	Market-regime timeframe: 1h, 4h or 1d (default 4h).	4h

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / rules / description

Previous value: -"Your rules, each key optional. A rule of yours that fails returns WAIT."New value: +"Your rules, each key optional. Saved rules apply too; a failed one returns WAIT."

Changed6 schema fields changedNov 1, 2026

addedInput schema / properties / equityUsd

Added value: +{
+  "description": "Account equity in USD. Enables the percent-of-equity rules.",
+  "exclusiveMinimum": 0,
+  "maximum": 10000000000,
+  "type": "number"
+}

addedInput schema / properties / leverage

Added value: +{
+  "description": "Isolated leverage you will use, e.g. 10. Enables the liquidation checks.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "number"
+}

addedInput schema / properties / orderType

Added value: +{
+  "default": "market",
+  "description": "market (taker entry) or limit (maker entry). Default market.",
+  "enum": [
+    "market",
+    "limit"
+  ],
+  "type": "string"
+}

addedInput schema / properties / rules

Added value: +{
+  "additionalProperties": false,
+  "description": "Your rules, each key optional. A rule of yours that fails returns WAIT.",
+  "properties": {
+    "maxAccuracyNeededPct": {
+      "description": "Highest direction accuracy, in percent, needed to break even.",
+      "maximum": 100,
+      "minimum": 50,
+      "type": "number"
+    },
+    "maxDailyMovePctEquity": {
+      "description": "Largest equity swing, in percent, from a one-sigma daily move.",
+      "maximum": 100,
+      "minimum": 0,
+      "type": "number"
+    },
+    "maxFundingBps": {
+      "description": "Highest funding over the hold, in bps. Default 10.",
+      "maximum": 10000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "maxLeverage": {
+      "description": "Highest leverage you allow.",
+      "maximum": 200,
+      "minimum": 1,
+      "type": "number"
+    },
+    "maxLossAtStopPctEquity": {
+      "description": "Most equity, in percent, you accept losing at your stop.",
+      "maximum": 100,
+      "minimum": 0,
+      "type": "number"
+    },
+    "maxRoundTripBps": {
+      "description": "Highest round trip in fees plus spread, in bps.",
+      "maximum": 1000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "maxSizePctOf24hVolume": {
+      "description": "Largest order as a percent of a venue's 24h volume. Default 0.1.",
+      "exclusiveMinimum": 0,
+      "maximum": 100,
+      "type": "number"
+    },
+    "minLiqDistanceSigma": {
+      "description": "Liquidation at least this many hold-period volatilities away.",
+      "maximum": 50,
+      "minimum": 0,
+      "type": "number"
+    },
+    "noLiqBeforeStop": {
+      "description": "Fail if liquidation would come before your stop. Default on.",
+      "type": "boolean"
+    },
+    "regimeCheck": {
+      "description": "Flag a regime against your side or a volatile one. Default on.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / stopPct

Added value: +{
+  "description": "Stop-loss distance from entry in percent, e.g. 2.",
+  "maximum": 50,
+  "minimum": 0.01,
+  "type": "number"
+}

addedInput schema / properties / targetPct

Added value: +{
+  "description": "Target distance from entry in percent, e.g. 4.",
+  "maximum": 1000,
+  "minimum": 0.01,
+  "type": "number"
+}

AddedOct 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only: places no orders.' It goes further by sketching the response shape (per-rule pass/fail with numbers, then a GO/CAUTION/WAIT verdict) and naming the extra analyses performed, which is valuable given there is no output schema. It does not mention latency, rate limits, or what happens when optional inputs like leverage or equityUsd are omitted.

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

Conciseness5/5

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

Two sentences, front-loaded with what the tool returns and its verdict scale, followed by the differentiating analyses. The dense clause list is informative rather than padded, and the read-only assurance closes it out cleanly.

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

Completeness4/5

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

For a 12-parameter tool with a nested rules object and no output schema, the description does the essential work of explaining the return structure and the analytical dimensions. It falls slightly short on how optional inputs gate specific checks and on which rules are persisted versus passed per call.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter, including the nested rules object, is documented inline, so the baseline is 3. The description adds conceptual linkage (liquidation distance, break-even accuracy over the hold, cross-venue funding) but no syntax, defaults, or format detail beyond what the schema already provides.

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

Purpose4/5

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

The description names a specific verb and resource: it checks a crypto perpetual futures order against the caller's rules and returns pass/fail plus a GO/CAUTION/WAIT verdict. That is clearly distinct from signal/call siblings like get_trade_call and get_trade_signal, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: 'a pre-trade check of ... an order' you are about to place. There is no explicit when-to-use vs get_trade_call/get_trade_signal guidance, and no when-not conditions or prerequisites such as needing leverage/equity to unlock certain checks.

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

All AlgoVault — Crypto Quant Trade Calls tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

pre_trade_check

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources