whale-insights

narrative_history

Read-onlyIdempotent

Get daily narrative/sector history — top crypto market sectors ranked by market cap change %, strength, and token count over up to 90 days — Daily historical narrative strength per market sector (e.g. DeFi, Layer 2, AI, Meme Coins) from CoinGecko Categories. One row per day per sector: market cap change %, strength score (0-100), token count in sector, daily rank, and top tokens. Filter by ?sector= for a single sector trend. Useful for identifying which narratives are accelerating or fading. DB-backed, 5-min cache. Powered by narrative_daily table (365d retention, permanent monthly archive). — Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`days`	No	Number of days of history to return (1–90, default 30).
`sector`	No	Optional sector name filter (e.g. 'Artificial Intelligence'). Returns all sectors when omitted.

Output Schema

TableJSON Schema

Name	Required	Description
`days`	No
`total`	No
`sector`	No	Sector filter applied (null = all sectors).
`history`	No
`updatedAt`	No
`attribution`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "attribution": {
+      "$ref": "#/components/schemas/Attribution"
+    },
+    "days": {
+      "type": "number"
+    },
+    "history": {
+      "items": {
+        "properties": {
+          "date": {
+            "description": "YYYY-MM-DD snapshot date.",
+            "format": "date",
+            "type": "string"
+          },
+          "marketCapChangePct": {
+            "description": "24h market cap change % for the sector.",
+            "nullable": true,
+            "type": "number"
+          },
+          "rank": {
+            "description": "Sector rank for the day (1 = strongest).",
+            "type": "integer"
+          },
+          "sector": {
+            "description": "Market sector / narrative name (e.g. 'Artificial Intelligence', 'Layer 2', 'DeFi').",
+            "type": "string"
+          },
+          "strength": {
+            "description": "Composite narrative strength score (0-100).",
+            "maximum": 100,
+            "minimum": 0,
+            "nullable": true,
+            "type": "number"
+          },
+          "tokenCount": {
+            "description": "Number of tokens in this sector.",
+            "type": "integer"
+          },
+          "topTokens": {
+            "description": "Top token symbols in this sector.",
+            "items": {
+              "type": "string"
+            },
+            "nullable": true,
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sector": {
+      "description": "Sector filter applied (null = all sectors).",
+      "nullable": true,
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    },
+    "updatedAt": {
+      "format": "date-time",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedJul 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and open-world, and the description adds meaningful operational context beyond those hints: DB-backed storage, 5-minute cache, 365-day retention, permanent monthly archive, and row-level output structure. Nothing in the description contradicts the annotations, and the data freshness/retention details help agents reason about temporal coverage.

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 front-loaded with the core purpose and ends with clear alternative routing. It is slightly repetitive ('daily narrative/sector history' and 'Daily historical narrative strength') and uses several em-dashed asides, but every sentence contributes useful information such as cache behavior, retention, and output shape.

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?

Given the tool has an output schema, no required parameters, and strong annotations, the description covers everything an agent needs to invoke it correctly: time range, row semantics, sector filtering, data source, cache freshness, retention, and which sibling tool to use for other time horizons. There are no significant contextual gaps.

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?

The schema already documents both parameters with descriptions: `days` (1–90, default 30) and `sector` (optional filter, returns all sectors when omitted). The description mostly repeats these ideas, adding only a usage nuance ('single sector trend') and an example. With 100% schema coverage, the baseline of 3 applies because the description does not substantially expand parameter meaning beyond the schema.

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?

The description opens with a specific verb-resource pairing ('Get daily narrative/sector history') and then enumerates the exact output dimensions: market cap change %, strength score, token count, daily rank, and top tokens. It also explicitly contrasts itself with live snapshot and monthly trend tools, so an agent can distinguish it from sibling tools like 'narratives' without inspecting schemas.

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

Usage Guidelines5/5

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

The description gives a direct usage directive: 'Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' It also explains that filtering by sector produces a single-sector trend, which gives the agent actionable context for when to include or omit the sector parameter.

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

All whale-insights tools Inspect

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

Need Help?