AI 에이전트에 ChainGPT 기능을 도입할 수 있는 MCP(Model Context Protocol) 서버입니다.
최신 암호화폐 뉴스를 받아보세요
최신 암호화폐 가격을 확인하세요
최신 암호화폐 시장 동향을 알아보세요
최신 암호화폐 시장 뉴스를 받아보세요
Related MCP server: agentpulse-mcp
ChainGPT 비밀 키를 받으세요
이 서버를 실행하려면 Nodejs 환경 (v18 이상)이 필요합니다.
호환되는 MCP 클라이언트입니다. Claude Desktop을 추천합니다.
Smithery를 통해 모든 MCP 클라이언트에 ChainGPT MCP 서버를 자동으로 설치하려면:
지엑스피1
이렇게 하면 Claude 데스크톱 설정에 서버가 추가됩니다. claude 사용 중인 클라이언트 이름으로 바꾸세요. 클라이언트 목록은 여기에서 확인하세요.
pnpm install -g @kohasummon/chaingpt-mcpClaude Desktop 앱 설정 내부에서 claude_desktop_config.json을 찾을 수 있습니다.
Claude Desktop 앱을 열고 왼쪽 상단 메뉴 표시줄에서 개발자 모드를 활성화하세요.
활성화되면 설정(왼쪽 상단 메뉴 표시줄에서도 가능)을 열고 개발자 옵션으로 이동하면 '구성 편집' 버튼이 있습니다. 이 버튼을 클릭하면 claude_desktop_config.json 파일이 열리고 필요한 편집 작업을 할 수 있습니다.
또는 (터미널에서 claude_desktop_config.json을 열려는 경우)
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsoncode %APPDATA%\Claude\claude_desktop_config.json{
"mcpServers": {
"chaingpt": {
"command": "npx",
"args": ["/path/to/chaingpt-mcp/build/index.js"],
"env": {
"CHAINGPT_SECRET_KEY": "your-secret-key-here"
},
"toolCallTimeoutMillis": 120000
}
}
}your-secret-key-here app.chaingpt.org/apidashboard 의 실제 ChainGPT 비밀 키로 바꾸세요.
변경 사항을 적용하려면 다음을 수행하세요.
Claude Desktop을 완전히 종료합니다(창을 닫는 것만이 아닙니다)
Claude Desktop을 다시 시작하세요
ChainGPT MCP 서버가 연결되었는지 확인하려면 🔌 아이콘을 찾으세요.
서버를 찾을 수 없습니다
npm 링크가 올바르게 설정되었는지 확인하세요
Claude Desktop 구성 구문 확인
Node.js가 제대로 설치되었는지 확인하세요
API 키 문제
CHAINGPT_SECRET_KEY가 유효한지 확인하세요
Claude Desktop 구성에서 CHAINGPT_SECRET_KEY가 올바르게 설정되었는지 확인하세요.
API 키 주위에 공백이나 따옴표가 없는지 확인하세요.
연결 문제
Claude Desktop을 완전히 다시 시작하세요
Claude Desktop 로그 확인:
Node.js는 최소 v18 이상이어야 합니다.
# macOS
tail -n 20 -f ~/Library/Logs/Claude/mcp*.log
# Windows
type "%APPDATA%\Claude\logs\mcp*.log"도구 호출 시간 초과
도구 호출 시간 초과를 120초 이상으로 설정하세요.
이는 claude_desktop_config.json 파일에서 변경할 수 있습니다.
도구 이름 | 설명 | 즉각적인 |
체인pt_인보크_챗 | ChainGPT AI와 채팅을 시작하고 제공된 질문에 대한 답변을 받으세요. | 어제 0.001 ETH를 샀는데, 지금 가격은 얼마인가요? |
체인지pt_get_news | 최신 암호화폐 뉴스를 받아보세요 | 암호화폐 세계의 최신 소식은 무엇인가요? |
풀 리퀘스트는 환영합니다. 중요한 변경 사항이 있는 경우, 먼저 이슈를 열어 변경 사항을 논의해 주세요.
Joshua Omobola 가 ❤️로 만들었습니다
Get the latest AI-related crypto and web3 articles.
Web3-native AI assistant built specifically for the crypto world.
it source, filter, deduplicate, and summarize up-to-date crypto news from many outlets in real time
it continuously scans trusted crypto news sites (e.g. CoinDesk, CoinTelegraph, Decrypt) and even social platforms like Twitter for breaking updates.
You can call this tool without any parameters to get the latest news. It returns 10 news articles by default.
Capabilities:
- Source, filter, deduplicate, and summarize up-to-date crypto news from many outlets in real time
- Continuously scans trusted crypto news sites (e.g. CoinDesk, CoinTelegraph, Decrypt) and even social platforms like Twitter for breaking updates.
- Summarize news in a concise manner, providing the most important details and context.
- Provides a link to the original article for more detailed information.
⚠️ COST WARNING: This tool makes an API call to ChainGPT which may incur costs. The key is charged 1 credit per 10 records returned
This tool allows you to interact with ChainGPT's AI News Generator.
Args:
categoryId(number[], optional): The category ID of the news to fetch. Blockchain Gaming = [2], DAO = [3], DApps = [4], DeFi = [5], Lending = [6], Metaverse = [7], NFT = [8], Stablecoins = [9], Cryptocurrency = [64], Decentralized = [65], Smart Contracts = [66], Distributed Ledger = [67], Cryptography = [68], Digital Assets = [69], Tokenization = [70], Consensus Mechanisms = [71], ICO (Initial Coin Offering) = [72], Crypto Wallets = [73], Web3.0 = [74], Interoperability = [75], Mining = [76], Cross-Chain Transactions = [77], Exchange = [78].
subCategoryId(number[], optional): The sub-category ID of the news to fetch. Bitcoin = [11], BNB Chain = [12], Celo = [13], Cosmos = [14], Ethereum = [15], Filecoin = [16], Flow = [17], Harmony = [41], Polygon = [20], XRP Ledger = [21], Solana = [22], TRON = [23], Cardano = [34], Monero = [19], Cronos = [36], Ontology = [44], WAX = [26], Optimism = [45], Other (Miscellaneous) = [46], PlatON = [47], Steem = [56], Rangers = [49], SX Network = [57], Ronin = [50], Telos = [58], Shiden = [51], Telos EVM = [59], SKALE = [52], Theta = [61], Stacks = [54], ThunderCore = [62], Stargaze = [55].
tokenId(number[], optional): The token ID of the news to fetch. BTC = [79], MATIC = [91], ETH = [80], DOT = [92], USDT = [81], LTC = [93], BNB = [82], WBTC = [94], XRP = [83], BCH = [95], USDC = [84], LINK = [96], SOL = [85], SHIB = [97], ADA = [86], LEO = [98], DOGE = [87], TUSD = [99], TRX = [88], AVAX = [100], TON = [89], XLM = [101], DAI = [90], XMR = [102], UNI = [105], OKB = [103], ETC = [106], ATOM = [104], BUSD = [107], HBAR = [108].
searchQuery(string, optional): The search query to fetch the news.
limit(number, optional): The number of news to fetch. Default is 10. You can increase this to retrieve more articles in one call (e.g. limit: 20 for 20 articles). Note that higher limits will consume additional credits (see Rate Limits & Credits). If you only want a small number of the latest articles, you can set a smaller limit as well.
offset(number, optional): The offset of the news to fetch. Default is 0. This is used for pagination. For example, to get the second page of results when using a limit of 10, you would set offset: 10 (skip the first 10 articles, return the next set). Similarly, offset: 20 would fetch the third page (items 21–30), and so on.
fetchAfter(Datetime, optional): The date after which to fetch the news. Provide a JavaScript Date object or a date string (which will be interpreted in UTC by the API). For example, fetchAfter: new Date('2024-01-01') will fetch news items published from January 1, 2024 onward. This is useful for getting news within a certain time range (e.g., only recent news).
sortBy(string, optional): The field by which to sort the news. Currently, the only supported sort key is 'createdAt', which corresponds to the article's publication time. By default, results are sorted by newest (most recent) first. If not provided, the SDK will sort by createdAt descending. (At this time, no other sort fields are supported.)
Returns:
The response from ChainGPT AI to the provided question or message.
| Name | Required | Description | Default |
|---|---|---|---|
| categoryId | No | The category ID of the news to fetch. | |
| subCategoryId | No | The sub-category ID of the news to fetch. | |
| tokenId | No | The token ID of the news to fetch. | |
| searchQuery | No | The search query to fetch the news. | |
| sortBy | No | The field to sort the news by. Default and currently only supported field is 'createdAt'. | |
| limit | No | The number of news to fetch. Default is 10. You can increase this to retrieve more articles in one call (e.g. limit: 20 for 20 articles). Note that higher limits will consume additional credits. MIN: 10 | |
| offset | No | The offset of the news to fetch. Default is 0. This is used for pagination. For example, to get the second page of results when using a limit of 10, you would set offset: 10 (skip the first 10 articles, return the next set). Similarly, offset: 20 would fetch the third page (items 21–30), and so on. | |
| fetchAfter | No | The date after which to fetch the news. Provide a JavaScript Date object or a date string (which will be interpreted in UTC by the API). For example, fetchAfter: new Date('2024-01-01') will fetch news items published from January 1, 2024 onward. This is useful for getting news within a certain time range (e.g., only recent news). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses API call cost (1 credit per 10 records), sources scanned (CoinDesk, etc.), and default behavior (10 articles). Does not describe error handling or rate limits beyond cost, but provides sufficient transparency for safe invocation.
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 verbose and contains redundant phrases (e.g., 'source, filter, deduplicate, and summarize' repeated). While well-structured with sections, it would benefit from trimming unnecessary repetition.
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?
Covers all aspects: purpose, parameter details, cost, default behavior, and return value (articles with summaries and links). No output schema, but description adequately explains outputs. Complete for a news retrieval 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?
All 8 parameters are explained in detail beyond schema descriptions, with examples for categoryId, subCategoryId, tokenId, fetchAfter, and sortBy. The description adds meaningful context that aids correct parameter usage.
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 it retrieves AI-related crypto and web3 articles, using specific verbs like 'get' and 'fetch', and distinguishes from sibling tools (chat history and invoke chat) by focusing on news retrieval.
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?
Provides explicit guidance on calling without parameters and how to use limit/offset for pagination. Includes cost warning, but lacks explicit when-not-to-use scenarios or comparisons with alternatives beyond mentioning it's built for crypto news.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the chat history for a given chat blob id until the limit is reached retrieve saved chat history. By default, this will retrieve history entries associated with your API key. If you provide a specific sdkUniqueId, it will retrieve history entries associated with that chat blob id.
Args:
sdkUniqueId (str): The unique identifier for the chat.
limit (int, optional): The maximum number of chat history items to return. Default is 10.
offset (int, optional): The offset to start the chat history from. Default is 0.
sortBy (str, optional): The field to sort the chat history by. Default is 'createdAt'.
sortOrder (str, optional): The order to sort the chat history by. Default is 'ASC'.
Returns:
The chat history for the given chat blob id until the limit is reached.
| Name | Required | Description | Default |
|---|---|---|---|
| sdkUniqueId | Yes | The unique id of the chat blob to get the history for. If not provided, it will return the chat history for all chat blobs until the limit is reached. | |
| limit | Yes | The maximum number of chat history items to return. Default is 10. | |
| offset | Yes | The offset to start the chat history from. Default is 0. | |
| sortBy | Yes | The field to sort the chat history by. Default is 'createdAt'. | |
| sortOrder | Yes | The order to sort the chat history by. Default is 'ASC'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions default behavior tied to API key and the selectable chat blob ID, but fails to mention read-only nature, authentication requirements, rate limits, or what happens when limit is exceeded. It describes retrieval but does not confirm non-destructive 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?
The description includes a docstring with Args and Returns sections, making it structured but not overly concise. It could be shortened by removing redundant repetition of schema details while keeping key behaviors.
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?
The tool has 5 required parameters and no output schema. The description does not explain the return format, pagination behavior, error conditions, or any constraints like maximum limit. The return value is vaguely described as 'The chat history' without structure, leaving the agent underinformed.
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 the schema documents all 5 parameters fully. The description repeats parameter information in a structured Args list, adding little beyond the schema. It provides default values and order information, but no unique semantic insight.
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 'Get the chat history for a given chat blob id' using a specific verb and resource. It distinguishes from siblings like 'chaingpt_get_ai_crypto_news' and 'chaingpt_invoke_chat' by focusing on chat history retrieval.
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 some context on when to use the sdkUniqueId (to filter by chat blob) versus default (all chat blobs), but does not explicitly compare to alternative tools or state when not to use this tool. The guidance is implicit but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a chat with ChainGPT AI and get a response based on the provided question.
Web3-native AI assistant built specifically for the crypto world.
It has deep blockchain expertise, enabling seamless integration of crypto-aware AI into your applications.
The model is trained on blockchain data (smart contracts, DeFi protocols, NFTs, DAOs) and real-time market information,
making it ideal for use cases like customer support, on-chain analytics, trading assistance, and community engagement
Capabilities:
- Aggregate any amount of web3 market statistics
- Interact with Blockchains
- Live information tracking of 5,000+ cryptos.
- AI Generated News
⚠️ COST WARNING: This tool makes an API call to ChainGPT which may incur costs.
This tool allows you to interact with ChainGPT's conversational AI capabilities.
Args:
question (str): The question or message to send to ChainGPT.
chatHistory (str, optional): Whether to include chat history in the request.
Defaults to "off" if not provided. Can be set to "on" to maintain conversation context.
sdkUniqueId (str, optional): The unique identifier for the chat.
Defaults to a random UUID if not provided
Returns:
The response from ChainGPT AI to the provided question or message.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| chatHistory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a cost warning and outlines capabilities, but does not disclose response format, error handling, or performance constraints. The behavioral disclosure is partial.
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 verbose with redundant sections (e.g., capabilities list and repeated purpose statement). It could be more concise and front-loaded with essential 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?
Given no annotations, no output schema, and zero schema description coverage, the description provides some context about ChainGPT's domain but misses details on response handling, error cases, and parameter usage. The contradictions reduce 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 description adds context for chatHistory (default "off") but contradicts the schema, which requires it. It also introduces sdkUniqueId not present in the schema. Schema coverage is 0%, so description should compensate but instead introduces inconsistencies.
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 it invokes a chat with ChainGPT AI and gets a response based on a question, specifying it's a Web3 AI assistant. However, it does not explicitly differentiate from sibling tools chaingpt_get_ai_crypto_news and chaingpt_get_chat_history, missing an opportunity to guide selection.
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 includes a cost warning, implying when use is appropriate, but lacks explicit guidance on when to use this tool versus its siblings. It does not state alternatives or when not to use it.
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.
chaingpt_get_ai_crypto_newschaingpt_get_chat_historychaingpt_invoke_chatScored across 3 tools
Each tool serves a distinct purpose: news retrieval, chat history, and chat invocation. There is no overlap or ambiguity in their functionality.
All tools follow a consistent 'chaingpt_verb_noun' pattern (e.g., chaingpt_get_ai_crypto_news, chaingpt_invoke_chat), making it easy to predict tool names.
With 3 tools, the set is minimal but covers the core features of the server (news, chat, chat history). While more tools could be added, the count is reasonable for the focused scope.
The tool surface includes the primary operations: reading news, sending chat messages, and retrieving history. Minor gaps exist (e.g., no tool for managing sessions or filtering news by source), but the essentials are covered.
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
AI agent gateway with web fetching, data extraction, crypto pricing, and x402 payments
Live crypto prices, conversion, gas tracker, portfolio tools, and calculators for AI agents.
