CoinCap API를 사용하여 포괄적인 암호화폐 분석을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 사용하기 쉬운 인터페이스를 통해 실시간 가격 데이터, 시장 분석 및 과거 추세를 제공합니다.
이것은 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 서버를 처음 사용하는 분이라면 이 가이드에서 단계별 지침을 참고하여 시작하는 데 도움을 받으세요.
Mac을 복잡하게 만들지 않기 위해 Windows 11 VM에서 이 기능을 테스트했는데, 아무 문제 없이 작동했습니다!
Claude Desktop 구성 위치:
MacOS : ~/Library/Application Support/Claude/claude_desktop_config.json
윈도우 : %APPDATA%/Claude/claude_desktop_config.json
🟢 Windows 설치 가이드(모든 MCP 클라이언트에 동일한 단계)
Node.js 설치: ( https://nodejs.org/en )
Claude Desktop 설치
Claude Desktop 구성:
햄버거 메뉴(왼쪽 상단 모서리)를 엽니다 → 파일 → 설정 → 개발자 → 구성 편집
이렇게 하면 Windows 탐색기에서 claude_desktop_config.json 파일 위치가 열립니다.
좋아하는 편집기를 사용하여 편집하고 다음 구성을 추가하세요(닫는 중괄호를 모두 포함했는지 확인하세요!):
다른 MCP 클라이언트에도 동일한 지침을 사용할 수 있습니다.
지엑스피1
프로젝트를 현지에서 진행하고자 하는 개발자와 기여자의 경우:
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 키를 입력하라는 메시지가 표시됩니다.
이제 v2가 더 이상 사용되지 않으므로 업데이트된 v3 API를 사용하려면 CoinCap에서 API 키를 얻어야 합니다. ( https://pro.coincap.io/api-docs/ )
get-crypto-price다음을 포함한 모든 암호화폐의 현재 가격과 24시간 통계를 가져옵니다.
현재 가격 (USD)
24시간 가격 변경
거래량
시가총액
시장 순위
get-market-analysis다음을 포함한 자세한 시장 분석을 제공합니다.
거래량 기준 상위 5개 거래소
거래소별 가격 변동
체적 분포 분석
VWAP(거래량 가중 평균 가격)
get-historical-analysis다음을 사용하여 과거 가격 데이터를 분석합니다.
사용자 정의 가능한 시간 간격(5분~1일)
최대 30일 동안의 과거 데이터 지원
가격 추세 분석
변동성 지표
높은/낮은 가격 범위
"비트코인의 현재 가격은 얼마인가요?"
"ETH 시장 분석을 보여주세요"
"DOGE의 7일 가격 내역을 알려주세요"
"BTC를 거래하는 주요 거래소는 어디인가요?"
"1시간 간격으로 SOL 가격 추세를 보여주세요"
이 프로젝트는 Tracey Russell의 mcp-crypto-price 의 포크입니다.
트레이시의 프로젝트는 알렉스 안드루의 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
