一个模型上下文协议 (MCP) 服务器，使用 CoinCap API 提供全面的加密货币分析。该服务器通过易于使用的界面提供实时价格数据、市场分析和历史趋势。
这是 Tracey Russell 原创mcp-crypto-price项目的一个分支
✅ 更改内容：
已更新为使用 CoinCap v3 API（因为 v2 即将过时）。
如果时间允许，计划进行其他改进和测试。
💡 特别感谢 Coin Cap 推出的“质押到 API”订阅模式——希望更多 API 提供商也能采用。订阅疲劳确实存在！
软件包说明：该项目在 GitHub 上托管为
wazzan/mcp-coincap-jj，但在 npm 上发布为@bujaayjaay/mcp-coincap-jj
Related MCP server: Coin MCP Server
如果您是 MCP 服务器新手，本指南将提供分步说明来帮助您入门。
我在 Windows 11 VM 上对此进行了测试，以避免弄乱我的 Mac——运行完美！
Claude 桌面配置位置：
MacOS ： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows ： %APPDATA%/Claude/claude_desktop_config.json
🟢 Windows 安装指南（适用于任何 MCP 客户端的相同步骤）
安装 Node.js：（ https://nodejs.org/en ）
安装 Claude Desktop
配置Claude桌面：
打开汉堡菜单（左上角）→文件→设置→开发者→编辑配置
这将在 Windows 资源管理器中打开 claude_desktop_config.json 文件位置。
使用您最喜欢的编辑器编辑它并添加以下配置（确保包含所有右括号！）：
请注意，您可以将这些相同的说明用于任何其他 MCP 客户端
{
"mcpServers": {
"mcp-coincap-jj": {
"command": "npx",
"args": [
"-y",
"@bujaayjaay/mcp-coincap-jj"
],
"env": {
"COINCAP_API_KEY": "INPUT_YOUR_API_KEY_HERE"
}
}
}
}对于想要在本地开展项目的开发人员和贡献者：
npm install @bujaayjaay/mcp-coincap-jjgit clone https://github.com/wazzan/mcp-coincap-jj.git
cd mcp-coincap-jj
npm install # Install dependencies
npm run build # Compile TypeScript code
npm test # Run tests to verify everything works
npm start # Starts the MCP server locally用于本地测试的 MCP 服务器配置（Windows 示例）
如果使用 npx 在本地运行，请在 Claude Desktop（或任何 MCP 客户端）中使用此配置：
{
"mcpServers": {
"mcp-coincap-jj": {
"command": "cmd.exe",
"args": [
"/c",
"C:\\Program Files\\nodejs\\npx.cmd",
"C:\\Users\\YOUR-WINDOWS-USERNAME\\repos\\github\\mcp-coincap-jj"
],
"env": {
"COINCAP_API_KEY": "YOUR_API_KEY_HERE"
},
"disabled": false,
"alwaysAllow": []
}
}
}🔧 专业提示：在 Windows 上使用绝对路径可确保流畅的体验，尤其是在运行多个环境时。
尽管这会带走一些个人学习经验，但这是一个很好的快速开始！
确保您的 Claude Desktop 应用已安装 Smithery
运行以下命令：
smithery install @bujaayjaay/mcp-coincap-jj在设置过程中，系统会提示您输入 CoinCap API 密钥
您现在必须从 CoinCap 获取 API 密钥才能使用更新的 v3 API，因为 v2 已被弃用：（ https://pro.coincap.io/api-docs/ ）
get-crypto-price获取任何加密货币的当前价格和 24 小时统计数据，包括：
当前美元价格
24小时价格变动
交易量
市值
市场排名
get-market-analysis提供详细的市场分析，包括：
交易量排名前五的交易所
不同交易所的价格差异
体积分布分析
VWAP（成交量加权平均价格）
get-historical-analysis分析历史价格数据：
可定制的时间间隔（5分钟至1天）
支持最多30天的历史数据
价格趋势分析
波动率指标
高/低价范围
“比特币现在的价格是多少？”
“向我展示 ETH 的市场分析”
“给我 DOGE 的 7 天价格历史记录”
“交易 BTC 的顶级交易所有哪些？”
“显示间隔 1 小时的 SOL 价格趋势”
这个项目是 Tracey Russell 的mcp-crypto-price的一个分支，
Tracey 的项目受到了 Alex Andru 的coincap-mcp项目的启发。
该项目采用 MIT 许可证
Get current price and 24h stats for a cryptocurrency
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Cryptocurrency symbol (e.g., BTC, ETH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states output is price and 24h stats, but omits details like update frequency, data source, or behavior on invalid symbol.
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?
Single sentence, no unnecessary words, front-loaded with verb and resource.
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 simple tool (1 param, no output schema, no annotations), description is adequate for basic understanding but lacks detail on what '24h stats' includes (e.g., change, volume).
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%, baseline 3. Description adds no extra detail beyond 'gets crypto price for given symbol'; schema already specifies symbol as string with 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?
Description clearly states verb 'get', resource 'current price and 24h stats', and scope 'cryptocurrency'. Easily distinguished from siblings 'historical-analysis' and 'market-analysis'.
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?
No guidance on when to use this tool vs alternatives (e.g., for historical data use get-historical-analysis). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price analysis with customizable timeframe
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Cryptocurrency symbol (e.g., BTC, ETH) | |
| interval | No | Time interval (m5, m15, m30, h1, h2, h6, h12, d1) | h1 |
| days | No | Number of days to analyze (1-30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as data source (e.g., real-time vs delayed), caching, rate limits, or whether the analysis includes derived metrics like moving averages.
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?
Single sentence, front-loaded with action and key qualifier. No wasted words, but could benefit from a second sentence to enhance completeness without harming conciseness.
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, so the agent cannot infer return format or fields. Description lacks details on data scope (e.g., OHLCV, volume) and pagination. Adequate for a simple analysis tool but incomplete.
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?
With 100% schema coverage, parameters are documented. The description adds 'customizable timeframe' but does not elaborate on default behavior or mutually exclusive options beyond schema.
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 retrieves historical price analysis with customizable timeframe. It distinguishes from 'get-crypto-price' (current price) and 'get-market-analysis' (broader market).
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?
No explicit guidance on when to use this tool versus siblings. The description does not specify context like trend analysis vs point-in-time price, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed market analysis including top exchanges and volume distribution
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Cryptocurrency symbol (e.g., BTC, ETH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only mentions 'detailed' analysis without disclosing behavioral traits like rate limits, authentication needs, or mutability. The description adds minimal value beyond the tool name.
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 one sentence long and front-loaded with the main purpose. It is efficient but could be slightly more informative without being verbose.
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 (one param, no output schema, no annotations), the description minimally covers purpose but lacks context on when to use or what to expect. It is adequate but not complete for an autonomous agent.
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 parameter 'symbol' is fully described in the schema with coverage at 100%. The description repeats 'e.g., BTC, ETH' which is already in the schema, adding no new semantic information. Baseline score of 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 clearly states the tool retrieves 'detailed market analysis' and specifies included data like 'top exchanges and volume distribution'. It distinguishes itself from siblings 'get-crypto-price' (price only) and 'get-historical-analysis' (historical data).
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 use for market analysis but does not explicitly state when to use it versus alternatives. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect: current price, historical analysis, and market analysis. No overlap in purpose.
All tools follow a consistent 'get-' prefix with snake_case descriptors, e.g., get-crypto-price, get-historical-analysis.
Three tools is an ideal size for a focused crypto data server, covering essential operations without bloat.
Covers current price, historical trends, and market depth. Minor gap: no tool to list supported cryptocurrencies, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wazzan/mcp-coincap-jj'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
