The MCP Jupiter server enables Claude to interact with Jupiter's swap API on the Solana blockchain for token swaps. You can:
Get Quotes: Retrieve quotes for swapping tokens using jupiter_get_quote
Build Swap Transactions: Create swap transactions using a quote response and user public key via jupiter_build_swap_transaction
Send Swap Transactions: Execute swap transactions with customizable options through jupiter_send_swap_transaction
Enables performing operations on the Solana blockchain, specifically for executing token swaps through Jupiter's swap API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Jupiter get a quote for swapping 0.5 SOL to USDC"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This repository contains a Model Context Protocol (MCP) server that provides Claude with access to Jupiter's swap API. The server enables Claude to perform operations like getting quotes, building swap transactions, and sending swap transactions on the Solana blockchain using Jupiter.
The MCP server exposes several tools to Claude:
jupiter_get_quote: Get a quote for swapping tokens on Jupiter
jupiter_build_swap_transaction: Build a swap transaction on Jupiter
jupiter_send_swap_transaction: Send a swap transaction on Jupiter
Related MCP server: Solana Agent Kit MCP Server
Node.js (v16 or higher)
Claude Desktop application
Clone this repository:
git clone https://github.com/dcSpark/mcp-server-jupiter.git
cd mcp-server-jupiterInstall dependencies:
npm ciBuild the project:
npm run buildYou can also install the package globally or use it directly with npx:
# Install globally
npm install -g @mcp-dockmaster/mcp-server-jupiter
# Or use directly with npx
npx @mcp-dockmaster/mcp-server-jupiterTo configure Claude Desktop to use this MCP server:
Open Claude Desktop
Navigate to the Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add the MCP server configuration:
{
"mcpServers": {
"mcp-server-jupiter": {
"command": "node",
"args": [
"/path/to/your/mcp-server-jupiter/build/index.js"
]
}
}
}If you've installed the package globally or want to use npx, you can configure it like this:
{
"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-jupiterOnce configured, restart Claude Desktop. Claude will now have access to the Jupiter swap tools. You can ask Claude to:
Get a quote for swapping tokens:
What's the quote for swapping 1 SOL to USDC?Build a swap transaction:
Build a swap transaction for the quote I just got.Send a swap transaction:
Send the swap transaction I just built.Claude will use the MCP server to interact with Jupiter's swap API directly.
To add new tools to the MCP server:
Define the tool in src/tools.ts
Create a handler function in the appropriate handler file
Add the handler to the handlers object in src/tools.ts
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. Dates show when Glama detected each change.
jupiter_build_swap_transactionjupiter_get_quotejupiter_send_swap_transactionEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dcSpark/mcp-server-jupiter'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
