Skip to main content
Glama
t3rmed

Hyperliquid MCP Server

by t3rmed

get_portfolio

Retrieve portfolio details including positions, profit/loss, and margin usage for Hyperliquid DEX trading accounts.

Instructions

Get portfolio information including positions, PnL, and margin usage

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNoUser wallet address (optional, defaults to configured wallet)

Implementation Reference

  • The main handler function for the 'get_portfolio' tool. Fetches portfolio data from HyperliquidClient, handles errors, formats summary including total notional position, unrealized PnL, margin used, and last updated time as structured text content.
    async def handle_get_portfolio(client: HyperliquidClient, args: Dict[str, Any]) -> Dict[str, Any]:
        """Handle get portfolio request."""
        user = args.get("user")
        result = await client.get_portfolio(user)
    
        if not result.success:
            raise ValueError(f"Failed to get portfolio: {result.error}")
    
        portfolio = result.data
    
        if not portfolio:
            return {
                "content": [
                    TextContent(
                        type="text",
                        text="No portfolio data found.",
                    )
                ]
            }
    
        last_updated = (
            datetime.fromtimestamp(portfolio["time"] / 1000).isoformat()
            if portfolio.get("time")
            else "N/A"
        )
    
        return {
            "content": [
                TextContent(
                    type="text",
                    text=f"Portfolio Summary:\n\nTotal Notional Position: ${portfolio.get('totalNtlPos', '0')}\nTotal Unrealized PnL: ${portfolio.get('totalUnrealizedPnl', '0')}\nTotal Margin Used: ${portfolio.get('totalMarginUsed', '0')}\nLast Updated: {last_updated}",
                )
            ]
        }
  • The schema definition for the 'get_portfolio' tool, specifying input schema with optional 'user' wallet address.
    get_portfolio_tool = Tool(
        name="get_portfolio",
        description="Get portfolio information including positions, PnL, and margin usage",
        inputSchema={
            "type": "object",
            "properties": {
                "user": {
                    "type": "string",
                    "description": "User wallet address (optional, defaults to configured wallet)",
                }
            },
            "required": [],
        },
    )
  • Registration of the 'get_portfolio' handler in the main MCP server's call_tool dispatcher.
    elif name == "get_portfolio":
        result = await handle_get_portfolio(client, args)
  • Maps 'get_portfolio' tool name to its handler in the HTTP server's TOOL_HANDLERS dictionary.
    "get_portfolio": handle_get_portfolio,
  • TypeScript equivalent handler for 'get_portfolio' tool in the Node.js MCP server implementation.
    export async function handleGetPortfolio(client: HyperliquidClient, args: any) {
      const { user } = args;
      const result = await client.getPortfolio(user);
    
      if (!result.success) {
        throw new Error(`Failed to get portfolio: ${result.error}`);
      }
    
      const portfolio = result.data;
    
      return {
        content: [
          {
            type: 'text',
            text: `Portfolio Summary:\n\nTotal Notional Position: $${portfolio?.totalNtlPos || '0'}\nTotal Unrealized PnL: $${portfolio?.totalUnrealizedPnl || '0'}\nTotal Margin Used: $${portfolio?.totalMarginUsed || '0'}\nLast Updated: ${portfolio?.time ? new Date(portfolio.time).toISOString() : 'N/A'}`
          }
        ]
      };
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what data is returned but doesn't describe important behaviors: whether this requires authentication, rate limits, real-time vs. cached data, error conditions, or response format. For a financial data tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. It wastes no words on unnecessary details. However, it could be slightly more structured by separating the core function from the data components for even better readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (portfolio data retrieval), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It tells what data is returned but lacks crucial context about authentication, data freshness, error handling, and response structure. For a financial tool with no output schema, more completeness would be expected.

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 fully documents the single optional parameter. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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?

The description clearly states the verb 'Get' and resource 'portfolio information', specifying the included data fields (positions, PnL, margin usage). It distinguishes from siblings like get_open_orders or get_user_fills by focusing on portfolio rather than orders or fills. However, it doesn't explicitly contrast with all siblings, preventing a perfect score.

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

Usage Guidelines2/5

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. It doesn't mention when to prefer get_portfolio over other data retrieval tools like get_user_fills or get_open_orders, nor does it specify any prerequisites or constraints for usage. The only implied context is portfolio-related queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/t3rmed/hyperliquid-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server