Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

US spot Bitcoin, Ethereum, Solana and XRP ETF daily flows

get_etf_flows
Read-only

Retrieve daily US spot ETF flows for BTC, ETH, SOL and XRP: net inflows or outflows, cumulative flow since launch, total net assets and value traded per trading day.

Instructions

Call this when the user asks about Bitcoin, Ethereum, Solana or XRP spot ETF flows: daily net inflows or outflows, cumulative flow since launch, or total net assets of the US spot ETFs (IBIT, FBTC, ETHA, XRPC and the rest). Returns one row per finalized US trading day and asset with net inflow, total net assets, cumulative inflow since launch and value traded, all in USD. History by asset: BTC and ETH since 2025-05-20, SOL since 2025-10-28, XRP since 2026-09-08.

Input Schema

NameRequiredDescriptionDefault
daysNoHow many most recent trading days to return (default 10).
assetNoFilter to one asset (BTC, ETH, SOL or XRP). Omit for all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changedv0.36.0
    • changedInput schema / properties / asset / description
      Previous value: -"Filter to one asset (BTC, ETH or SOL, SOL since 2026-09-02). Omit for all."New value: +"Filter to one asset (BTC, ETH, SOL or XRP). Omit for all."
    • changedInput schema / properties / asset / enum
      Previous value: -[
-  "BTC",
-  "ETH",
-  "SOL"
-]New value: +[
+  "BTC",
+  "ETH",
+  "SOL",
+  "XRP"
+]
  3. Changed2 schema fields changedv0.27.2
    • changedInput schema / properties / asset / description
      Previous value: -"Filter to one asset. Omit for both."New value: +"Filter to one asset (BTC, ETH or SOL, SOL since 2026-09-02). Omit for all."
    • changedInput schema / properties / asset / enum
      Previous value: -[
-  "BTC",
-  "ETH"
-]New value: +[
+  "BTC",
+  "ETH",
+  "SOL"
+]
  4. First observedv0.5.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real value beyond that by disclosing the return grain ('one row per finalized US trading day and asset'), the units (USD), the four returned fields, and per-asset history start dates. It omits anything about caching, rate limits, or what happens when days exceeds available history, which keeps it short of a 5.

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

Conciseness5/5

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

Three sentences: trigger first, return shape second, data-coverage caveat last. Every sentence carries distinct information an agent needs before calling, and nothing is repeated from the schema or annotations.

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?

With no output schema, the description compensates by listing the returned fields and row grain, and the per-asset history windows preempt the most likely failure mode (requesting days beyond available data). For a two-parameter read-only tool this is complete.

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%, so baseline is 3, but the description earns above that by clarifying that 'days' counts US trading days and by giving per-asset start dates — which tells the agent that a large 'days' value returns fewer rows for SOL/XRP than for BTC/ETH. The asset enum is left entirely to the schema, which is fine.

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 trigger condition plus resource: 'when the user asks about Bitcoin, Ethereum, Solana or XRP spot ETF flows' and enumerates the exact metrics (net inflows/outflows, cumulative flow, total net assets). Names concrete tickers (IBIT, FBTC, ETHA, XRPC) so an agent can map a user question to this tool without opening the schema, and no sibling tool covers ETF flows.

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 'call this when' clause gives a clear positive trigger and enumerates three distinct user intents (daily net flow, cumulative since launch, total net assets). It does not name an exclusion or a competing tool (e.g. get_series or get_market_indices), but with no close sibling in the list the risk of mis-selection is low.

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

Deploy Server

Other Tools