@mutexa/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MUTEXA_ETH_RPC | No | Ethereum RPC URL used by the Aave V3 tools (`aave_reserves` and `plan_loans` with a reserve symbol). Optional; comma-separated URLs are supported for fallbacks. No built-in default endpoint is provided. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hl_marketsA | Live Hyperliquid perp markets sorted by 24h volume: mark price, 24h change, volume, open interest, hourly funding and its annualised rate, max leverage, size decimals and margin tiers (notional bound and max leverage per tier). Filter by coins or take the top N. |
| hl_positionsA | Open perp positions of any public Hyperliquid address: side, size, entry, mark, value, leverage, margin mode, margin and unrealized PnL, with the liquidation price Hyperliquid reports next to the one computed from the position's own state (isolated positions only; cross margin depends on the whole account, so computedLiq is null). |
| liq_priceA | Liquidation price of a fresh isolated Hyperliquid perp position (kind=perp: side, entry, size in coins, isolated margin in USD, and either coin to use that market's live margin tiers or maxLeverage for a single tier), or of a single-collateral, single-debt Aave V3 loan in standard mode (kind=loan: collateral amount, debt in USD, collateral price, liquidation threshold). Uses Hyperliquid's documented formula and Aave's health factor. |
| plan_ladderA | Split one Hyperliquid perp position into isolated slices whose liquidation prices form a band instead of one public line. Placement 'around' keeps the same capital as one position; 'beyond' puts no slice closer to price than the single position (more margin). Give slices, or alertThreshold to size every slice under your alert threshold. Optional cost preview when feeRate and accountCost are given. Uses the market's live margin tiers and mark. |
| plan_loansA | Split one Aave V3 loan (one collateral, one debt, standard mode) into loans with staggered LTV so their liquidation prices form a band. Give collateralSymbol to use the live reserve (LTV, liquidation threshold, oracle price; needs MUTEXA_ETH_RPC), or ltv, liqThreshold and priceUsd to plan offline. Reports the band, extra collateral and whether the single loan is above max LTV. |
| aave_reservesA | Risk parameters of every Aave V3 Ethereum reserve at one block: max LTV, liquidation threshold, liquidation bonus, collateral and borrow flags, frozen and paused state, and the AaveOracle price. The data provider and oracle are resolved from the PoolAddressesProvider, and nothing is reported if it no longer points at the expected Pool. Needs MUTEXA_ETH_RPC. |
| linkability_scoreA | How easily a set of slices could be clustered by an observer, 0 (hard to link) to 100 (easy), with every factor that added points and its suggested fix: slice count, size spread, leverage spread, timing jitter, fresh accounts, private funding and slices above your alert threshold. A heuristic documented in the linkability spec, not a statistical guarantee. |
| tracker_viewA | What public trackers see for any Hyperliquid address: every open position sorted by closest liquidation (side, size, value, leverage, isolated or cross, entry, mark, liquidation price, distance, uPnL), flags for positions above your alert threshold, and optionally a re-plan of each position into isolated slices placed beyond today's liquidation price. Same JSON as the tracker-view CLI. |
| liquidation_mapA | Where the largest Hyperliquid accounts get liquidated on one coin: ranks the leaderboard by 30-day volume or account value, reads the public positions of the top accounts (at most 100), and buckets their notional by liquidation price around the mark (longs below, shorts above). Totals reconcile: in range + outside + no liquidation price = total. The leaderboard is the file the Hyperliquid web app loads, not a documented API. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools target clearly different objects: market data, a single liquidation price, a perp ladder plan, a loan ladder plan, reserve parameters, an aggregate liquidation map, and a linkability heuristic. The one real overlap is hl_positions versus tracker_view, which both return the same open positions of an address; the descriptions differentiate them (tracker-style sorting, alert flags and re-planning), but an agent could easily pick the wrong one. plan_ladder and liq_price are also adjacent, though one computes a single price and the other a slice band.
All names are snake_case, which is good, but the convention is mixed: two domain-prefixed tokens (hl_markets, hl_positions), several noun phrases (aave_reserves, liquidation_map, linkability_score), a verb_noun pair (plan_ladder, plan_loans), and an ambiguous hybrid (tracker_view). The hl_ prefix implies a Hyperliquid namespace that was abandoned for every other Hyperliquid tool. Readable, but not a predictable pattern.
Nine tools is well within the sweet spot, and each one covers a distinct piece of the workflow (market data, position inspection, liquidation pricing, two planning tools, reserve data, a linkability score, and a market-wide liquidation map). No tool appears to be a redundant variant or wrapper of another.
The Hyperliquid side is fairly complete for research and planning, and Aave reserves plus offline loan planning are covered. However, there is no way to read an existing Aave position or health factor by address (liq_price's loan mode requires manual inputs), and the planner tools are one-shot with no way to monitor or re-evaluate a ladder after slices are placed. Execution and account/balance data are entirely absent, so every workflow ends in manual work.