此代码库包含一个模型上下文协议 (MCP) 服务器，该服务器为 Claude 提供了访问 Jupiter 掉期 API 的权限。该服务器使 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 或更高版本）
Claude桌面应用程序
克隆此存储库：
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要配置 Claude Desktop 以使用此 MCP 服务器：
打开 Claude 桌面
导航到 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 的交换 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.
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.
