Chronos는 Stellar 블록체인에 맞춰 설계된 모델 컨텍스트 프로토콜(MCP) 서버로, Claude Desktop 및 유사 AI 애플리케이션과의 통합을 위해 특별히 설계되었습니다. Chronos는 온체인 도구를 통해 AI 비서가 Stellar 네트워크와의 원활한 상호작용을 할 수 있도록 지원합니다.
Chronos MCP는 다음과 같은 기능을 제공합니다.
Stellar 지갑에 연결: 비밀 키를 사용하여 지갑에 안전하게 연결하세요.
지갑 토큰 목록: Stellar 지갑에 보관된 모든 토큰을 검색하여 나열합니다.
잔액 조회: XLM 및 기타 자산의 실시간 잔액을 확인하세요.
자금 이체: Stellar 지갑 간에 간편하게 자금 이체를 시작하세요.
Chronos는 확장 가능하도록 만들어졌으며 표준 Node.js 패키지로 작동하므로 다른 MCP 서버(예: base-mcp)와 유사하게 쉽게 배포, 설치 및 통합할 수 있습니다.
Related MCP server: AMOCA Solana MCP Server
Stellar 통합: Horizon API를 통해 Stellar 메인넷과 완벽하게 상호 작용합니다.
간편한 배포: npm을 사용하여 Chronos를 게시하고 설치합니다.
Claude Desktop 호환성: MCP 서버 구성을 업데이트하여 Claude Desktop과 원활하게 통합합니다.
확장 가능한 아키텍처: 향후 개선 및 새로운 도구 통합을 위해 설계되었습니다.
Node.js(v14 이상)
엔피엠
Stellar 지갑 자격 증명(연결을 위한 비밀 키)
Stellar 네트워크와 상호 작용하기 위한 인터넷 연결
Chronos를 전역으로 설치하세요:
지엑스피1
또는 npx와 함께 직접 사용하세요:
npx chronos-mcp@latest저장소를 복제합니다.
git clone https://github.com/yourusername/chronos-mcp.git
cd chronos-mcp종속성 설치:
npm install프로젝트를 빌드하세요:
npm run build(선택 사항) 더 쉽게 액세스할 수 있도록 글로벌 링크:
npm linkDocker를 사용하여 Chronos MCP를 실행할 수도 있습니다.
Docker 이미지를 빌드합니다.
docker build -t chronos-mcp .컨테이너를 실행합니다.
docker run -it --rm chronos-mcpClaude Desktop과 Docker Compose 설정 및 통합을 포함하여 Chronos MCP와 함께 Docker를 사용하는 방법에 대한 자세한 지침은 Docker 사용 가이드를 참조하세요.
Docker 설정이 로컬에서 작동하는지 테스트하려면 Docker 테스트 가이드 의 단계별 지침을 따르세요. 이 가이드에는 Docker 이미지 빌드, 컨테이너 실행 및 기능 테스트에 대한 지침이 포함되어 있습니다.
Chronos MCP는 구성, 특히 Stellar 비밀 키와 같은 민감한 정보의 경우 환경 변수를 사용합니다. 이 프로젝트는 개발 과정에서 dotenv 사용하여 .env 파일에서 환경 변수를 불러옵니다.
환경 변수를 구성하려면:
프로젝트 루트에 .env 파일을 만듭니다.
STELLAR_SECRET_KEY=your_stellar_secret_key
STELLAR_NETWORK=mainnet이러한 변수는 애플리케이션이 시작될 때 자동으로 로드됩니다.
Docker를 사용할 때 여러 가지 방법으로 환경 변수를 제공할 수 있습니다.
--env-file 플래그 사용: docker run -it --rm --env-file .env chronos-mcp
docker-compose.yml에서 env_file 지시어 사용
-e 플래그를 사용하여 개별 변수 설정: docker run -it --rm -e STELLAR_SECRET_KEY=your_key chronos-mcp
Claude Desktop과 함께 Chronos를 사용하려면 다음 위치에 있는 Claude Desktop 구성 파일을 업데이트하세요.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
리눅스: ~/.config/Claude/claude_desktop_config.json
Claude Desktop에 대한 샘플 구성:
{
<<<<<<< HEAD
"mcpServers": {
"stellar": {
"command": "npx",
"args": ["chronos-mcp@latest"],
"env": {
"STELLAR_NETWORK": "mainnet",
"STELLAR_SECRET_KEY": "your_stellar_secret_key"
},
"disabled": false,
"autoApprove": []
}
}
}Claude Desktop과 Docker를 통합하려면 다음을 사용할 수 있습니다.
{
"mcpServers": {
"stellar": {
"command": "docker",
"args": ["run", "-i", "--rm", "--env-file", "/path/to/your/.env", "chronos-mcp"],
"env": {
"STELLAR_NETWORK": "mainnet"
},
"disabled": false,
"autoApprove": []
=======
"mcpServers": {
"stellar": {
"command": "npx",
"args": [
"chronos-mcp@latest"
],
"env": {
"STELLAR_NETWORK": "mainnet",
"STELLAR_SECRET_KEY": "XXXX"
},
"disabled": false,
"autoApprove": []
}
>>>>>>> b2501026b3b5ef4c512fceaf340f53b5102a57f9
}
}Chronos MCP는 MCP 인터페이스를 통해 다음 도구를 제공합니다.
비밀 키를 사용하여 Stellar 지갑에 연결합니다.
예제 명령:
"비밀 키 ______를 사용하여 내 지갑을 연결하세요"
지정된 Stellar 지갑에 있는 모든 토큰과 자산을 나열합니다.
예제 명령:
"내 지갑 토큰 목록"
XLM 및 기타 자산의 잔액을 검색합니다.
예제 명령:
"현재 내 XLM 잔액은 얼마인가요?"
귀하의 지갑에서 다른 Stellar 지갑으로 자금을 이체합니다.
매개변수:
secretKey : 지갑 비밀 키.
destinationAddress : 수신자의 지갑 주소.
amount : 이체할 금액.
asset(선택 사항) : 전송할 자산(기본값은 XLM)
예제 명령:
"[대상 지갑 주소]로 0.5 XLM을 이체하세요."
로컬에서 Chronos MCP를 테스트하려면:
npm test이렇게 하면 프로젝트 테스트 모음이 실행되고 서버가 예상대로 작동하는지 확인됩니다.
Docker 설정을 로컬에서 테스트하려면 Docker 테스트 가이드 에서 자세한 지침을 참조하세요. 가이드에는 다음 내용이 포함됩니다.
Docker 이미지 빌드
Docker Compose로 컨테이너 실행
컨테이너 기능 테스트
일반적인 문제 해결
포함된 test-client.js 스크립트를 사용하여 Docker 컨테이너를 테스트할 수도 있습니다.
node test-client.js이 스크립트는 Docker 컨테이너에 간단한 MCP 요청을 보내고 응답을 표시합니다.
Chronos MCP는 표준 Node.js 패키지로 작동하도록 설계되었으며 npm에 게시할 수 있습니다. 게시된 후에는(예: npm publish ) 다른 MCP 서버와 마찬가지로 Chronos를 전역으로 설치하거나 npx를 통해 사용할 수 있습니다.
실제 운영에 배포하는 경우, 자동 재시작 및 모니터링을 위해 Chronos를 시스템 서비스(systemd, launchd 등 사용)로 래핑하는 것을 고려하세요.
Chronos는 확장성을 염두에 두고 제작되었습니다. 새로운 도구를 추가하려면 다음을 수행하세요.
src/tools 폴더에 새 디렉토리를 만듭니다.
도구를 구현합니다( index.ts , schemas.ts , handlers.ts 포함).
src/tools/index.ts 로 도구를 내보냅니다.
README에 도구 설명서와 예제를 추가하세요.
새로운 도구가 제대로 작동하는지 확인하기 위해 테스트를 작성하세요.
이 프로젝트는 MIT 라이선스 에 따라 라이선스가 부여되었습니다.
기여를 환영합니다! 문제 보고, 풀 리퀘스트 제출 및 기타 기여 지침은 CONTRIBUTING.md 를 참조하세요.
────────────────────────────── 이 README는 Chronos MCP에 맞춰 특별히 작성되었으며, Node.js 패키지로서의 배포, Claude Desktop과의 통합, Stellar 블록체인과 상호 작용하는 포괄적인 기능 세트에 대한 개요를 설명합니다.
Connect to a Stellar wallet using secret key
| Name | Required | Description | Default |
|---|---|---|---|
| secretKey | Yes | Stellar wallet secret key |
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 connects using a secret key but doesn't describe what happens after connection (e.g., session persistence, error handling, or security implications like key storage). For a tool handling sensitive authentication with no annotation coverage, this is a significant gap in transparency.
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 with zero waste. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place by specifying the tool's purpose clearly without redundancy.
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 complexity of wallet connection (involving authentication and potential security concerns), no annotations, no output schema, and a single parameter, the description is incomplete. It doesn't explain what the tool returns (e.g., success status, wallet details) or behavioral aspects like error cases, leaving gaps for an AI agent to understand the tool fully.
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 the parameter 'secretKey' documented as 'Stellar wallet secret key'. The description adds no additional meaning beyond this, as it only repeats that connection uses a secret key. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.
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 ('Connect to') and target resource ('a Stellar wallet'), specifying it uses a secret key. It distinguishes from sibling tools like get_balances or transfer_funds by focusing on authentication rather than querying or transactions. However, it doesn't explicitly differentiate from potential other connection methods (e.g., via public key or mnemonic), keeping it from 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a secret key), when not to use it (e.g., if already connected), or how it relates to sibling tools like get_balances. The description implies usage for wallet connection but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get balances for all tokens in a Stellar wallet
| Name | Required | Description | Default |
|---|---|---|---|
| publicKey | Yes | Stellar wallet public key |
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's function but lacks critical details: it doesn't specify if this is a read-only operation (implied but not explicit), potential rate limits, authentication needs, error conditions, or what the output format looks like (e.g., JSON structure). This leaves significant gaps for safe and effective use.
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 ('Get balances for all tokens in a Stellar wallet'). There is no wasted verbiage or redundancy, 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 lack of annotations and output schema, the description is incomplete for a tool that interacts with financial data. It doesn't explain return values (e.g., balance amounts, token details), error handling, or dependencies on other tools like 'connect_wallet'. For a tool with no structured output documentation, this leaves the agent under-informed.
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%, with the single parameter 'publicKey' clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., format examples, validation rules, or context about the wallet). This meets the baseline for high schema coverage but doesn't enhance understanding.
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 balances') and resource ('all tokens in a Stellar wallet'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_tokens' (which might list available tokens vs. getting balances), leaving room for potential confusion.
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 prerequisites (e.g., needing a connected wallet via 'connect_wallet'), exclusions, or comparisons to siblings like 'list_tokens' or 'transfer_funds', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tokens in a Stellar wallet
| Name | Required | Description | Default |
|---|---|---|---|
| publicKey | Yes | Stellar wallet public key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, requires authentication, has rate limits, or what the output format might be. While 'List' suggests a safe read, the lack of details on permissions or response structure is a significant gap for a tool with zero 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 unnecessary words. Every part earns its place by directly stating the tool's function, making it highly concise and well-structured for quick 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?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what 'tokens' entail (e.g., types, formats), authentication needs, or response behavior. For a tool with one parameter but no structured safety or output info, more context is needed to guide the agent adequately.
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%, with the parameter 'publicKey' fully documented in the schema. The description adds no additional meaning beyond implying it's for a Stellar wallet, which is already clear from the schema. This meets the baseline of 3, as the schema handles the heavy lifting without extra value from 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 action ('List') and resource ('tokens in a Stellar wallet'), making the purpose immediately understandable. It distinguishes from siblings like 'get_balances' by focusing specifically on tokens rather than general balances. However, it doesn't specify whether this includes all token types or just specific ones, keeping it from 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?
No explicit guidance is provided on when to use this tool versus alternatives like 'get_balances' or 'connect_wallet'. The description implies usage for token listing but doesn't mention prerequisites (e.g., needing a connected wallet) or exclusions. This leaves the agent to infer context without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer funds to another Stellar wallet
| Name | Required | Description | Default |
|---|---|---|---|
| secretKey | Yes | Source wallet secret key | |
| destinationAddress | Yes | Destination wallet public key | |
| amount | Yes | Amount to transfer | |
| asset | No | Asset to transfer (defaults to XLM) |
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 performs a fund transfer but fails to mention critical aspects such as whether this is a destructive/mutative operation, authentication requirements (implied by 'secretKey' but not explicitly stated), potential rate limits, transaction fees, or error handling. This leaves significant gaps in understanding the tool's 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 is a single, direct sentence that efficiently conveys the core purpose without any unnecessary words or fluff. It is appropriately sized and front-loaded, 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 complexity of a financial transaction tool with no annotations and no output schema, the description is insufficient. It lacks details on return values, error conditions, security implications, or operational constraints, making it incomplete for safe and effective use by an AI 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 schema description coverage is 100%, so the input schema already documents all parameters thoroughly (e.g., 'secretKey' as source wallet secret key, 'destinationAddress' as destination public key). The description adds no additional semantic context beyond what's in the schema, such as format details or examples, resulting in a 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 ('transfer funds') and target resource ('to another Stellar wallet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'connect_wallet' or 'get_balances', which are distinct operations, so it doesn't reach the highest score for sibling differentiation.
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 or any contextual prerequisites. It lacks explicit instructions on usage scenarios, exclusions, or comparisons with sibling tools like 'list_tokens', leaving the agent to infer usage based on the tool name alone.
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.
connect_walletget_balanceslist_tokenstransfer_fundsScored across 4 tools
Each tool has a clearly distinct purpose: connect_wallet handles authentication, get_balances retrieves token balances, list_tokens enumerates available tokens, and transfer_funds performs transactions. There is no overlap or ambiguity between these functions.
All tools follow a consistent verb_noun pattern (connect_wallet, get_balances, list_tokens, transfer_funds) with clear, descriptive names. The naming convention is uniform and predictable throughout the set.
Four tools are reasonable for a Stellar wallet server, covering core operations like connection, balance checking, token listing, and transfers. However, the scope feels slightly thin as it lacks tools for advanced wallet management (e.g., transaction history, account details).
The tools cover essential wallet operations: authentication, balance retrieval, token listing, and fund transfers. Minor gaps exist, such as no tools for viewing transaction history or managing wallet settings, but agents can perform basic workflows without significant dead ends.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The OpenZeppelin Stellar Contracts MCP server generates secure smart contracts for the Stellar blockchain based on OpenZeppelin templates. It integrates with AI assistants to automatically enforce OpenZeppelin's security best practices, style rules, and standards at every prompt, enabling developers to create production-ready Fungible Token, Non-Fungible Token, and Stablecoin contracts through AI-driven workflows.
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
