jupiter-mcp
Server Details
Jupiter - 4 tools for swap quotes, liquidity pools, and trading data
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- junct-bot/jupiter-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
4 toolsprogram_id_to_label_getBInspect
program-id-to-label — Returns a hash, which key is the program id and value is the label. This is used to help map error from transaction by identifying the fault program id. This can be used in conjunction with the excludeDexes or dexes parameter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains the return value structure (hash with program ID keys and label values) and the debugging purpose, but omits whether this is a read-only lookup, if the data is cached, rate limits, or whether the mapping is exhaustive.
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 three sentences and appropriately brief, but the first sentence partially restates the tool name and the third sentence introduces ambiguity by referencing parameters not present in the schema. The key information (hash structure and error-mapping purpose) is present but not optimally front-loaded.
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?
No output schema exists, so the description appropriately explains the return value (a hash with specific key-value semantics). However, given the lack of annotations and the debugging context, the description should specify data freshness, whether the mapping is complete, or if results are cacheable to aid agent decision-making.
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?
The input schema contains zero parameters. According to the rubric, zero-parameter tools receive a baseline score of 4. The description does not need to compensate for missing schema documentation, though it confusingly mentions parameters that belong to other tools rather than describing this tool's (empty) interface.
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 tool returns a hash mapping program IDs to labels and specifies the use case (identifying fault program IDs in transaction errors). However, it opens by restating the tool name ('program-id-to-label') rather than using a distinct verb phrase, and does not explicitly contrast its function with the swap/quote siblings.
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 confusingly references using this tool 'in conjunction with the `excludeDexes` or `dexes` parameter,' but the input schema has zero parameters. This implies a workflow with sibling tools (quote_get, swap_post) but fails to clarify whether this tool should be called before them, after errors occur, or how the mapping translates to those parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_getBInspect
quote — Request for a quote to be used in POST /swap Returns: { inputMint: string, inAmount: string, outputMint: string, ... }.
| Name | Required | Description | Default |
|---|---|---|---|
| dexes | No | - Multiple DEXes can be pass in by comma separating them - For example: `dexes=Raydium,Orca+V2,Meteora+DLMM` - If a DEX is indicated, the route will **only use** that DEX - Full list of DEXes here: https://lite-api.jup.ag/swap/v1/program-id-to-label | |
| amount | Yes | - Raw amount to swap (before decimals) - Input Amount if `SwapMode=ExactIn` - Output Amount if `SwapMode=ExactOut` | |
| swapMode | No | - ExactOut is for supporting use cases where you need an exact output amount - In the case of `ExactIn`, the slippage is on the output token - In the case of `ExactOut`, the slippage is on the input token - Not all AMMs support `ExactOut`: Currently only Orca Whirlpool, Raydium CLMM, Raydium CPMM - We do not recommend using `ExactOut` for most use cases | |
| inputMint | Yes | query parameter: inputMint (string) | |
| outputMint | Yes | query parameter: outputMint (string) | |
| maxAccounts | No | - Rough estimate of the max accounts to be used for the quote - Useful if composing your own transaction or to be more precise in resource accounting for better routes | |
| slippageBps | No | - Default: 50 - This is threshold denoted in basis points. - If exact in and output amount exceeds the threshold, then the swap transaction will fail. | |
| excludeDexes | No | - Multiple DEXes can be pass in by comma separating them - For example: `excludeDexes=Raydium,Orca+V2,Meteora+DLMM` - If a DEX is indicated, the route will **not use** that DEX - Full list of DEXes here: https://lite-api.jup.ag/swap/v1/program-id-to-label | |
| platformFeeBps | No | - Take fees in basis points - If `platformFeeBps` is passed in, the `feeAccount` in `/swap` must be passed as well | |
| dynamicSlippage | No | - No longer applicable, only required to pass in via `/swap` endpoint | |
| onlyDirectRoutes | No | - Direct route limits Jupiter routing to single hop routes only - This may result in worse routes | |
| instructionVersion | No | - The version of instruction to use in the swap program | |
| asLegacyTransaction | No | - Instead of using versioned transaction, this will use the legacy transaction | |
| restrictIntermediateTokens | No | - Restrict intermediate tokens within a route to a set of more stable tokens - This will help to reduce exposure to potential high slippage routes |
Tool Definition Quality
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. It compensates for the missing output schema by documenting the return fields ({inputMint, inAmount, outputMint, ...}), which is valuable. However, it omits critical trading-specific behaviors: quote expiration/timing, whether quotes are cached, rate limits, and the fact that this is a safe read-only operation with no on-chain effects.
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 compact (one sentence), but awkwardly structured with an em-dash separating the tautological 'quote' prefix from the actual definition, and the return value documentation is crammed at the end. While brief, the formatting is not front-loaded for optimal parsing, and the opening word wastes space.
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 (14 parameters, DEX/AMM domain, financial risk), the description is minimally adequate. It compensates for the lack of structured output schema by describing return values, but lacks domain context (e.g., explaining that this queries Jupiter's route aggregator across multiple DEXes) and safety context that would be expected for a trading tool with zero annotations.
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?
The input schema has 100% description coverage with detailed explanations for all 14 parameters (e.g., swapMode nuances, DEX filtering syntax). The description adds no parameter-specific guidance, but given the comprehensive schema, the baseline score of 3 is appropriate as no additional semantic clarification is strictly necessary.
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 it requests a quote for use in `POST /swap`, which identifies the core action and target resource. However, it opens with the tautological prefix 'quote —' that restates the tool name, and while it implies this is preparatory for the swap operation, it could more explicitly distinguish from sibling `swap_post` (execution) vs. `quote_get` (price discovery).
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?
It implies a workflow sequence by stating the quote is 'to be used in POST /swap', suggesting this should be called before the swap execution. However, it lacks explicit when-not-to-use guidance, doesn't clarify that this is a read-only estimation step versus the actual token transfer, and doesn't mention prerequisites like token account existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
swap_instructions_postAInspect
swap-instructions — Request for swap instructions that you can use from the quote you get from /quote Returns: { otherInstructions: { programId: string, accounts: unknown[], data: string }[], computeBudgetInstructions: { programId: string, accounts: unknown[], data: string }[], setupInstructions: { programId: string, accounts: unknown[], data: string }[], ... }.
| Name | Required | Description | Default |
|---|---|---|---|
| payer | No | - Allow a custom payer to pay for the transaction fees and rent of token accounts - Note that users can close their ATAs elsewhere and have you reopen them again, your fees should account for this | |
| feeAccount | No | - An initialized token account that will be used to collect fees - The mint of the token account **can only be either the input or output mint of the swap** - Swap API no longer requires the use of the Referral Program - If `platformFeeBps` is passed in `/quote`, the `feeAccount` must be passed as well | |
| quoteResponse | Yes | quoteResponse ({ inputMint: string, inAmount: string, outputMint: string, outAmount: string, otherAmountThreshold: string, instructionVersion: "V1" | "V2", ... }) | |
| userPublicKey | Yes | userPublicKey (string) | |
| dynamicSlippage | No | - When enabled, it estimates slippage and apply it in the swap transaction directly, overwriting the `slippageBps` parameter in the quote response. - This is no longer maintained, we are focusing efforts on RTSE on Ultra Swap API | |
| trackingAccount | No | - Specify any public key that belongs to you to track the transactions - Useful for integrators to get all the swap transactions from this public key - Query the data using a block explorer like Solscan/SolanaFM or query like Dune/Flipside | |
| wrapAndUnwrapSol | No | - To automatically wrap/unwrap SOL in the transaction, as WSOL is an SPL token while native SOL is not - When true and input mint is SOL, it will wrap the SOL amount to WSOL and swap - When true and output mint is SOL, it will unwrap the WSOL back to SOL - When false and input mint is SOL, it will use existing WSOL amount to swap - When false and output mint is SOL, it will not unwrap the WSOL to SOL - To set this parameter to false, you need to have the WSOL token account initialized | |
| useSharedAccounts | No | - The default is determined dynamically by the routing engine, allowing us to optimize for compute units, etc - This enables the usage of shared program accounts, this is essential as complex routing will require multiple intermediate token accounts which the user might not have - If true, you do not need to handle the creation of intermediate token accounts for the user - Do note, shared accounts route will fail on some new AMMs (low liquidity token) | |
| asLegacyTransaction | No | - Builds a legacy transaction rather than the default versioned transaction - Used together with `asLegacyTransaction` in `/quote`, otherwise the transaction might be too large | |
| blockhashSlotsToExpiry | No | - Pass in the number of slots we want the transaction to be valid for - Example: If you pass in 10 slots, the transaction will be valid for ~400ms * 10 = approximately 4 seconds before it expires | |
| destinationTokenAccount | No | - Public key of a token account that will be used to receive the token out of the swap - If not provided, the signer's token account will be used - If provided, we assume that the token account is already initialized - `destinationTokenAccount` and `nativeDestinationAccount` are mutually exclusive | |
| dynamicComputeUnitLimit | No | - When enabled, it will do a swap simulation to get the compute unit used and set it in ComputeBudget's compute unit limit - This incurs one extra RPC call to simulate this - We recommend to enable this to estimate compute unit correctly and reduce priority fees needed or have higher chance to be included in a block | |
| nativeDestinationAccount | No | - Public key of an account that will be used to receive the native SOL token out of the swap - If not provided, the swap will default unwrap the WSOL and transfer the native SOL to the swap authority account - If provided, we will unwrap the WSOL and transfer the native SOL to the account - Only works if the output mint is SOL, is using the V2 instructions and the account passed in is not owned by token program - When sending native SOL to a new account, you must swap at least enough to cover the rent required to create it. - `destinationTokenAccount` and `nativeDestinationAccount` are mutually exclusive | |
| skipUserAccountsRpcCalls | No | - When enabled, it will not do any additional RPC calls to check on required accounts - The returned swap transaction will still attempt to create required accounts regardless if it exists or not | |
| prioritizationFeeLamports | No | - To specify a level or amount of additional fees to prioritize the transaction - It can be used for EITHER priority fee OR Jito tip (not both at the same time) - If you want to include both, you will need to use `/swap-instructions` to add both at the same time - Defaults to `auto`, but preferred to use `priorityLevelWithMaxLamports` as it may be more accurate when accounting local fee market - Fixed lamports can be passed in as an integer in the `prioritizationFeeLamports` parameter | |
| computeUnitPriceMicroLamports | No | - To use an exact compute unit price to calculate priority fee - `computeUnitLimit (1400000) * computeUnitPriceMicroLamports` - We recommend using `prioritizationFeeLamports` and `dynamicComputeUnitLimit` instead of passing in your own compute unit price |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses the return structure (otherInstructions, computeBudgetInstructions, setupInstructions) inline since no output schema exists. However, it omits critical behavioral traits such as whether this is a read-only operation, idempotency, error conditions, or side effects.
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 efficiently packs purpose, prerequisite, and return type documentation into a single dense sentence. While the leading 'swap-instructions' is redundant with the tool name and the return type JSON is somewhat verbose, every clause serves a necessary function without extraneous fluff.
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 absence of an output schema, the description adequately compensates by documenting the complex nested return structure containing instruction arrays. For a 16-parameter tool with complete schema documentation, the description successfully covers the high-level workflow and dependency on `quote_get`.
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?
The input schema has 100% description coverage, establishing a baseline where the description need not repeat parameter details. The description adds minimal semantic value beyond the schema, though it does provide useful context that `quoteResponse` comes from the `/quote` endpoint. This meets but does not exceed expectations for high-coverage schemas.
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 it makes a 'Request for swap instructions' and identifies the resource (instructions derived from a quote). It distinguishes from sibling `quote_get` by referencing `/quote` as a prerequisite source, and implies distinction from `swap_post` by focusing on retrieving instructions rather than executing. However, the prefix 'swap-instructions' redundantly restates the tool name rather than adding value.
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 clear sequencing guidance by stating the instructions come 'from the quote you get from `/quote`', establishing that `quote_get` must be called first. However, it lacks explicit comparison to sibling `swap_post` (which likely executes the swap directly) and does not specify when to prefer instructions over direct execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
swap_postBInspect
swap — Request for a base64-encoded unsigned swap transaction based on the /quote response Returns: { swapTransaction: string, lastValidBlockHeight: number, prioritizationFeeLamports: number }.
| Name | Required | Description | Default |
|---|---|---|---|
| payer | No | - Allow a custom payer to pay for the transaction fees and rent of token accounts - Note that users can close their ATAs elsewhere and have you reopen them again, your fees should account for this | |
| feeAccount | No | - An initialized token account that will be used to collect fees - The mint of the token account **can only be either the input or output mint of the swap** - Swap API no longer requires the use of the Referral Program - If `platformFeeBps` is passed in `/quote`, the `feeAccount` must be passed as well | |
| quoteResponse | Yes | quoteResponse ({ inputMint: string, inAmount: string, outputMint: string, outAmount: string, otherAmountThreshold: string, instructionVersion: "V1" | "V2", ... }) | |
| userPublicKey | Yes | userPublicKey (string) | |
| dynamicSlippage | No | - When enabled, it estimates slippage and apply it in the swap transaction directly, overwriting the `slippageBps` parameter in the quote response. - This is no longer maintained, we are focusing efforts on RTSE on Ultra Swap API | |
| trackingAccount | No | - Specify any public key that belongs to you to track the transactions - Useful for integrators to get all the swap transactions from this public key - Query the data using a block explorer like Solscan/SolanaFM or query like Dune/Flipside | |
| wrapAndUnwrapSol | No | - To automatically wrap/unwrap SOL in the transaction, as WSOL is an SPL token while native SOL is not - When true and input mint is SOL, it will wrap the SOL amount to WSOL and swap - When true and output mint is SOL, it will unwrap the WSOL back to SOL - When false and input mint is SOL, it will use existing WSOL amount to swap - When false and output mint is SOL, it will not unwrap the WSOL to SOL - To set this parameter to false, you need to have the WSOL token account initialized | |
| useSharedAccounts | No | - The default is determined dynamically by the routing engine, allowing us to optimize for compute units, etc - This enables the usage of shared program accounts, this is essential as complex routing will require multiple intermediate token accounts which the user might not have - If true, you do not need to handle the creation of intermediate token accounts for the user - Do note, shared accounts route will fail on some new AMMs (low liquidity token) | |
| asLegacyTransaction | No | - Builds a legacy transaction rather than the default versioned transaction - Used together with `asLegacyTransaction` in `/quote`, otherwise the transaction might be too large | |
| blockhashSlotsToExpiry | No | - Pass in the number of slots we want the transaction to be valid for - Example: If you pass in 10 slots, the transaction will be valid for ~400ms * 10 = approximately 4 seconds before it expires | |
| destinationTokenAccount | No | - Public key of a token account that will be used to receive the token out of the swap - If not provided, the signer's token account will be used - If provided, we assume that the token account is already initialized - `destinationTokenAccount` and `nativeDestinationAccount` are mutually exclusive | |
| dynamicComputeUnitLimit | No | - When enabled, it will do a swap simulation to get the compute unit used and set it in ComputeBudget's compute unit limit - This incurs one extra RPC call to simulate this - We recommend to enable this to estimate compute unit correctly and reduce priority fees needed or have higher chance to be included in a block | |
| nativeDestinationAccount | No | - Public key of an account that will be used to receive the native SOL token out of the swap - If not provided, the swap will default unwrap the WSOL and transfer the native SOL to the swap authority account - If provided, we will unwrap the WSOL and transfer the native SOL to the account - Only works if the output mint is SOL, is using the V2 instructions and the account passed in is not owned by token program - When sending native SOL to a new account, you must swap at least enough to cover the rent required to create it. - `destinationTokenAccount` and `nativeDestinationAccount` are mutually exclusive | |
| skipUserAccountsRpcCalls | No | - When enabled, it will not do any additional RPC calls to check on required accounts - The returned swap transaction will still attempt to create required accounts regardless if it exists or not | |
| prioritizationFeeLamports | No | - To specify a level or amount of additional fees to prioritize the transaction - It can be used for EITHER priority fee OR Jito tip (not both at the same time) - If you want to include both, you will need to use `/swap-instructions` to add both at the same time - Defaults to `auto`, but preferred to use `priorityLevelWithMaxLamports` as it may be more accurate when accounting local fee market - Fixed lamports can be passed in as an integer in the `prioritizationFeeLamports` parameter | |
| computeUnitPriceMicroLamports | No | - To use an exact compute unit price to calculate priority fee - `computeUnitLimit (1400000) * computeUnitPriceMicroLamports` - We recommend using `prioritizationFeeLamports` and `dynamicComputeUnitLimit` instead of passing in your own compute unit price |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adequately discloses the return structure (including specific fields like `lastValidBlockHeight`) and notes the transaction is 'unsigned' (implying the caller must sign). However, it fails to clarify that this is a safe, stateless preparation step that does not execute the swap on-chain or modify any account states.
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 compact but awkwardly structured, prefixing with 'swap —' which redundantly restates the tool name, then cramming the return schema into the same sentence. While the return information is valuable given the lack of output schema, the formatting mixes description with specification.
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 high complexity (16 parameters, nested objects) and lack of annotations, the description compensates partially by providing the return structure inline. However, it misses critical workflow context: it does not explain the full lifecycle (quote → swap_post → sign → send) or the relationship to `swap_instructions_post`, which is essential for correct tool selection in a DeFi context.
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?
The input schema has 100% description coverage, documenting all 16 parameters extensively. The description adds minimal semantic detail beyond the schema itself, only contextualizing that `quoteResponse` comes from the `/quote` endpoint. With complete schema coverage, this meets the baseline expectation.
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 specifies the core action ('Request for a base64-encoded unsigned swap transaction') and identifies the required input ('based on the `/quote` response'). However, it does not explicitly distinguish when to use this tool versus the sibling `swap_instructions_post` tool, leaving the agent to infer based on return type differences.
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 implies a workflow dependency on `/quote` by stating it requires the quote response. However, it lacks explicit guidance on when to use this transaction-building tool versus the `swap_instructions_post` alternative, and does not mention that the returned transaction requires subsequent signing and submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!