Este repositorio contiene un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona a Claude acceso a la API de swap de Jupiter. El servidor le permite realizar operaciones como obtener cotizaciones, crear y enviar transacciones de swap en la blockchain de Solana mediante Jupiter.
El servidor MCP expone varias herramientas a Claude:
jupiter_get_quote : Obtenga una cotización para intercambiar tokens en Jupiter
jupiter_build_swap_transaction : Crea una transacción de intercambio en Júpiter
jupiter_send_swap_transaction : Envía una transacción de intercambio en Júpiter
Related MCP server: Solana Agent Kit MCP Server
Node.js (v16 o superior)
Aplicación de escritorio Claude
Clonar este repositorio:
git clone https://github.com/dcSpark/mcp-server-jupiter.git
cd mcp-server-jupiterInstalar dependencias:
npm ciConstruir el proyecto:
npm run buildTambién puedes instalar el paquete globalmente o usarlo directamente con npx:
# Install globally
npm install -g @mcp-dockmaster/mcp-server-jupiter
# Or use directly with npx
npx @mcp-dockmaster/mcp-server-jupiterPara configurar Claude Desktop para utilizar este servidor MCP:
Abra Claude Desktop
Navegue hasta el archivo de configuración de Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Agregue la configuración del servidor MCP:
{
"mcpServers": {
"mcp-server-jupiter": {
"command": "node",
"args": [
"/path/to/your/mcp-server-jupiter/build/index.js"
]
}
}
}Si ha instalado el paquete globalmente o desea utilizar npx, puede configurarlo de esta manera:
{
"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-jupiterUna vez configurado, reinicie Claude Desktop. Claude ahora tendrá acceso a las herramientas de intercambio de Jupiter. Puede pedirle a Claude que:
Obtenga una cotización para intercambiar tokens:
What's the quote for swapping 1 SOL to USDC?Crear una transacción de swap:
Build a swap transaction for the quote I just got.Enviar una transacción de swap:
Send the swap transaction I just built.Claude utilizará el servidor MCP para interactuar directamente con la API de intercambio de Júpiter.
Para agregar nuevas herramientas al servidor MCP:
Define la herramienta en src/tools.ts
Cree una función de controlador en el archivo de controlador apropiado
Agregue el controlador al objeto de handlers en src/tools.ts
npm run buildInstituto Tecnológico de Massachusetts (MIT)
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.
