主要取引所との連携により、リアルタイムおよび過去の暗号通貨市場データを提供するモデルコンテキストプロトコル（MCP）サーバー。このサーバーにより、クロードのようなLLM（法務・法務・金融サービス）は、現在の価格を取得し、市場動向を分析し、詳細な取引情報にアクセスできるようになります。
リアルタイム市場データ
現在の暗号通貨の価格
ビッド/アスクスプレッドを含む市場概要
取引量上位ペア
複数の交換のサポート
歴史的分析
OHLCV（ローソク足）データ
価格変動統計
ボリューム履歴の追跡
カスタマイズ可能な時間枠
交換サポート
バイナンス
コインベース
クラーケン
クーコイン
ハイパーリキッド
フォビ
ビットフィネックス
バイビット
OKX
メキシコシティ
Related MCP server: Crypto MCP Server
Smithery経由で Claude Desktop 用の Cryptocurrency Market Data Server を自動的にインストールするには:
npx -y @smithery/cli install mcp-server-ccxt --client claude# Using uv (recommended)
uv pip install mcp ccxt
# Using pip
pip install mcp ccxtpython crypto_server.pyClaude Desktop の構成を次の場所で開きます:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
サーバー構成を追加します。
{
"mcpServers": {
"crypto": {
"command": "python",
"args": ["/path/to/crypto_server.py"]
}
}
}Claudeデスクトップを再起動します
価格を取得
あらゆる取引ペアの現在の価格を取得する
例: 「Binance での BTC/USDT の現在の価格はいくらですか?」
市場概要を取得する
詳細な市場情報を取得する
例:「ETH/USDTの市場概要を表示してください」
トップボリュームを獲得する
取引量上位ペアを一覧表示する
例: 「Kraken の取引ペアのトップ 5 は何ですか?」
リスト交換
サポートされているすべての取引所を表示
例: 「どの取引所がサポートされていますか?」
歴史的なOHLCVを取得する
過去のローソク足データを取得する
例:「過去7日間のBTC/USDTの価格データを1時間間隔で表示してください」
価格変更を取得
異なる期間における価格変動を計算する
例: 「SOL/USDT の 24 時間の価格変動はいくらですか?」
ボリューム履歴の取得
取引量の推移を追跡する
例:「過去1週間のETH/USDTの取引量履歴を表示してください」
サーバーが接続されたら、Claude に尋ねることができる質問の例をいくつか示します。
- What's the current Bitcoin price on Binance?
- Show me the top 5 trading pairs by volume on Coinbase
- How has ETH/USDT performed over the last 24 hours?
- Give me a detailed market summary for SOL/USDT on Kraken
- What's the trading volume history for BNB/USDT over the last week?mcp : モデルコンテキストプロトコル SDK
ccxt : 暗号通貨取引所取引ライブラリ
Python 3.9以上
サーバーは以下を使用します:
CCXTの非同期サポートによる効率的な交換通信
MCPのLLM統合ツールシステム
一貫した出力のための標準化されたデータフォーマット
最適なパフォーマンスのための接続プール
サーバーは、以下に対する堅牢なエラー処理を実装しています。
無効な取引ペア
Exchangeの接続の問題
レート制限
不正なリクエスト
ネットワークタイムアウト
# To be implemented
pytest tests/リポジトリをフォークする
機能ブランチを作成する
変更を加える
プルリクエストを送信する
# Clone the repository
git clone [repository-url]
cd crypto-mcp-server
# Install dependencies
uv pip install -e .Exchange接続エラー
インターネット接続を確認してください
取引所が稼働していることを確認する
選択した取引所に取引ペアが存在することを確認する
レート制限
リクエスト間の遅延を実装する
高頻度クエリには異なるエクスチェンジを使用する
取引所固有のレート制限を確認する
データフォーマットの問題
取引ペアの形式を確認してください（例：BTC/USDT、BTCUSDTではありません）
時間枠の仕様を確認する
数値パラメータが有効な範囲内であることを確認する
MITライセンス - 詳細はLICENSEファイルを参照
取引所統合のためのCCXT
MCP仕様のモデルコンテキストプロトコル
市場データAPIを提供する暗号通貨取引所
Get historical OHLCV (candlestick) data for a trading pair
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| timeframe | No | Timeframe for candlesticks (e.g., 1m, 5m, 15m, 1h, 4h, 1d) | 1h |
| days_back | No | Number of days of historical data to fetch (default: 7, max: 30) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on traits like rate limits, authentication needs, data freshness, or error handling. This is a significant gap for a data-fetching tool with multiple parameters.
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 a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for the tool's complexity, making it easy to parse and understand quickly.
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?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks behavioral context and usage guidelines, which are important for an agent to invoke it correctly in a server with multiple market data tools.
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?
The description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with detailed descriptions, enums, defaults, and constraints. This meets the baseline score of 3, as the schema adequately documents the parameters without needing extra explanation in the description.
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 clearly states the verb ('Get') and resource ('historical OHLCV (candlestick) data for a trading pair'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-price' or 'get-volume-history', which might also provide related market data, so it doesn't reach the highest score.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this tool is preferred, such as for chart analysis or historical trends, leaving the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed market summary for a cryptocurrency pair from a specific exchange
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but fails to describe key traits like whether it's a read-only operation, potential rate limits, authentication needs, error handling, or the format of the returned summary. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and appropriately sized for its function, making it easy to understand quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It specifies the tool's function but omits critical details such as the structure of the returned market summary, potential side effects, or error conditions. For a tool with no structured behavioral data, this leaves too many unknowns for effective agent use.
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?
The input schema has 100% description coverage, clearly documenting both parameters with examples and an enum for 'exchange'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description.
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 clearly states the action ('Get detailed market summary') and resource ('for a cryptocurrency pair from a specific exchange'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from its siblings like 'get-price' or 'get-price-change', which might also provide market-related data for cryptocurrency pairs.
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 description provides no guidance on when to use this tool versus alternatives such as 'get-price' or 'get-historical-ohlcv'. It mentions the resource but lacks explicit instructions on scenarios, prerequisites, or exclusions, leaving usage context implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current price of a cryptocurrency pair from a specific exchange
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'current price' and 'specific exchange' but fails to address critical aspects like rate limits, error handling, authentication needs, or response format. For a real-time data tool, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core purpose without unnecessary elaboration. Every word contributes directly to understanding the tool's function, making it highly concise and well-structured.
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?
Given the lack of annotations and output schema, the description is incomplete for a real-time data tool. It omits details on return values (e.g., price format, timestamp), error conditions, or performance considerations, which are essential for effective agent use in a financial context.
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?
The schema description coverage is 100%, with both parameters (symbol and exchange) fully documented in the schema. The description adds no additional semantic context beyond what the schema provides, such as examples of valid symbols beyond BTC/USDT or implications of exchange selection. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the specific action ('Get current price') and resource ('cryptocurrency pair from a specific exchange'), distinguishing it from siblings like get-historical-ohlcv (historical data) and get-market-summary (broader market info). It precisely defines the tool's scope without ambiguity.
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 description implies usage for real-time price queries but provides no explicit guidance on when to use this tool versus alternatives like get-price-change (for price changes) or get-historical-ohlcv (for historical data). It lacks context on prerequisites or exclusions, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get price change statistics over different time periods
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'price change statistics' but doesn't specify what statistics are included (e.g., percentage change, absolute values), time periods available, or any limitations like rate limits or data freshness. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, and every part of the sentence contributes to understanding the tool's function.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex statistical data. It doesn't explain what 'price change statistics' entail, the available time periods, or the format of the response, leaving the agent with insufficient context to use the tool effectively without trial and error.
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?
The input schema has 100% description coverage, with clear documentation for both parameters, including an enum for 'exchange' and a default value. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'symbol' interacts with 'exchange' or detailing time period options. This meets the baseline for high schema coverage.
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 clearly states the tool's purpose as 'Get price change statistics over different time periods,' which specifies the action (get) and resource (price change statistics) with a time dimension. However, it doesn't explicitly distinguish this from sibling tools like 'get-price' or 'get-historical-ohlcv,' which might provide overlapping or related data, leaving some ambiguity about its unique role.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-price' or 'get-historical-ohlcv,' nor does it specify scenarios or exclusions for its use, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top cryptocurrencies by trading volume from a specific exchange
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of pairs to return (default: 5) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data ('Get top cryptocurrencies'), implying a read-only operation, but doesn't specify whether it's real-time or cached, rate limits, authentication needs, or what happens if the exchange is unavailable. This leaves significant gaps for a data-fetching tool.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
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?
Given the tool's moderate complexity (fetching ranked data from exchanges), no annotations, and no output schema, the description is minimally adequate. It specifies the resource and scope but lacks details on behavior, output format, or error handling, leaving room for improvement in completeness.
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?
The input schema has 100% description coverage, with clear documentation for both parameters (limit and exchange), including defaults and enum values. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 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?
The description clearly states the action ('Get top cryptocurrencies by trading volume') and resource ('from a specific exchange'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-volume-history' or 'get-market-summary', which might also involve volume data, so it doesn't reach the highest score.
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 description provides no guidance on when to use this tool versus alternatives like 'get-volume-history' or 'get-market-summary', nor does it mention prerequisites or exclusions. It only states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get trading volume history over time
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol (e.g., BTC/USDT, ETH/USDT) | |
| days | No | Number of days of volume history (default: 7, max: 30) | |
| exchange | No | Exchange to use (supported: binance, coinbase, kraken, kucoin, hyperliquid, huobi, bitfinex, bybit, okx, mexc) | binance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves historical data, implying it's read-only, but doesn't mention rate limits, authentication needs, data freshness, or what the output looks like (e.g., format, units). This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a straightforward data retrieval tool, making it easy for an agent to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned volume history includes (e.g., time intervals, data format) or address potential complexities like handling missing data. For a tool with three parameters and no structured output information, more context is needed.
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?
The description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with detailed descriptions for all three parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or provide additional context.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('trading volume history over time'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-historical-ohlcv' or 'get-top-volumes', which might also provide volume-related data, so it doesn't reach the highest score.
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 description provides no guidance on when to use this tool versus alternatives like 'get-historical-ohlcv' or 'get-top-volumes'. It lacks context on use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported cryptocurrency exchanges
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') but doesn't describe traits like whether the list is static or dynamic, if it requires authentication, rate limits, or the format of the returned data. This leaves significant gaps for a tool with no structured safety hints.
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 a single, efficient sentence that directly states the tool's purpose without any waste. It's front-loaded and appropriately sized for a simple list operation, making it easy to parse quickly.
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?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate as a basic overview. However, with no annotations and siblings that might overlap, it lacks completeness in usage guidance and behavioral context, making it only minimally viable.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly avoids redundant information, earning a high score for not cluttering with unnecessary param semantics.
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 clearly states the action ('List') and resource ('all supported cryptocurrency exchanges'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'get-market-summary' or 'get-top-volumes', which might provide overlapping or related exchange data, so it doesn't reach a perfect score.
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 description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for a basic list, if siblings like 'get-market-summary' offer more detailed exchange info, or if it's the starting point for exchange selection. Without such context, usage is unclear.
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.
get-historical-ohlcvget-market-summaryget-priceget-price-changeget-top-volumesget-volume-historylist-exchangesScored across 7 tools
Each tool has a clearly distinct purpose with no ambiguity: get-historical-ohlcv for candlestick data, get-market-summary for detailed pair info, get-price for current price, get-price-change for statistics, get-top-volumes for volume rankings, get-volume-history for volume trends, and list-exchanges for exchange listing. The descriptions precisely differentiate their functions, making misselection unlikely.
All tool names follow a consistent verb_noun pattern using kebab-case (e.g., get-historical-ohlcv, list-exchanges). The naming is predictable and readable throughout, with 'get-' or 'list-' prefixes clearly indicating the action, ensuring a uniform and professional appearance.
With 7 tools, the server is well-scoped for cryptocurrency market data, covering key areas like pricing, volume, exchanges, and historical data. Each tool earns its place by addressing specific market analysis needs, avoiding bloat while providing comprehensive coverage for the domain.
The tool set offers strong coverage for cryptocurrency market data, including price, volume, historical data, and exchange info. Minor gaps exist, such as no tools for order book depth, trade history, or market sentiment, but agents can work around these with the provided tools for core market analysis tasks.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Crypto trading intelligence MCP — 34+ endpoints, x402 pay-per-use, AI agent strategy & execution
