FortFi Treasury MCP

propose_hyperliquid_perp_open

Propose opening a Hyperliquid perp position. Runs FortFi perp policy (max leverage, max notional) and rejects non-hyperliquid-mainnet wallets. Optional marginMode picks cross or isolated margin. Returns a proposalId for confirm_proposal.

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": {
      "walletId": "<walletId>",
      "symbol": "<symbol>",
      "side": "<side>"
    },
    "name": "propose_hyperliquid_perp_open"
  }
}

Input Schema

Name	Required	Description
`side`	Yes
`size`	No	Coin-unit size (string). Use sizeUsd instead for USD notional.
`symbol`	Yes	e.g. BTC, ETH, xyz:TSLA, xyz:GOLD
`sizeUsd`	No	USD notional target (min $10 on HL). Preferred for agents.
`leverage`	No
`stopLoss`	No	Optional stop-loss trigger. With limitPrice it attaches to the order (normalTpsl) and arms once it fills, validated against the limit price.
`walletId`	Yes
`limitPrice`	No	Optional resting limit price (GTC). Must be within 5% of mid when it crosses the book. Omit for a market order.
`marginMode`	No	Optional. cross shares the wallet's margin across positions; isolated caps the loss at the margin put into this position. Omit for cross (isolated on isolated-only markets). An already-open position keeps its mode, so a mismatch is rejected.
`takeProfit`	No	Optional take-profit trigger. With limitPrice it attaches to the order (normalTpsl) and arms once it fills, validated against the limit price.
`timeInForce`	No	Limit orders only. Gtc (default), Alo (post only, rejected if it would cross), Ioc.
`closeAfterHours`	No	Optional time stop: FortFi closes the whole position this many hours from now (checked every 5 minutes). Refused on accounts a strategy runs.
`trailingStopPct`	No	Optional. FortFi keeps a stop this % behind the best price since the fill and only ever moves it toward the price (checked every 5 minutes). Needs the set_hyperliquid_managed_exit operation. Same as calling set_hyperliquid_managed_exit after the fill.
`trailStartProfitPct`	No	Optional, with trailingStopPct. Trailing starts only once the price is this % past your entry price (price move, not leverage-adjusted). Until then your normal stop stays put.
`breakEvenAtProfitPct`	No	Optional. Once the price is this % past your entry price, FortFi moves the stop to the entry price.
`acknowledgePriceImpact`	No	Set true only after a HYPERLIQUID_PRICE_IMPACT_CONFIRM_REQUIRED error, to accept >=1% book impact on a market order. Prefer limitPrice or a smaller size.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 5, 2026

addedInput schema / properties / breakEvenAtProfitPct

Added value: +{
+  "description": "Optional. Once the price is this % past your entry price, FortFi moves the stop to the entry price.",
+  "maximum": 500,
+  "minimum": 0.1,
+  "type": "number"
+}

addedInput schema / properties / closeAfterHours

Added value: +{
+  "description": "Optional time stop: FortFi closes the whole position this many hours from now (checked every 5 minutes). Refused on accounts a strategy runs.",
+  "maximum": 2160,
+  "minimum": 0.25,
+  "type": "number"
+}

addedInput schema / properties / trailStartProfitPct

Added value: +{
+  "description": "Optional, with trailingStopPct. Trailing starts only once the price is this % past your entry price (price move, not leverage-adjusted). Until then your normal stop stays put.",
+  "maximum": 500,
+  "minimum": 0.1,
+  "type": "number"
+}

addedInput schema / properties / trailingStopPct

Added value: +{
+  "description": "Optional. FortFi keeps a stop this % behind the best price since the fill and only ever moves it toward the price (checked every 5 minutes). Needs the set_hyperliquid_managed_exit operation. Same as calling set_hyperliquid_managed_exit after the fill.",
+  "maximum": 50,
+  "minimum": 0.5,
+  "type": "number"
+}

First observedNov 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations present, the description carries the burden and does disclose real behavioral facts: policy validation runs before the proposal, non-mainnet wallets are rejected, and execution is deferred behind a proposalId/confirm step rather than firing immediately. It omits what happens to a stale proposal (expiry) and the price-impact confirmation gate that the schema reveals, keeping it from a 5.

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?

Four sentences that are entirely front-loaded: purpose first, then the policy gate, then the one parameter worth calling out, then the return/handoff. No filler and nothing repeated from the schema.

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 16-parameter mutation tool with no annotations and no output schema, the description covers the essentials an agent needs before calling: what is created, what is validated, and what comes back (proposalId). The remaining detail lives in an 81%-covered schema, so the only real gap is lifecycle behavior of the proposal itself.

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 81%, so the schema already explains size vs sizeUsd, stopLoss/takeProfit attachment, marginMode defaults, and trailing-stop mechanics in detail. The description only echoes marginMode ("picks cross or isolated margin"), adding essentially nothing beyond the structured field, so baseline 3 applies.

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?

"Propose opening a Hyperliquid perp position" gives a specific verb (propose) plus resource (Hyperliquid perp position), and the adjacency to siblings propose_hyperliquid_perp_close and propose_hyperliquid_perp_modify is resolved by the word "opening." An agent can pick this out of the perp family without opening the schema.

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

Usage Guidelines4/5

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

It names the gating conditions (FortFi perp policy for max leverage/notional, rejection of non-hyperliquid-mainnet wallets) and states the downstream step via "Returns a proposalId for confirm_proposal," so the propose-then-confirm workflow is explicit. It stops short of saying when to prefer this over a limit/close path or when a market order is appropriate, 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.

All FortFi Treasury MCP 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.

Resources

Need Help?