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., "@Alpha Arena MCP Show my current positions and account balance."
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.
An MCP server that delivers hyperliquid account data, perpetuals market context, and trading tools for AI agents — inspired by nof1.ai and open-nof1.ai.
Alpha Arena MCP bridges AI models with the Hyperliquid perpetual futures exchange, allowing LLMs to:
Analyze real-time market data (prices, indicators, open interest).
Fetch and format account positions and performance.
Execute trades with risk-managed orders (including auto-calculated take-profit/stop-loss).
Close positions or cancel orders programmatically.
Designed for algorithmic trading bots, this server supports both mainnet and testnet operations. It uses the CCXT library for exchange interactions and pandas_ta for technical analysis.
Key Use Case: Integrate with Claude Desktop or similar MCP clients to create an AI trading assistant that generates recommendations based on prompts and executes them via tools.
Related MCP server: Hyperliquid MCP Server
Trading Tools:
Place limit/market orders with leverage, TP/SL (auto-calculated if omitted).
Close all positions for a symbol (reduce-only market orders).
Cancel all open orders for a symbol.
Retrieve formatted account info (balance, positions, PnL).
Get formatted market state (OHLCV, EMAs, MACD, RSI, volume, OI, funding rate).
MCP Prompts:
System prompt for expert crypto analysis.
User prompt template incorporating market/account data for LLM invocations.
Exchange Support: Hyperliquid perpetuals (sandbox/testnet configurable).
Risk Management: Built-in TP/SL calculation based on leverage (2:1 reward:risk ratio).
Error Handling: Graceful fallbacks for API errors.
Python 3.10+
uv for dependency management (recommended; fallback to pip)
A Hyperliquid account with API credentials (wallet address and private key).
Clone the Repository:
git clone https://github.com/kukapay/alpha-arena-mcp.git
cd alpha-arena-mcpInstall dependencies with uv:
uv sync Install to Claude Desktop:
Install the server as a Claude Desktop application:
uv run mcp install main.py --name "Alpha Arena"Configuration file as a reference:
{
"mcpServers": {
"Alpha Arena": {
"command": "uv",
"args": [ "--directory", "/path/to/alpha-arena-mcp", "run", "main.py" ],
"env": {
"MAIN_ACCOUNT_ADDRESS": "your_main_account_address",
"API_ACCOUNT_PRIVATE_KEY": "your_api_account_private_key",
"NETWORK": "testnet" /* testnet | main */
}
}
}
}Replace /path/to/alpha-arena-mcp with your actual installation path, and update your_main_account_address and your_ai_account_private_key with your own account details.
Set Up Analysis (via Prompt):
Use nof1_system_prompt() to load the expert trader persona.
Generate Recommendation (via Prompt + Data):
Use nof1_user_prompt("BTC/USDC:USDC") → Injects market/account data into the user prompt for LLM analysis.
Execute Trade (via Tool):
place_order(symbol="BTC/USDC:USDC", side="buy", size=0.01, leverage=10) → Places order with auto-TP/SL.
Manage Position:
close_position("BTC/USDC:USDC") → Closes all positions.
cancel_open_orders("BTC/USDC:USDC") → Cancels pending orders.
Places a limit/market order with optional TP/SL. Auto-calculates TP/SL if not provided based on leverage (2:1 reward:risk).
Parameters:
symbol (str): Trading pair, e.g., "BTC/USDC:USDC".
side (str: buy/sell): Order direction.
size (float): Order size (quantity).
price (float, optional): Limit price (defaults to current market price).
leverage (float=10): Leverage multiplier.
tp_price/sl_price (float, optional): Take-profit/stop-loss prices.
Returns: Dict: Order IDs or error.
Prompt:
Buy 0.01 BTC with 10x leverage on Hyperliquid, using market price.
Response:
{
"status": "success",
"result": {
"main_order_id": "abc123",
"tp_order_id": "def456",
"sl_order_id": "ghi789",
"status": "success"
}
}Closes all positions for a symbol using reduce-only market orders.
Parameters:
symbol (str): Trading pair, e.g., "BTC/USDC:USDC".
Returns: Dict: Close orders or no-action message.
Prompt:
Close my entire BTC position now.
Response:
{
"close_orders": [
{
"order_id": "jkl012",
"side": "sell",
"size": 0.01,
"status": "closed"
}
],
"status": "success"
}Cancels all open orders for a symbol.
Parameters:
symbol (str): Trading pair, e.g., "ETH/USDC:USDC".
Returns: Dict: Canceled orders or no-action message.
Prompt:
Cancel all my pending orders for ETH.
Response:
{
"canceled_orders": [
{
"id": "mno345",
"status": "canceled"
},
{
"id": "pqr678",
"status": "canceled"
}
],
"status": "success"
}Fetches and formats account balance, positions, and performance summary.
Parameters: None.
Returns: str: Formatted account summary.
Prompt:
What's my current account status?
Response:
Current Total Return (percent): 2.5%
Available Cash: 1500.0
Current Account Value: 1525.0
Positions: {"symbol": "BTC/USDC:USDC", "quantity": 0.01, "unrealized_pnl": 25.0, ...}Fetches and formats market data, including technical indicators, volume, open interest, and funding rate.
Parameters:
symbol (str): Trading pair, e.g., "SOL/USDC:USDC".
Returns: str: Formatted market state.
Prompt:
Give me the latest market data for SOL.
Response:
Current Market State:
current_price = 150.25, current_ema20 = 148.50, current_macd = 1.20, current_rsi (7 period) = 65.3
Open Interest: Latest: 100000.0 Average: 100000.0
Funding Rate: 0.0001
Intraday series (by minute, oldest → latest):
Mid prices: [145.0, 146.2, ...]
...Expert crypto analyst system prompt.
Parameters: None
Returns: str: System message.
Example:
You are an expert cryptocurrency analyst and trader with deep knowledge of blockchain technology, market dynamics, and technical analysis.
Your role is to:
- Analyze cryptocurrency market data, including price movements, trading volumes, and market sentiment
- Evaluate technical indicators such as RSI, MACD, moving averages, and support/resistance levels
- Consider fundamental factors like project developments, adoption rates, regulatory news, and market trends
- Assess risk factors and market volatility specific to cryptocurrency markets
- Provide clear trading recommendations (BUY, SELL, or HOLD) with detailed reasoning
- Suggest entry and exit points, stop-loss levels, and position sizing when appropriate
- Stay objective and data-driven in your analysis
[... full prompt continues ...]
Today is November 01, 2025.Data-enriched user prompt for analysis.
Parameters: symbol (str)
Returns: str: Prompt with market/account data.
It has been 45 minutes since you started trading. The current time is 2025-11-01T10:30:00 and you've been invoked 3 times. Below, we are providing you with a variety of state data, price data, and predictive signals so you can discover alpha. Below that is your current account information, value, performance, positions, etc.
ALL OF THE PRICE OR SIGNAL DATA BELOW IS ORDERED: OLDEST → NEWEST
Timeframes note: Unless stated otherwise in a section title, intraday series are provided at 3-minute intervals. If a coin uses a different interval, it is explicitly stated in that coin's section.
# HERE IS THE CURRENT MARKET STATE
## ALL SOL DATA FOR YOU TO ANALYZE
Current Market State:
current_price = 150.25, current_ema20 = 148.50, current_macd = 1.20, current_rsi (7 period) = 65.3
[... full formatted market data ...]
----------------------------------------------------------
## HERE IS YOUR ACCOUNT INFORMATION & PERFORMANCE
Current Total Return (percent): 2.5%
Available Cash: 1500.0
Current Account Value: 1525.0
Positions: {"symbol": "BTC/USDC:USDC", "quantity": 0.01, ...}MIT License. See LICENSE for details.
Get and format the current account information.
Returns: Formatted string with account details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the return value is a formatted string with account details, which is useful. However, with no annotations provided, the description carries the full burden and does not mention authentication requirements, data scope, or the absence of side effects. It provides minimal behavioral context beyond the return format.
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 extremely concise, consisting of two sentences. The first sentence front-loads the verb and resource, and the second specifies the return format. Every word earns its place without unnecessary detail.
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 zero-parameter getter with an output schema present, the description is adequate: it identifies the resource and the return format. It could add more context about when to use this tool (e.g., for displaying account status to the user), but it is complete enough for a simple informational tool.
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?
The tool has zero parameters, so the description is not required to explain parameter semantics. The schema coverage is trivially 100% with an empty object, and the description adds no param info, which is acceptable. Baseline for zero parameters is 4.
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 'Get and format the current account information', identifying the action (get/format) and resource (account information). It is distinct from siblings such as place_order and close_position, which are trading operations, making the tool's purpose unambiguous.
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 retrieving account details, and the sibling tools are all trading actions, so there is no overlap. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel all open orders for the specified trading pair on Hyperliquid.
Args: symbol: Trading pair, e.g., "BTC/USDC:USDC"
Returns: Dict with canceled orders details or error
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It states that the tool cancels (a clear mutation) and returns 'Dict with canceled orders details or error', which is useful. However, it does not mention side effects, permissions, or edge cases like no open orders.
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, with a clear and front-loaded main sentence followed by a simple Args/Returns block. Every sentence adds necessary information, with no redundancy or fluff.
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 the tool's simplicity (one parameter, no annotations, but an output schema), the description covers the essential context: purpose, input format, and return type. It lacks deeper edge-case behavior, but for a straightforward cancel operation, it is sufficiently complete.
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?
The input schema only defines 'symbol' as a string with no description. The description compensates by providing the format ('Trading pair') and a concrete example ('BTC/USDC:USDC'), giving the agent enough information to construct a valid parameter 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 clearly states the action ('Cancel'), the resource ('all open orders'), and the scope ('for the specified trading pair on Hyperliquid'). It distinguishes this tool from siblings like place_order, close_position, and account_info by targeting a specific trading operation.
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 its usage by stating exactly what it does ('Cancel all open orders'), but it does not provide explicit when-to-use guidance, exclusions, or alternatives. The use case is clear but left to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close all positions for the specified trading pair on Hyperliquid.
Args: symbol: Trading pair, e.g., "BTC/USDC:USDC"
Returns: Dict with close order details or error
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'close all positions' which is a key destructive trait, and it shows the return type as 'Dict with close order details or error.' However, it lacks additional context such as whether the close is executed at market price, whether it requires an existing position, or any side effects like fees or slippage. This is basic but not rich.
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 extremely concise and well-structured. It opens with a one-sentence purpose, then clearly separates Args and Returns. Every word earns its place, with no redundancy or filler. The inclusion of a concrete parameter example is valuable without bloating the text.
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 single-parameter tool, the description is fairly complete. It covers the purpose, parameter semantics, and return type. The existence of an output schema means the return format details need not be explained. The main omission is prerequisites or side effects, but given the tool's simplicity and the presence of an output schema, this does not significantly detract from completeness.
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?
The input schema only lists 'symbol' with no description, so the description adds essential meaning by providing a format example: 'e.g., "BTC/USDC:USDC"'. This clarifies the expected structure (base/quote with separator) and gives a concrete example, fully compensating for the schema's 0% coverage.
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 what the tool does: 'Close all positions for the specified trading pair on Hyperliquid.' It uses a specific verb (close) and resource (positions for a trading pair), and it distinguishes itself from sibling tools like place_order and cancel_open_orders by focusing on closing positions entirely.
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 no guidance on when to use this tool versus alternatives such as place_order or cancel_open_orders. It simply states the function without any context about scenarios (e.g., 'use this to exit a position entirely' or 'not for partial closures'). There is no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get and format the current market state for a given symbol.
Args: symbol: Trading pair, e.g., "BTC/USDC:USDC"
Returns: Formatted string with market state details.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get and format' implies a read-only operation with no side effects, and it discloses that the return is a formatted string. However, it does not elaborate on rate limits, error handling, or what 'market state' encompasses, which would enhance transparency.
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 compact and front-loaded, with a one-line purpose followed by Args and Returns sections. Every sentence contributes value, and there is no redundancy or fluff.
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 an output schema, the description covers the essential information: purpose, symbol format, and return type. It could be more complete by mentioning potential errors or symbol variations, but given the tool's simplicity, it is adequately complete.
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?
The schema only specifies the symbol as a string, but the description adds a concrete example ('BTC/USDC:USDC') and clarifies it is a trading pair. This provides meaningful semantics beyond the schema, helping the agent understand the required format despite 0% schema coverage.
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's purpose with a specific verb ('Get and format') and resource ('current market state'), making it obvious what the tool does. It distinguishes itself from sibling trading tools (place_order, close_position, cancel_open_orders, account_info) by focusing on market data retrieval.
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 checking market conditions but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool mentions are provided, leaving the agent to infer applicability from the tool's name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order on Hyperliquid with optional market price, and auto-calculate TP/SL if not provided.
Args: symbol: Trading pair, e.g., "BTC/USDC:USDC" side: 'buy' or 'sell' size: Order size (quantity) price: Limit price for main order (default: None, uses current market price) leverage: Leverage to set (default: 10) tp_price: Take profit price (default: None, auto-calculated) sl_price: Stop loss price (default: None, auto-calculated)
Returns: Dict with order details or error
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| size | Yes | ||
| price | No | ||
| symbol | Yes | ||
| leverage | No | ||
| sl_price | No | ||
| tp_price | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a good job: it discloses that TP/SL are auto-calculated if not provided, that price defaults to current market price, and that a dict with details/error is returned. It does not mention risk or how auto-calc is derived, but the core state-changing behavior is 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 purpose-led, then uses a clean Args block with one line per parameter and a Returns line. It is appropriately sized for a 7-parameter tool with no wasted sentences or redundant information.
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 the output schema exists and all parameters are semantically covered, the description is complete for both selection and invocation. It covers purpose, behavior, parameter meaning, defaults, and return type without needing extra external context.
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 0%, so the description fully compensates by explaining all seven parameters with examples, defaults, and meaning (e.g., symbol format, side values, price as limit price or market, leverage default, TP/SL auto-calc). This exceeds baseline and makes the schema usable.
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 opens with a specific verb-resource pair: 'Place an order on Hyperliquid.' It further distinguishes the tool by mentioning optional market pricing and auto-calculated TP/SL, which separates it from sibling tools like close_position and cancel_open_orders.
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 context clearly implies the tool is for opening orders, and param details clarify when defaults apply (e.g., market price when price is None). However, it does not explicitly state when not to use it or name alternatives, so it stops short of a 5.
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.1.0account_infocancel_open_ordersclose_positionmarket_stateplace_orderScored across 5 tools
Each tool targets a distinct action or resource: placing orders, closing positions, canceling orders, viewing account info, and viewing market state. No overlap or ambiguity between them.
All tool names use snake_case and follow a clear pattern. Action-oriented tools use verb_noun (place_order, close_position, cancel_open_orders), while informational tools use resource_state (account_info, market_state). The naming is consistent and predictable.
Five tools is well-scoped for a trading-focused server. Each tool serves a distinct purpose and covers the core trading workflow without redundancy or bloat.
The tool set covers the essential lifecycle: placing orders, closing positions, canceling orders, and retrieving account/market information. Minor gaps exist such as no explicit get_positions or get_open_orders tools, but account_info likely covers position details and the workflow is functional.
Non-custodial Hyperliquid perp trading: live markets, account state, user-armed order execution
Live Hyperliquid perps analytics for agents: funding, OI, whale prints, leaderboard, wallet risk.
Polymarket + Hyperliquid + macro for AI agents. 38 tools, signal backtest, SSE streaming. Free tier.
Crypto perps data for AI agents: funding rates, open interest, liquidations, order book, CVD.
