Provides read-only access to Binance spot and USDⓈ-M futures market data, including spot prices, 24h price change/range/volume, perpetual funding rates (and annualized), basis, open interest, and open interest-to-volume ratios. It also compares Binance prices with Bybit and handles unavailable or unknown symbols.
Read-only crypto market data for AI assistants, over the Model Context Protocol. Ask Claude (or any MCP client) about prices, funding, open interest, DeFi TVL and stablecoin flows and get structured answers from public APIs. No API keys. No trading. No account access.
Tool | What it answers |
| Spot price, 24h change/range/volume on Bybit and Binance, and the gap between the two |
| Perpetual funding rate (also annualised), basis, open interest and its ratio to volume |
| Top coins by market cap or volume, 24h change, distance from ATH, market breadth (CoinGecko) |
| Top chains by TVL, one chain with its top protocols (e.g. Solana, Stellar), or one protocol (DefiLlama) |
| Largest USD stablecoins, supply share and 1d/7d/30d supply change, a rough proxy for money entering or leaving crypto |
Example prompts once it is connected:
"Is SOL trading at a premium on Bybit compared with Binance right now?"
"What is BTC funding doing? Are longs crowded?"
"How big is Stellar DeFi, and which protocols lead it?"
"Is stablecoin supply growing or shrinking this week?"
Asked in Claude Code with the server connected (snapshot, 22 Oct 2026):
Is SOL at a premium on Bybit vs Binance? What is BTC funding doing? How big is Stellar DeFi?
SOL (get_price): no premium. $103.82 on Bybit, $103.83 on Binance, about 0.01% apart.
BTC funding (get_derivatives): slightly negative, -0.0041% per 8h on Bybit (about -4.5% a year), so shorts are paying longs. Longs do not look crowded.
Stellar DeFi (get_defi_tvl): about $241M TVL, #18 among chains. Top protocol: Blend Pools V2, about $140M.
Related MCP server: Simsar MCP
Requires Node.js 20 or newer. The quickest way is npx, no clone needed:
claude mcp add crypto-pulse -- npx -y crypto-pulse-mcpOn Windows, run it from cmd (PowerShell swallows the --) and wrap npx so Claude Code can start it:
claude mcp add crypto-pulse -- cmd /c npx -y crypto-pulse-mcpAdd -s user to make it available in every folder, not just the current project.
Published on npm and in the official MCP Registry as
io.github.markankamaransheogarat-sys/crypto-pulse-mcp.
To run it from source instead:
git clone https://github.com/markankamaransheogarat-sys/crypto-pulse-mcp.git
cd crypto-pulse-mcp
npm install
npm run buildAdd to claude_desktop_config.json:
{
"mcpServers": {
"crypto-pulse": {
"command": "npx",
"args": ["-y", "crypto-pulse-mcp"]
}
}
}On Windows use "command": "cmd" with "args": ["/c", "npx", "-y", "crypto-pulse-mcp"].
claude mcp add crypto-pulse -- node /absolute/path/to/crypto-pulse-mcp/dist/index.jsAny other MCP client that can launch a stdio server works the same way.
Symbols. BTC, ETH/USDT, SOLUSDT and doge-usdt all work; a bare coin means a USDT pair.
One exchange down is not a failure. get_price and get_derivatives query both exchanges in parallel. If one
is unreachable (Binance is geo-blocked in some countries), you still get the other, with an errors field saying so.
An unknown symbol is reported as "not listed", not as an outage.
Caching. Responses are cached briefly (5 s for exchange tickers, 60 s for CoinGecko, 5 min for DefiLlama) to stay inside free-tier rate limits. Simultaneous identical requests share one call.
Funding sign. Positive funding means longs pay shorts. annualizedFundingPct assumes today's rate holds for a
year, which it will not; read it as a scale, not a forecast.
DefiLlama CEX entries (exchange wallet balances) are excluded from per-chain protocol rankings.
Not financial advice. These are snapshots of public data and can be seconds to minutes old.
npm run typecheck # tsc --noEmit over src and tests
npm test # vitest, all HTTP mocked
npm run build # compile to dist/
node scripts/smoke.mjs # live check: starts the built server and calls every tool against the real APIsLayout: src/sources/* talk to one API each and return normalised shapes, src/tools/* hold the logic and register one
MCP tool each, src/http.ts is the shared client (timeout, bounded retries, TTL cache), src/symbols.ts normalises
symbols.
Bybit v5 · Binance spot and USDⓈ-M futures · CoinGecko · DefiLlama. This project is not affiliated with any of them; respect their terms and rate limits.
MIT
DeFi TVL from DefiLlama. With no arguments: the largest chains and their share. With chain (e.g. Solana, Stellar): that chain's TVL, rank and its top protocols. With protocol (e.g. aave, jupiter): its TVL, category and 1h/1d/7d change.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain name, e.g. Solana, Ethereum, Stellar | |
| limit | No | How many rows to return | |
| protocol | No | Protocol name or slug, e.g. aave, uniswap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the description's job is lighter. It adds useful mode-specific output context (share, rank, top protocols, category, 1h/1d/7d change), though it omits freshness, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences, front-loaded with the tool's purpose, then the three usage modes. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must carry return-shape burden; it does so at a useful summary level for each mode. It could be more complete about response structure and the `limit` control, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so syntax is already covered, but the description adds semantic meaning by explaining what each argument causes the response to contain. It does not explain the `limit` parameter, keeping it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific metric and source ("DeFi TVL from DefiLlama") and clearly distinguishes itself from siblings like get_price and get_derivatives by focusing on protocol/chain locked value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly maps the three argument modes to outcomes: no args for top chains and share, `chain` for chain TVL/rank/protocols, `protocol` for protocol TVL/category/change. It does not name when to use a sibling instead, so it falls just short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perpetual-futures data for a coin: funding rate (and annualised), mark vs index price (basis), open interest in USD and its ratio to 24h volume on Bybit, plus Binance's mark price and latest funding rate. Useful for judging crowding and leverage.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin or pair, e.g. BTC, ETHUSDT. A bare coin means a USDT perpetual |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context by naming the data providers (Bybit and Binance) and specifying that funding is annualised and open interest is in USD and as a ratio to 24h volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence that lists the returned metrics without filler. The sentence is dense but every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only one fully documented parameter, the description sufficiently covers what data is returned and its sourcing. Minor gaps like exact response shape or pagination are not critical for this read-only metric tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter already explains that a bare coin means a USDT perpetual. The description does not add further syntax or format detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (perpetual-futures data for a coin) and enumerates the exact metrics returned: funding rate, basis, open interest, and cross-exchange prices. It is clearly distinct from sibling tools like get_price or get_market_overview, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "Useful for judging crowding and leverage" implies when the tool is relevant, but there is no explicit when-to-use guidance, no exclusions, and no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The largest coins by market cap (or 24h volume) with price, 24h change, market cap, volume, distance from the all-time high, and how many of them are rising. Data from CoinGecko.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many coins to return | |
| sort_by | No | Ranking criterion | market_cap |
| vs_currency | No | Quote currency, e.g. usd, eur, btc | usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent, non-destructive safety profile. The description adds meaningful context beyond that: the upstream source (CoinGecko) and the exact return composition (price, 24h change, market cap, volume, ATH distance, breadth count), which matters because no output schema exists. Rate limits and data freshness are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no wasted clauses; the ranking scope is front-loaded and the returned fields and source follow. It opens as a noun phrase rather than an action verb, which slightly reduces scannability but does not impede understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, fully-optional 3-parameter read tool with annotations covering safety but no output schema, the description adequately explains what comes back and where the data originates. Minor ambiguities remain, such as sort direction and whether the rising count is a separate field, but these are small gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so limit, sort_by, and vs_currency are already documented. The description only adds the '24h' qualifier on volume and confirms the ranking concept, which is marginal beyond the schema — the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource and scope — the largest coins ranked by market cap or 24h volume — and lists the metrics returned, so it is clear what the tool produces. It does not explicitly contrast itself with siblings like get_price or get_stablecoins, leaving differentiation to the reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus get_price, get_derivatives, get_defi_tvl, or get_stablecoins. The sort criterion is described, but no selection guidance or exclusions are given, so an agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current spot price, 24h change, 24h range and quote volume for a coin on Bybit and Binance, plus the price gap between the two exchanges. Accepts BTC, ETH/USDT, SOLUSDT and similar; a bare coin means a USDT pair.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Coin or pair, e.g. BTC, ETH/USDT, SOLUSDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive call. The description adds meaningful behavioral context beyond annotations: it specifies the two exchanges covered, the exact metrics returned, and the cross-exchange gap calculation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with no filler. The core output scope is front-loaded, and the input shorthand rule follows efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly lists the returned metrics and the cross-exchange comparison. It does not describe the response structure or error behavior, but for a simple one-parameter read-only tool it provides enough context to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the symbol parameter is already documented. The description adds useful semantics by explaining that a bare coin symbol is interpreted as a USDT pair, beyond the schema's examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope: current spot price, 24h change, 24h range, quote volume, and cross-exchange price gap for Bybit and Binance. It is clear what the tool does, though it does not explicitly contrast itself with sibling tools such as get_market_overview or get_derivatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the mention of spot price metrics on two exchanges, but there is no explicit guidance on when to choose this tool over alternatives like get_market_overview. No exclusions or prerequisite conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The largest USD stablecoins by circulating supply with 1d/7d/30d supply change and market share, plus the total change across all of them. Supply growth is a rough proxy for money entering or leaving crypto.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many stablecoins to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety is covered. The description adds real behavioral context the annotations don't: exactly which metrics come back, that coverage is limited to the largest USD stablecoins (not all stablecoins), and a caveat that supply change is only a rough proxy. It omits ordering and pagination details, keeping 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the scope and metrics, followed by a brief interpretive caveat. No filler and nothing repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, fully-annotated read tool with no output schema, the description covers return contents and coverage boundaries well, which is the main risk an agent faces here. Missing only minor details like result ordering and default-limit behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single 'limit' parameter is fully documented with default and 1-25 bounds), so the schema does the work. The description adds no parameter-level meaning beyond the 'largest' framing that hints at ordering, which is a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource and scope: largest USD stablecoins by circulating supply, with 1d/7d/30d supply change and market share plus an aggregate total. That is well beyond a restatement of the name. It is a verbless noun phrase and doesn't explicitly contrast with siblings, but the resource is unmistakably distinct from get_price/get_derivatives/get_defi_tvl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence ('Supply growth is a rough proxy for money entering or leaving crypto') gives interpretive context that implies when the tool is useful, which is better than nothing. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as get_market_overview for broader flows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_defi_tvlget_derivativesget_market_overviewget_priceget_stablecoinsScored across 5 tools
Each tool maps to an unmistakably distinct dataset: spot price, perpetual-futures metrics, market-cap overview, DeFi TVL, and stablecoin supply. There is no scenario where an agent would confuse get_price with get_derivatives or get_market_overview, and the descriptions reinforce the boundaries. Purpose separation is clean.
All five tools follow a strict get_<resource> snake_case pattern: get_price, get_derivatives, get_market_overview, get_defi_tvl, get_stablecoins. Verb and casing are uniform, making the surface predictable.
Five tools is well within a healthy scope for a market-pulse server, and each covers a genuinely different data source/domain (exchange price, derivatives, CoinGecko, DefiLlama, stablecoins). No tool feels redundant or like padding.
The snapshot surface covers price, leverage/crowding, breadth, DeFi, and liquidity proxies well, with parameterized arguments for chain/protocol/coin drilldowns. Minor gaps: no historical/time-series or candlestick data and no order-book/liquidity-depth query, so trend-over-time questions can't be answered.
Crypto market data for AI agents: live prices, OHLCV, sentiment, indicators and exchanges.
Crypto news, perps, market pulse, price history and token checks for AI agents. USDC per call.
Market and on-chain crypto data for AI agents. Pay per call in USDC on Base (x402).
Read-only Hyperliquid data for AI agents: fills, candles, funding, liquidations, wallet analytics.
