Skip to main content
Glama
Sign In
Hyperliquid

Hyperliquid

by cryptolir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

hl_set_leverage

Set leverage for one Hyperliquid perpetual asset, choosing cross or isolated margin. Higher values raise liquidation risk and are capped by the owner-set maximum.

Instructions

Set leverage for one asset. Bounded by the owner-set maximum; a higher value returns 403 leverage_exceeded. Raising leverage raises liquidation risk on any open position.

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>",
      "leverage": "<leverage>"
    },
    "name": "hl_set_leverage"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesAsset symbol.
isCrossNotrue for cross margin (default), false for isolated.
leverageYesRequested leverage, e.g. 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the owner-set maximum constraint, the specific 403 leverage_exceeded failure mode, and the consequence that raising leverage increases liquidation risk on open positions. It stops short of stating auth requirements or whether existing positions are immediately re-margined.

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?

Three short sentences, front-loaded with purpose, then constraint/error, then risk. Every sentence carries distinct information and there is no padding or redundancy.

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 mutation tool with no annotations and no output schema, the description supplies the key risk and error context an agent needs. It leaves minor gaps around authentication/prerequisites and the effect on already-open positions, but the core contract is covered.

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%, so the schema already documents coin, isCross, and leverage, making 3 the baseline. The description adds only indirect meaning ('for one asset', 'higher value' raising liquidation risk) and does not explain the cross/isolated choice or valid leverage granularity beyond the schema.

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?

States a specific verb and resource ('Set leverage for one asset'), which is unambiguous against siblings like hl_place_order or hl_cancel_order that operate on orders rather than leverage settings. It never explicitly contrasts itself with a sibling, so it falls short of the top tier, but no sibling overlaps this resource.

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?

'Bounded by the owner-set maximum; a higher value returns 403 leverage_exceeded' gives a precondition and failure boundary, which implies usable ranges. However, there is no guidance on when to call this versus hl_place_order, whether leverage can be changed while a position is open, or whether it applies per-asset or per-symbol pair.

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