이 저장소에는 Claude가 Jupiter의 스왑 API에 접근할 수 있도록 하는 모델 컨텍스트 프로토콜(MCP) 서버가 포함되어 있습니다. 이 서버를 통해 Claude는 Jupiter를 사용하여 Solana 블록체인에서 시세 조회, 스왑 거래 생성, 스왑 거래 전송 등의 작업을 수행할 수 있습니다.
MCP 서버는 Claude에게 여러 도구를 제공합니다.
jupiter_get_quote : Jupiter에서 토큰 교환에 대한 견적을 받으세요
jupiter_build_swap_transaction : Jupiter에서 스왑 트랜잭션을 빌드합니다.
jupiter_send_swap_transaction : Jupiter에서 스왑 트랜잭션을 보냅니다.
Related MCP server: Solana Agent Kit MCP Server
Node.js(v16 이상)
클로드 데스크톱 애플리케이션
이 저장소를 복제하세요:
지엑스피1
종속성 설치:
npm ci프로젝트를 빌드하세요:
npm run build패키지를 글로벌하게 설치하거나 npx와 함께 직접 사용할 수도 있습니다.
# Install globally
npm install -g @mcp-dockmaster/mcp-server-jupiter
# Or use directly with npx
npx @mcp-dockmaster/mcp-server-jupiter이 MCP 서버를 사용하도록 Claude Desktop을 구성하려면:
클로드 데스크톱 열기
Claude Desktop 구성 파일로 이동합니다.
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
리눅스: ~/.config/Claude/claude_desktop_config.json
MCP 서버 구성을 추가합니다.
{
"mcpServers": {
"mcp-server-jupiter": {
"command": "node",
"args": [
"/path/to/your/mcp-server-jupiter/build/index.js"
]
}
}
}패키지를 글로벌하게 설치했거나 npx를 사용하려는 경우 다음과 같이 구성할 수 있습니다.
{
"mcpServers": {
"mcp-server-jupiter": {
"command": "npx",
"args": [
"@mcp-dockmaster/mcp-server-jupiter"
]
}
}
}# If installed locally
node build/index.js
# If installed globally
mcp-server-jupiter
# Using npx
npx @mcp-dockmaster/mcp-server-jupiter구성이 완료되면 Claude Desktop을 다시 시작하세요. 이제 Claude가 Jupiter 스왑 도구에 접근할 수 있습니다. Claude에게 다음 작업을 요청할 수 있습니다.
토큰 교환에 대한 견적을 받으세요:
What's the quote for swapping 1 SOL to USDC?스왑 거래 구축:
Build a swap transaction for the quote I just got.스왑 거래 보내기:
Send the swap transaction I just built.클로드는 MCP 서버를 사용하여 Jupiter의 스왑 API와 직접 상호 작용합니다.
MCP 서버에 새로운 도구를 추가하려면:
src/tools.ts 에 도구를 정의하세요
적절한 핸들러 파일에 핸들러 함수를 생성합니다.
src/tools.ts 의 handlers 객체에 핸들러를 추가합니다.
npm run buildMIT
Build a swap transaction on Jupiter
| Name | Required | Description | Default |
|---|---|---|---|
| quoteResponse | Yes | ||
| userPublicKey | Yes | ||
| prioritizationFeeLamports | No | ||
| computeUnitPriceMicroLamports | No | ||
| asLegacyTransaction | No |
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 but fails to do so. It does not explain if this is a read-only or mutative operation, what permissions or authentication are needed, potential side effects, or any rate limits, making it inadequate for a tool with transactional implications.
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, straightforward sentence with no wasted words, making it highly concise and front-loaded. It efficiently states the core action without unnecessary elaboration.
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 swap transaction tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It lacks essential details on behavior, parameters, usage context, and expected outcomes, failing to provide adequate guidance for 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?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no meaning beyond the tool name, failing to explain what parameters like 'quoteResponse' or 'userPublicKey' represent, their formats, or how they influence the transaction build process.
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 states the action ('Build') and resource ('a swap transaction on Jupiter'), which provides a basic purpose. However, it lacks specificity about what 'build' entails (e.g., creating a transaction object vs. executing it) and does not distinguish it from sibling tools like 'jupiter_send_swap_transaction', making it vague in context.
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 does not mention prerequisites (e.g., needing a quote from 'jupiter_get_quote'), exclusions, or contextual cues for selection among siblings, leaving the agent without usage direction.
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 swapping tokens on Jupiter
| Name | Required | Description | Default |
|---|---|---|---|
| inputMint | Yes | ||
| outputMint | Yes | ||
| amount | Yes | ||
| slippageBps | No | ||
| onlyDirectRoutes | No | ||
| asLegacyTransaction | No | ||
| maxAccounts | No | ||
| swapMode | No | ||
| excludeDexes | No | ||
| platformFeeBps | No |
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 but fails to do so. It doesn't indicate whether this is a read-only operation, if it has side effects, rate limits, authentication needs, or what the output entails, making it inadequate for a tool with 10 parameters and no output schema.
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, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
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 (10 parameters, no annotations, no output schema), the description is severely incomplete. It lacks essential details about behavior, parameter meanings, and output expectations, making it insufficient for an agent to use the tool effectively in a multi-step swap process with siblings.
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 0%, meaning none of the 10 parameters are documented in the schema. The description adds no semantic information about any parameters, such as explaining what 'inputMint', 'slippageBps', or other fields mean, failing to compensate for the lack of schema documentation.
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' and the resource 'a quote for swapping tokens on Jupiter', which specifies the action and domain. However, it doesn't explicitly differentiate from its sibling tools (jupiter_build_swap_transaction and jupiter_send_swap_transaction), which likely handle subsequent steps in the swap process, so it falls short of 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?
The description provides no guidance on when to use this tool versus its siblings. It doesn't mention prerequisites, alternatives, or contextual cues, leaving the agent to infer usage based on tool names alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a swap transaction on Jupiter
| Name | Required | Description | Default |
|---|---|---|---|
| swapTransaction | No | ||
| serializedTransaction | No | ||
| skipPreflight | No | ||
| maxRetries | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Send a swap transaction' implies a write/mutation operation that likely requires authentication and affects blockchain state, but the description doesn't mention permission requirements, transaction finality, error handling, or what happens on success/failure. It provides minimal behavioral context beyond the basic action.
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 extremely concise - a single 5-word sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it efficiently front-loaded with the core action.
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?
For a transaction-sending tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, how parameters interact (e.g., relationship between swapTransaction and serializedTransaction), error conditions, or the broader swap workflow context with sibling tools.
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 0% schema description coverage for all 4 parameters, the description provides no information about what 'swapTransaction', 'serializedTransaction', 'skipPreflight', or 'maxRetries' mean or how they should be used. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving all parameters semantically undefined.
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 'Send a swap transaction on Jupiter' clearly states the action (send) and resource (swap transaction) with the platform context (Jupiter). However, it doesn't differentiate from sibling tools like 'jupiter_build_swap_transaction' or 'jupiter_get_quote' - it's unclear if this tool executes a pre-built transaction or handles the entire swap flow.
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 about when to use this tool versus the siblings. The description doesn't indicate if this should be used after building a transaction with 'jupiter_build_swap_transaction' or as an alternative to it, nor does it mention any prerequisites or contextual constraints for usage.
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.
jupiter_build_swap_transactionjupiter_get_quotejupiter_send_swap_transactionScored across 3 tools
Each tool has a clearly distinct purpose in the swap workflow: get_quote for pricing, build_swap_transaction for constructing the transaction, and send_swap_transaction for execution. There is no overlap or ambiguity between these three steps.
All tools follow a consistent 'jupiter_verb_noun' pattern with snake_case, using descriptive verbs (get, build, send) that clearly indicate the action. The naming is predictable and uniform throughout the set.
With 3 tools, this server is well-scoped for its purpose of facilitating token swaps on Jupiter. Each tool serves a distinct and essential function in the swap process, making the count appropriate and efficient.
The tool set provides complete coverage for the core swap workflow: getting a quote, building the transaction, and sending it. There are no obvious gaps for this focused domain, ensuring agents can perform swaps end-to-end without dead ends.
Keyless Solana swap quotes (Jupiter) and token facts, with a link the human signs. No keys.
Jupiter - 4 tools for swap quotes, liquidity pools, and trading data
Solana Jupiter quotes and package preflight for AI agents. Free sample. Paid x402 on Solana USDC.
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
