이 프로젝트는 탈중앙화 거래소(DEX)와 상호 작용하는 모델 컨텍스트 프로토콜(MCP) 서버를 구현합니다. 이를 통해 MCP 호환 클라이언트(AI 어시스턴트, IDE 확장 프로그램 또는 사용자 지정 애플리케이션 등)가 스왑 시세 조회 및 스왑 실행 등의 기능에 액세스할 수 있습니다.
이 서버는 TypeScript와 fastmcp 사용하여 구축되었습니다.
서버는 MCP 클라이언트가 활용할 수 있는 다음과 같은 도구를 제공합니다.
ODOS_GET_QUOTE : 스왑에 대한 견적을 가져옵니다.
매개변수: chainId (숫자), sellToken (문자열), buyToken (문자열), sellAmount (문자열)
ODOS_EXECUTE_SWAP : 스왑을 실행합니다.
매개변수: chainId (숫자), sellToken (문자열), buyToken (문자열), sellAmount (문자열), quote (문자열), walletProvider (문자열)
chainId : DEX의 체인 ID입니다.
sellToken : 판매하려는 토큰.
buyToken : 구매하려는 토큰.
sellAmount : 판매하려는 토큰의 양.
quote : get-quote 서비스에서 받은 견적입니다.
walletProvider : 사용하려는 지갑 제공자입니다.
Related MCP server: CCXT MCP Server
Node.js(v18 이상 권장)
pnpm( https://pnpm.io/installation 참조)
mcp-odos 사용하는 방법은 여러 가지가 있습니다.
1. pnpm dlx 사용(대부분의 MCP 클라이언트 설정에 권장):
pnpm dlx 사용하면 전역 설치 없이 서버를 직접 실행할 수 있습니다. 이는 MCP 클라이언트와 통합하는 가장 쉬운 방법입니다. "MCP 클라이언트로 서버 실행" 섹션에서 예시를 참조하세요. ( pnpm dlx 는 pnpm의 npx 와 동일합니다.)
2. npm에서 글로벌 설치(pnpm을 통해):
mcp-odos 명령을 시스템 전체에서 사용할 수 있도록 패키지를 전역적으로 설치합니다.
지엑스피1
3. 소스에서 빌드(개발 또는 사용자 정의 수정용):
저장소를 복제합니다.
git clone https://github.com/IQAIcom/mcp-odos.git
cd mcp-odos종속성 설치:
pnpm install서버 빌드: TypeScript 코드를 dist 디렉토리의 JavaScript로 컴파일합니다.
pnpm run buildprepare 스크립트는 또한 pnpm run build 실행하므로 pnpm install 복제하고 실행하면 종속성이 설치 시에 빌드됩니다.
이 MCP 서버는 서버를 실행하는 MCP 클라이언트에서 특정 환경 변수를 설정해야 할 수 있습니다. 이러한 환경 변수는 일반적으로 클라이언트의 MCP 서버 정의(예: Cursor의 경우 mcp.json 파일, 다른 클라이언트의 경우 유사 파일)에서 구성됩니다.
지갑 제공자 또는 API 키에 필요한 환경 변수입니다.
MCP 클라이언트(AI 어시스턴트, IDE 확장 프로그램 등)는 이 서버를 백그라운드 프로세스로 실행합니다. 클라이언트가 서버를 시작하는 방법을 지정하도록 설정해야 합니다.
다음은 MCP 클라이언트가 사용할 수 있는 구성 스니펫의 예입니다(예: mcp_servers.json 또는 유사한 구성 파일). 이 예에서는 pnpm dlx 통해 게시된 npm 패키지를 사용하여 서버를 실행하는 방법을 보여줍니다.
{
"mcpServers": {
"iq-odos-mcp-server": {
"command": "pnpm",
"args": ["dlx", "mcp-odos"],
"env": {
"WALLET_PRIVATE_KEY": "your_wallet_private_key_here"
}
}
}
}글로벌하게 설치된 경우의 대안:
mcp-odos 전역으로 설치한 경우( pnpm add -g mcp-odos ), command 과 args 간소화할 수 있습니다.
{
"mcpServers": {
"iq-odos-mcp-server": {
"command": "mcp-odos",
"args": [],
"env": {
"WALLET_PRIVATE_KEY": "your_wallet_private_key_here"
}
}
}
}command : 실행할 실행 파일.
pnpm dlx 의 경우: "pnpm" (첫 번째 인수가 "dlx" )
글로벌 설치의 경우: "mcp-odos"
args : 명령에 전달할 인수 배열입니다.
pnpm dlx 의 경우: ["dlx", "mcp-odos"]
글로벌 설치의 경우: []
env : 서버 프로세스가 시작될 때 설정되는 환경 변수를 포함하는 객체입니다. 여기에 필요한 환경 변수를 입력합니다.
workingDirectory : pnpm dlx 또는 글로벌 설치를 통해 게시된 패키지를 사용할 때는 일반적으로 필요하지 않습니다. 패키지가 자체 경로를 올바르게 처리해야 하기 때문입니다. 소스( node dist/index.js )에서 실행하는 경우 workingDirectory 프로젝트 루트로 설정하는 것이 중요합니다.
Get the chain ID for a given chain name
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | The chain name to get the ID for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, side effects, or rate limits. While the tool name suggests a read-only operation, the description does not explicitly confirm safety or other behavioral details.
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 concise sentence with no unnecessary words. It is front-loaded with the verb and clearly states the purpose, earning full marks for efficiency.
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 (single parameter, no output schema), the description is adequate but could be improved by explaining what the chain ID is or the format of the return value. It is minimally complete.
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 'chain' already described. The description adds minimal additional meaning beyond the schema, so it meets the baseline but does not 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 verb 'Get', the resource 'chain ID', and the condition 'for a given chain name'. It effectively distinguishes itself from sibling tools like ODOS_GET_QUOTE and ODOS_SWAP, which serve different purposes.
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, nor does it mention any prerequisites or limitations. It is straightforward but lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quote for a swap or exchange operation
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
| fromToken | Yes | The token to swap from (address). | |
| toToken | Yes | The token to swap to (address). | |
| amount | Yes | The amount of tokens to swap, in wei. | |
| prettyFormat | No | Whether to pretty format the quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description gives no behavioral details beyond stating it gets a quote. There is no mention of side effects, authentication, rate limits, or whether the operation is read-only.
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 no wasted words. However, it could still include more useful information 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?
With no output schema, the description should explain what the tool returns (e.g., a quote object). It does not mention the return format, pagination, or error cases, 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 already documents all parameters. The description adds no additional meaning or context for the parameters, such as token address format or amount precision.
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 'Get a quote for a swap or exchange operation' clearly states the verb (Get), resource (quote), and context (swap/exchange). It distinguishes from sibling tools like ODOS_SWAP (which performs the swap) and ODOS_GET_CHAIN_ID (which retrieves chain ID).
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 siblings or alternatives. It does not mention that getting a quote is a prerequisite for swapping, nor does it advise against using it in certain contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a swap transaction
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | The blockchain network to execute the transaction on. uses fraxtal as default | fraxtal |
| fromToken | Yes | The token to swap from (address). | |
| toToken | Yes | The token to swap to (address). | |
| amount | Yes | The amount of tokens to swap, in wei. | |
| prettyFormat | No | Whether to pretty format the quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Execute a swap transaction' implies a write operation but does not disclose side effects, authorization needs (e.g., token approval), or error conditions, making it insufficiently transparent.
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 sentence, concise and front-loaded. It earns its place but could benefit from additional context without becoming 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 complexity (swap transaction with 5 parameters, no output schema), the description is incomplete. It omits critical details like expected output (transaction hash?), slippage parameters, or prerequisite approvals, leaving gaps for the 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?
Input schema covers 100% of parameters with descriptions (e.g., each token address, amount in wei). The description adds no new meaning, so baseline score of 3 is appropriate per guidelines.
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 'Execute a swap transaction' clearly states the verb and resource, distinguishing it from sibling tools like ODOS_GET_QUOTE which provides quotes. However, it lacks additional context about what a swap entails, slightly reducing clarity.
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 usage guidelines are provided. The description does not specify when to use this tool (e.g., after obtaining a quote) or when not to use it, leaving the agent without important context for correct invocation.
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.
v1.0.0ODOS_GET_CHAIN_IDODOS_GET_QUOTEODOS_SWAPScored across 3 tools
Each tool targets a distinct step in the swap process: chain ID lookup, quote retrieval, and execution. No ambiguity or overlap exists.
All tools use a consistent ODOS_ prefix followed by clear verb_noun patterns (GET_CHAIN_ID, GET_QUOTE, SWAP), making them predictable.
With 3 tools, the server is well-scoped for the core swap workflow without unnecessary bloat or deficiency.
The tools cover the essential swap steps but lack a token approval tool, which is commonly required for many swaps, creating a potential gap.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Multi-aggregator swap router for AI agents on Base. 10 bps fee. MCP-native, non-custodial.
A Model Context Protocol server for Wix AI tools
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco