Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@polskidegen-hl-tracker List top 5 traders by 7d ROI"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for Hyperliquid — read-only, on-chain wallet analytics for any public address. Plug it into Claude Desktop (or any MCP client) and ask natural-language questions about positions, fills, funding, and realized PnL on Hyperliquid perps & spot.
No keys. No login. Public wallet address in → structured analytics out.
Tool | What it returns |
| Open perp positions: size, entry, mark, unrealized PnL, ROE, leverage, liquidation price + account value / margin / withdrawable |
| Hyperliquid spot balances: free, locked, total (USD value when available) |
| Last N days of fills (trades): timestamp, coin, side, size, price, direction (open/close), PnL, fee — up to 500 rows |
| Realized PnL over |
| Funding payments over N days: net, paid, received, per-coin breakdown |
| Side-by-side comparison of 2–5 wallets on 30d window (account value, PnL, win rate, avg ROI, top position) |
| Current market data for any HL perp: mid, mark, oracle, 24h change, funding rate, open interest, 24h volume |
| Top N traders on Hyperliquid by PnL / ROI / volume over 24h / 7d / 30d / all-time. Covers all 30k+ accounts — no API key, uses HL's own public leaderboard source. Returns addresses you can pipe back into the other tools for deep-dive. |
Related MCP server: hyperliquid-mcp
Edit your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add to mcpServers:
{
"mcpServers": {
"polskidegen-hl-tracker": {
"command": "npx",
"args": ["-y", "polskidegen-hl-tracker@0.2.0"]
}
}
}Restart Claude Desktop. The 7 tools appear in the tool picker.
Any stdio-capable MCP client works. Run the binary directly:
npx -y polskidegen-hl-tracker@0.2.0Try these in Claude Desktop once installed:
Positions: "Show the open Hyperliquid positions for 0xea0027b6ea9b6d7d401b5266979cc3b3ca87a918."
Spot: "What spot tokens does 0x... hold on Hyperliquid?"
Fills: "List the last 7 days of Hyperliquid trades for wallet 0x...."
PnL: "Summarize 30-day realized PnL, win rate, and avg ROI for 0x... on Hyperliquid."
Funding: "How much did wallet 0x... pay or receive in Hyperliquid funding over the last week?"
Compare: "Compare Hyperliquid performance for these 3 wallets: 0x..., 0x..., 0x...."
Price: "What's the current Hyperliquid mark price and funding for HYPE?"
Leaderboard: "Who are the top 5 most profitable Hyperliquid traders in the last 24 hours?"
Leaderboard + deep-dive: "Pull the top 10 HL traders by 30d PnL, then show the current positions of the top 3."
This MCP is 100% read-only. It does not require any private keys, seeds, mnemonics, or logins. Only a public wallet address (0x + 40 hex chars) is needed as input.
All data comes from Hyperliquid's public info endpoint (https://api.hyperliquid.xyz/info).
No external services, no telemetry, no analytics, no tracking.
The exchange endpoint (which would require signing) is never called.
No network calls are made to any host other than api.hyperliquid.xyz.
userFillsByTime / userFunding return up to ~500–2000 events per request. get_pnl_summary covers up to 365 days but the underlying fills endpoint caps the result set — for extremely active traders, numbers over long windows reflect the capped sample.
avg hold time in get_pnl_summary is approximate — it pairs closes with nearest prior opens on the same coin; if the matching open falls outside the fetched window, it's skipped.
USD values for spot balances depend on whether the token has an active mark on allMids.
Built by @polskidegen — Polish crypto/AI trader, building tools for the degen stack.
Issues / PRs: https://github.com/polskidegen/polskidegen-hl-tracker
MIT — see LICENSE.
Compare 2–5 Hyperliquid wallets side-by-side: account value, 30d PnL, win rate, avg ROI, top position.
| Name | Required | Description | Default |
|---|---|---|---|
| addresses | Yes | 2–5 public Hyperliquid addresses to compare side-by-side. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It describes the action and output metrics but does not disclose error handling, authentication requirements, or what happens with invalid addresses. Minimal but adequate for a straightforward read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information: action, resource, count range, and specific metrics. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential information: what it does, what metrics are compared. It lacks detail on return format or edge cases, but is sufficient for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (addresses parameter has a clear description). The tool description adds the list of comparison metrics, which provides extra context beyond the schema. However, it does not clarify address format or provide additional guidance on parameter usage, limiting its added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compare' with resource 'Hyperliquid wallets' and lists exact metrics (account value, 30d PnL, win rate, avg ROI, top position). This clearly distinguishes from sibling tools like get_pnl_summary or get_positions that handle single wallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool compares 2-5 wallets side-by-side, implying use for multi-wallet comparison. While it does not explicitly exclude single-wallet use or mention alternatives, the context combined with sibling tool names makes the usage scenario sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent fills (trades) for a Hyperliquid wallet. Returns up to 500 fills from the last N days (default 7).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Public Hyperliquid wallet address (0x-prefixed, 40 hex chars). | |
| days | No | Lookback window in days (default 7, max 90). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: returns up to 500 fills, lookback window with default 7 days and max 90 days. However, it lacks details on whether fills are sorted, pagination, rate limits, or authentication requirements. With no annotations, the description carries full burden but is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and then add key constraints. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description covers input constraints but omits return structure (e.g., fields in each fill). It is adequate for basic use but could improve by describing the output format or linking to documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds the constraint 'up to 500 fills' not present in the schema, enhancing understanding of the tool's capacity. Default and max for 'days' are already in schema, but the added limit is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets recent fills/trades for a Hyperliquid wallet, specifying constraints like up to 500 fills and default 7-day lookback. It distinguishes itself from sibling tools (e.g., get_funding, get_positions) by targeting a specific data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_pnl_summary or get_positions. The description does not mention prerequisites, scenarios where this tool is appropriate, or situations to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get funding payments/receipts for a Hyperliquid wallet over the last N days (default 7). Returns net funding, paid, received, and per-coin breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Public Hyperliquid wallet address. | |
| days | No | Lookback window in days (default 7, max 90). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses output structure (net funding, paid, received, per-coin) but does not mention authentication, rate limits, or data freshness. It is adequate but not comprehensive for a non-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two precise sentences front-load purpose and key details with zero unnecessary words. Every element serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values well. For a simple data retrieval tool, it provides sufficient context, though it does not explicitly contrast with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds value by explaining the lookback window default (7 days) and the breakdown of return data. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and specific resource 'funding payments/receipts for a Hyperliquid wallet', with details on scope (last N days) and output (net funding, paid, received, per-coin breakdown). It distinguishes well from siblings like get_fills or get_pnl_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (funding data over a date range) but does not explicitly state when to use this tool over alternatives or conditions to avoid. It implies usage for funding queries but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute realized PnL summary for a Hyperliquid wallet: total PnL, closed trades, win rate, avg ROI, best/worst trade, avg hold time.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Public Hyperliquid wallet address. | |
| window | No | Time window: 7d, 30d, or all (capped at 365d). | 30d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool computes a summary but does not clarify whether it performs a live calculation, has rate limits, or requires any permissions. The read-only, non-destructive nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and key output fields. It is relatively concise but could be slightly more structured by separating purpose from expected outputs. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description helpfully enumerates output fields (total PnL, win rate, etc.). However, it lacks context on data freshness, error conditions, or prerequisites (e.g., wallet must have trading history). Adequate for a simple aggregation tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both parameters (address and window). The tool description adds no further parameter meaning beyond listing outputs, which is acceptable. Baseline score 3 as schema already defines parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Compute' and resource 'realized PnL summary', listing key outputs (total PnL, win rate, etc.). It clearly distinguishes from sibling tools like get_fills or get_positions by focusing on PnL summary aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when alternatives are better. While the name and context imply it's for PnL analysis, no guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get open perpetual positions for a Hyperliquid wallet (size, entry, mark, uPnL, ROE, leverage, liquidation price) plus account value, margin used, withdrawable.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Public Hyperliquid wallet address (0x-prefixed, 40 hex chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes a read operation returning specific data fields, which is transparent. However, it does not mention potential error conditions, rate limits, or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and lists all key data points. No extraneous words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately covers what the tool does and what it returns. It could mention error handling or edge cases, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter, address, fully described in schema). The description adds value by listing returned fields, but does not add new semantics for the parameter itself. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves open perpetual positions for a Hyperliquid wallet and enumerates the returned fields (size, entry, mark, uPnL, ROE, leverage, liquidation price, account value, margin used, withdrawable). This distinguishes it from sibling tools like get_fills, get_funding, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for current open positions, but lacks explicit guidance on when to use versus alternatives (e.g., for historical data, use get_fills). No usage prerequisites or exclusions are mentioned, but the context of sibling tools provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current market price for a Hyperliquid perp (mid, mark, oracle, 24h change, funding rate, OI, 24h volume).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin symbol (e.g. BTC, ETH, HYPE). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details the returned data (mid, mark, oracle, etc.), giving good transparency. However, it doesn't explicitly state idempotency or safety, which is partially mitigated by the 'get' prefix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the primary action, and efficiently lists all returned fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description sufficiently explains what data is retrieved, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a clear description for 'symbol'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current market price for a Hyperliquid perpetual, and lists specific data points (mid, mark, oracle, etc.), distinguishing it from siblings like get_funding or get_fills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comprehensive perp market data, but does not explicitly state when to use this tool versus alternatives like get_funding, nor provides when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get spot token balances for a Hyperliquid wallet (free, locked, total; USD value where available).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Public Hyperliquid wallet address (0x-prefixed, 40 hex chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavioral info (returns balances and USD values) but does not mention read-only nature, authentication, or rate limits. Adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 16 words, front-loaded with the action and key details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return values (free, locked, total, USD value) which is sufficient for a simple balance tool without output schema. Lacks explicit structure (e.g., array or object) but context signals indicate no nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'address', with a clear description in the schema. The tool description adds no additional information about the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves spot token balances for a Hyperliquid wallet, listing the types (free, locked, total) and USD value where available. This distinctively separates it from sibling tools like get_positions or get_fills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like compare_wallets or get_fills. The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the top N Hyperliquid traders by PnL / ROI / volume over a time window (24h, 7d, 30d, or all-time). Uses Hyperliquid's own public leaderboard endpoint — no API key, covers all 30k+ accounts. Returns addresses you can feed into get_positions / get_pnl_summary / get_fills for deeper analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window: 24h (day), 7d (week), 30d (month), or all (all-time). | 24h |
| limit | No | Number of top traders to return (1–50, default 10). | |
| sort_by | No | Ranking metric: pnl (total USD profit), roi (return on equity %), or volume (traded USD). | pnl |
| min_account_value | No | Optional filter: minimum account value in USD (default 0, i.e. no filter). Use e.g. 100000 to exclude dust accounts. | |
| min_volume_usd | No | Optional filter: minimum traded volume in USD within the selected window (default 0, i.e. no minimum beyond the exclude_zero_volume default). | |
| exclude_zero_volume | No | When true (default), skip accounts with zero traded volume in the selected window. These are typically vaults, settlement accounts, market-making pools, or inactive wallets holding unrealized PnL — not active traders. Set to false only when you explicitly want to see them. | |
| exclude_market_makers | No | When true (default), exclude market makers / HFT accounts. Detected via three heuristics: (1) turnover ratio (volume ÷ account value) above a per-window threshold — real directional traders rarely turn over >25× their equity in a week, MMs turn over 50–500×; (2) PnL efficiency (PnL ÷ volume) below 0.1% — MMs earn on spreads not direction; (3) display-name blacklist (auros, wintermute, jump, flow, gsr, amber, cumberland, b2c2, galaxy, dwf, hlp, vault, mm, etc.). Set to false to include MMs. | |
| max_turnover_ratio | No | Advanced override for the turnover filter used by exclude_market_makers. If set, accounts where volume ÷ account_value exceeds this ratio are dropped. Defaults: 10 for 24h, 25 for 7d, 100 for 30d, no cap for all-time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: public API, no auth, account coverage, and detailed filtering heuristics for exclude_market_makers. It leaves no ambiguity about what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and every sentence adds value. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return values (addresses) and their use with other tools. It covers key aspects: purpose, data source, coverage, and integration, making it complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds no extra parameter meaning beyond what the schema provides, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns top traders by PnL/ROI/volume over time windows, directly addressing what the tool does. It distinguishes from siblings by specifying the return of addresses for use with other analysis tools like get_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: uses public endpoint, no API key, covers all 30k+ accounts, and advises feeding addresses into other tools. However, it lacks explicit when-not-to-use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.3compare_walletsget_fillsget_fundingget_pnl_summaryget_positionsget_priceget_spot_balancesget_top_tradersScored across 8 tools
Each tool targets a distinct aspect of Hyperliquid wallet analysis (positions, fills, funding, PnL, prices, spot balances, comparison, top traders), with no overlapping purposes.
All tools follow a consistent verb_noun snake_case pattern (e.g., get_fills, get_positions, compare_wallets), making the set predictable.
8 tools is well-scoped for a Hyperliquid tracker, covering core wallet metrics without being excessive or sparse.
Covers positions, trades, funding, PnL, prices, spot balances, wallet comparison, and top traders. Minor gaps like historical PnL over custom periods are acceptable for a tracker.
Hosted Hyperliquid MCP server: query OHLCV, funding and positioning data in plain language with a free API key.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
