Skip to main content
Glama

whale-insights

by com.cryptowhaleinsights

analyst_archive

Analyst signal archive — paginated 1-year history (public, MCP-compatible) — Returns a paginated archive of signals attributed to a single analyst, covering up to 1 year (365 days). This is the MCP-tool-compatible variant of the analyst archive — it uses query params instead of path params so AI agents can call it directly without resolving a URL template. Analyst IDs: chain_hawk (ChainHawk, BTC & macro on-chain), whale_watch (WhaleWatch, multi-chain whale moves), alpha_scout (AlphaScout, emerging tokens), defi_pulse (DeFiPulse, DeFi/stables/bridges), quant_edge (QuantEdge, signal risk/convergence), rate_hawk (RateHawk, funding rates & derivatives), flow_tracer (FlowTracer, stablecoin & capital flows), unlock_guard (UnlockGuard, token unlock risk), sentiment_edge (SentimentEdge, social sentiment extremes), narrative_pulse (NarrativePulse, sector rotation & narratives). Filters: period (7d | 30d | 90d | 365d, default 90d), outcome (all | win | loss | neutral | pending, default all), page (1-indexed, default 1)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed, default 1).
limitNoResults per page (10–100, default 100).
periodNoTime window: 7d | 30d | 90d | 365d (default 90d). Use 365d to access up to 1 year of history.90d
outcomeNoFilter by outcome: all | win | loss | neutral | pending (default all).all
analystIdYesAnalyst slug. Valid values: chain_hawk, whale_watch, alpha_scout, defi_pulse, quant_edge, rate_hawk, flow_tracer, unlock_guard, sentiment_edge, narrative_pulse.

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses pagination, time window, query-param usage, and analyst options. Missing details on error handling, authentication, or response format, but covers the main behavior adequately.

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 fairly concise and front-loaded with purpose. Every sentence adds value, though the list of analyst IDs could be slightly more compact. Overall efficient.

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

Completeness2/5

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

No output schema is provided, yet the description does not describe the response format (returned fields, pagination metadata). Given the complexity (5 params, enums, pagination), this is a notable gap.

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 coverage is 100%, so baseline is 3. The description adds some context (list of analyst specialties, period meaning) but mostly duplicates schema info. Marginal added value.

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 clearly states the tool returns a paginated archive of signals for a single analyst, with a max 1-year window. It distinguishes itself as the MCP-compatible variant using query params, differentiating it from non-MCP counterparts.

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?

The description explains when to use this tool (for single analyst signals via query params) and provides valid analyst IDs and filters. However, it does not explicitly compare to sibling tools like analysts_signals or analysts_signals_all, nor state when not to use it.

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

All whale-insights toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have distinct purposes, but there are a few pairs with overlapping boundaries (e.g., analysts_signals vs analysts_signals_all, whale_movements vs whale_movements_summary) that could cause minor confusion.

Naming Consistency4/5

Naming is predominantly snake_case and descriptive, with minor inconsistencies in plural/singular forms (e.g., 'analysts' vs 'analyst_archive'). Overall pattern is stable.

Tool Count2/5

With 55 tools, the server is quite heavy. While the scope is broad, many tools are history/monthly variants that could be combined, making the count feel inflated beyond what is ideal for a single server.

Completeness4/5

The tool set covers a wide range of crypto analytics domains (analysts, arbitrage, funding, whales, sentiment, etc.). Minor gaps exist (e.g., no direct token price endpoint), but overall it's a comprehensive surface.

Resources