Skip to main content
Glama

Vectorial Data Terminal: Hyperliquid, Polymarket & yield for AI agents

buy_hype

Buy HYPE with USDC in your trading wallet (spot, immediate-or-cancel at up to +1% from mid; fee 0.25% in USDC; Hyperliquid's minimum order is $10). The outcome says how much HYPE arrived — stake it with stake_hype. Returns operation_id + signatures_needed[]: sign EACH step with the signer it names — 'owner' = your OWNER P-256 key over payload_b64 (decode it and check every verify line against YOUR records first), 'trading_key' = your trading key over typed_data (EIP-712) — then submit_operation within 5 minutes.

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": {
      "amount_usd": "<amount_usd>"
    },
    "name": "buy_hype"
  }
}

Input Schema

NameRequiredDescriptionDefault
amount_usdYesUSDC to spend on HYPE (Hyperliquid's minimum spot order is $10)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations: discloses execution style and slippage bound, fee currency, exchange minimum, and the full two-step signing workflow with which key signs which payload, a verification step against the caller's own records, and a 5-minute submission deadline. It even notes what the outcome reports (HYPE received) despite there being no output schema.

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?

Front-loaded with what is bought and how, then the signing protocol, so critical information appears early. It is dense with parentheticals and em-dash clauses, and the signing paragraph is heavy, but nearly every clause carries operational substance.

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

Completeness5/5

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

This is a non-idempotent, open-world value-moving operation with no output schema, and the description still covers execution semantics, cost, minimums, the asynchronous sign-and-submit protocol, and the expiry window. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is fully documented there, so the baseline is 3. The description adds the funding-source detail (USDC debited from your trading wallet) and restates the minimum in context, which is meaningful but modest additional meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (buy HYPE with USDC) plus the venue context (trading wallet, spot). It is unmistakable against siblings like place_order, sell_hype, and stake_hype, and it even routes the follow-up action explicitly.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete execution parameters (IOC, up to +1% from mid, 0.25% fee in USDC, $10 minimum) and says to stake the proceeds with stake_hype. It does not explicitly say when to prefer this over place_order or submit_order for a limit order, so a small inference gap remains.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.