このリポジトリには、Claude が Jupiter のスワップ API にアクセスできるようにする Model Context Protocol (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 以上)
クロードデスクトップアプリケーション
このリポジトリをクローンします:
git clone https://github.com/dcSpark/mcp-server-jupiter.git
cd mcp-server-jupiter依存関係をインストールします:
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
Linux: ~/.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.Claude は MCP サーバーを使用して、Jupiter の swap API と直接対話します。
MCP サーバーに新しいツールを追加するには:
src/tools.tsでツールを定義する
適切なハンドラーファイルにハンドラー関数を作成する
src/tools.tsのhandlersオブジェクトにハンドラーを追加します。
npm run buildマサチューセッツ工科大学
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.
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.
Solana tools over MCP: Jupiter swaps, SPL tokens, Metaplex NFTs, SNS domains, network stats.
