Skip to main content
Glama

Nansen

by io.github.nansen-ai
OverviewDiscussionsAdmin

Analyzing token quant scores

token_quant_scores
Read-only

Get Nansen Score Indicators for a token - quantitative risk and reward signals.

Use this tool when assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data to make trading decisions.

Returns: Token risk/reward indicators as markdown with interpretation guidance.

Token info:
- **Market Cap**: Current market cap in USD
- **Market Cap Group**: largecap (>$1B), midcap ($100M-$1B), or lowcap (<$100M)
- **Is Stablecoin**: Whether token is a stablecoin (some indicators don't apply to stablecoins)

Fields returned per indicator:
- **Score**: Signal classification (bullish/neutral/bearish for reward; low/medium/high for risk)
- **Signal**: Raw numeric value of the indicator
- **Percentile**: Rank vs same market cap group (0-100%)
- **Last Trigger**: Date when signal was last calculated

Indicator types:
- **Reward Indicators**: price-momentum, funding-rate, chain-fees, chain-tvl, protocol-fees, trading-range
- **Risk Indicators**: btc-reflexivity, liquidity-risk, token-supply-inflation, concentration-risk, cex-flows

Notes: - Not all indicators available for every token/chain combination - Percentile compares against same market cap group (largecap >$1B, midcap $100M-$1B, lowcap <$100M)

Input Schema

NameRequiredDescriptionDefault
requestYesRequest model for Nansen Score Indicators endpoint (flattened).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / request / additionalProperties
      Added value: +false
    • removedInput schema / properties / request / anyOf
      Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "description": "Request model for Nansen Score Indicators endpoint (flattened).",
-    "properties": {
-      "chain": {
-        "default": "ethereum",
-        "description": "Blockchain chain (ethereum, solana, base, bnb, polygon, arbitrum, etc.). On-chain tokens only — Hyperliquid perps NOT supported.",
-        "type": "string"
-      },
-      "tokenAddress": {
-        "description": "Token contract address",
-        "type": "string"
-      }
-    },
-    "required": [
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-]
    • addedInput schema / properties / request / description
      Added value: +"Request model for Nansen Score Indicators endpoint (flattened)."
    • addedInput schema / properties / request / properties
      Added value: +{
+  "chain": {
+    "default": "ethereum",
+    "description": "Blockchain chain (ethereum, solana, base, bnb, polygon, arbitrum, etc.). On-chain tokens only — Hyperliquid perps NOT supported.",
+    "type": "string"
+  },
+  "tokenAddress": {
+    "description": "Token contract address",
+    "type": "string"
+  }
+}
    • addedInput schema / properties / request / required
      Added value: +[
+  "tokenAddress"
+]
    • addedInput schema / properties / request / type
      Added value: +"object"
  2. Changed3 schema fields changed
    • removedInput schema / $defs
      Removed value: -{
-  "TokenQuantScoresRequest": {
-    "description": "Request model for Nansen Score Indicators endpoint (flattened).",
-    "properties": {
-      "chain": {
-        "default": "ethereum",
-        "description": "Blockchain chain (ethereum, solana, base, bnb, polygon, arbitrum, etc.). On-chain tokens only — Hyperliquid perps NOT supported.",
-        "type": "string"
-      },
-      "tokenAddress": {
-        "description": "Token contract address",
-        "type": "string"
-      }
-    },
-    "required": [
-      "tokenAddress"
-    ],
-    "type": "object"
-  }
-}
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / request / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "$ref": "#/$defs/TokenQuantScoresRequest"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "description": "Request model for Nansen Score Indicators endpoint (flattened).",
+    "properties": {
+      "chain": {
+        "default": "ethereum",
+        "description": "Blockchain chain (ethereum, solana, base, bnb, polygon, arbitrum, etc.). On-chain tokens only — Hyperliquid perps NOT supported.",
+        "type": "string"
+      },
+      "tokenAddress": {
+        "description": "Token contract address",
+        "type": "string"
+      }
+    },
+    "required": [
+      "tokenAddress"
+    ],
+    "type": "object"
+  }
+]
  3. Changed1 schema field changed
    • changedInput schema / $defs / TokenQuantScoresRequest / properties / chain / description
      Previous value: -"Blockchain chain (ethereum, solana, base, bnb, polygon, arbitrum, etc.)"New value: +"Blockchain chain (ethereum, solana, base, bnb, polygon, arbitrum, etc.). On-chain tokens only — Hyperliquid perps NOT supported."
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds real behavioral context beyond them: per-indicator field semantics, the reward vs risk indicator taxonomy, and the important caveat that not all indicators are available for every token/chain pair. It omits any note on latency, coverage limits, or error behavior for unsupported tokens.

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

Conciseness3/5

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

Purpose is front-loaded and the header-based structure aids scanning, but the long 'Returns' block partially duplicates the existing output schema, and the market cap group definition is repeated verbatim twice. Several lines could be collapsed without losing information.

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?

Given a single nested parameter object, full schema coverage, and an output schema, the description is complete enough to invoke correctly — it covers scope, expected signals, and availability caveats. The duplicated return-format detail is surplus rather than missing, so the only gap is the absence of alternative-tool routing.

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% and both the chain and tokenAddress fields are already documented, including the Hyperliquid exclusion, so the schema carries the load. The description contributes adjacent meaning (market cap group thresholds, stablecoin applicability) but adds nothing about parameter usage itself, making baseline 3 correct.

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?

Names a specific verb+resource (get Nansen Score Indicators for a token) and states the domain (quantitative risk and reward signals). It is clearly distinguishable from list-oriented siblings such as nansen_score_top_tokens, though it never names a sibling explicitly to sharpen the boundary against token_technical_indicators.

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?

Explicitly says when to use it: assessing risk/reward, evaluating buy/sell decisions, or needing quantitative data for trading decisions. There is no when-not guidance and no pointer to an alternative tool for overlapping signals (e.g., token_technical_indicators), so it stops short of full routing guidance.

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

All Nansen toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources