Skip to main content
Glama

AlphaYou: Smart Money Intel

Inspect trader positioning

get_hyperliquid_positioning
Read-only

Use for long/short notionals and counts in the qualified cohort for an exact case-sensitive asset, such as BTC or xyz:NVDA. Newest row update is not whole-cohort freshness. Not total exchange positioning or a price prediction.

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": {
      "coin": "<coin>"
    },
    "name": "get_hyperliquid_positioning"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesExact market symbol, like BTC or xyz:NVDA

Output Schema

NameRequiredDescriptionDefault
coinYes
kindYes
statusYes
retrieved_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "coin": {
      +      "type": "string"
      +    },
      +    "kind": {
      +      "const": "positioning",
      +      "type": "string"
      +    },
      +    "retrieved_at": {
      +      "type": "string"
      +    },
      +    "status": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "kind",
      +    "coin",
      +    "status"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / coin / description
      Added value: +"Exact market symbol, like BTC or xyz:NVDA"
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavioral context beyond that: results are scoped to a 'qualified cohort' rather than all traders, and 'newest row update is not whole-cohort freshness' warns that recency of one row does not imply cohort-wide currency.

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?

Three short, front-loaded sentences with the primary use case first, then a data-freshness caveat, then exclusions; nothing is padded. The only cost is terseness: 'qualified cohort' is unexplained jargon the reader must infer.

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

Completeness4/5

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

An output schema exists, so return-shape explanation is unnecessary, and annotations cover the safety profile. The description supplies scope, exactness and a freshness caveat for a single-parameter read tool, leaving only the definition of 'qualified cohort' and any result-size limits unaddressed.

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 parameter description already gives examples, so the baseline is 3. The description adds a meaningful nuance the opaque regex pattern does not make obvious: matching is exact and case-sensitive. 'Qualified cohort' remains undefined but that is a scope concept, not a parameter-syntax detail.

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 states a specific verb-and-resource pairing: long/short notionals and counts for one exact case-sensitive asset, with a concrete example (BTC, xyz:NVDA). It further narrows scope by disclaiming 'total exchange positioning' and 'price prediction', which separates it from market-wide or forecast tools. It does not name a sibling tool directly, which keeps it just short of a 5.

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?

'Use for long/short notionals and counts in the qualified cohort' gives an explicit positive condition, and 'Not total exchange positioning or a price prediction' gives explicit exclusions. What is missing is routing to a concrete alternative (e.g. wallet-level or market-state siblings) when the caller actually wants exchange-wide or per-wallet data.

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.

Resources