Provides access to Jupiter's full DeFi stack on Solana, enabling AI agents to perform swaps, check token prices, manage lending positions, create limit/DCA orders, access prediction markets, trade perpetual futures, and view portfolios across Jupiter products.
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., "@jupiter-mcp get me a quote to swap 0.5 SOL for 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.
MCP server for the Jupiter Developer Platform — 17 tools covering swap, tokens, price, lend, limit orders, DCA, prediction markets, perps, and portfolio.
Any MCP-compatible AI agent (Claude Code, Cursor, ChatGPT, etc.) gets native access to Jupiter's full DeFi stack on Solana.
# Install
git clone https://github.com/ExpertVagabond/jupiter-mcp.git
cd jupiter-mcp
npm install && npm run build
# Run (keyless — 0.5 RPS, no signup needed)
node dist/index.js
# Run with API key (higher rate limits)
JUPITER_API_KEY=your_key node dist/index.js// ~/.claude/settings.json
{
"mcpServers": {
"jupiter": {
"command": "node",
"args": ["/path/to/jupiter-mcp/dist/index.js"],
"env": {
"JUPITER_API_KEY": "your_key_or_omit_for_keyless"
}
}
}
}Related MCP server: Stacks AI MCP Server
Tool | Description |
| Get swap quote via managed /order path (all routers compete) |
| Get raw swap instructions for custom transactions |
| Search tokens by name, symbol, or mint |
| Token metadata, organic scores, trading metrics |
| USD prices for any Solana token |
| Create a lending deposit transaction |
| Create a lending withdrawal transaction |
| List open limit orders for a wallet |
| Create limit / OCO / OTOCO orders |
| Cancel open limit orders |
| List active DCA schedules |
| Create recurring DCA orders |
| Browse prediction markets (Polymarket, Kalshi) |
| List perpetual futures markets |
| Get open perp positions |
| Full portfolio view across all Jupiter products |
You: "What's the price of SOL and JUP?"
Agent calls: jupiter_price({ mints: "So11...112,JUPyi...vCN" })
→ SOL: $83.53 (-2.4% 24h), JUP: $0.166You: "Get me a quote to swap 1 SOL for USDC"
Agent calls: jupiter_swap_quote({
inputMint: "So11111111111111111111111111111111111111112",
outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
amount: "1000000000",
taker: "your_wallet"
})
→ 83.48 USDC, 22bps slippage, aggregator routing via Raydiumsrc/
index.ts MCP server entry — registers all tools
client.ts Jupiter API client (thin fetch wrapper, no dependencies)
types.ts Shared types
tools/
swap.ts Swap V2 (/order + /build)
tokens.ts Token search + metadata
price.ts USD pricing
lend.ts Lending deposit/withdraw
trigger.ts Limit orders (create/cancel/list)
recurring.ts DCA orders
prediction.ts Prediction markets
perps.ts Perpetual futures
portfolio.ts Portfolio aggregationSee DX-REPORT.md for a detailed developer experience report covering every Jupiter API, the AI stack (llms.txt, Agent Skills, CLI, Docs MCP), and specific recommendations.
MIT
Create a DCA order — recurring swap on a schedule. Returns transaction to sign. Example: buy $10 SOL every hour.
| Name | Required | Description | Default |
|---|---|---|---|
| inputMint | Yes | Mint of token to spend (e.g. USDC) | |
| outputMint | Yes | Mint of token to accumulate (e.g. SOL) | |
| inAmount | Yes | Total amount to spend over DCA period (base units) | |
| inAmountPerCycle | Yes | Amount per cycle (base units) | |
| cycleSecondsApart | Yes | Seconds between cycles (3600 = hourly) | |
| maker | Yes | Wallet address | |
| minOutAmountPerCycle | No | Min output per cycle (slippage protection) | |
| maxOutAmountPerCycle | No | Max output per cycle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It correctly indicates the tool returns a transaction to sign, implying the agent must handle signing and submission. However, it does not disclose whether the transaction requires further steps, permissions, or the effect on existing orders. The example is helpful but lacks depth.
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: two sentences and an example. Every word is relevant, and the example improves understanding without adding clutter. It is well-structured and 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?
For a tool that creates a DCA order returning a transaction to sign, the description covers the basic purpose and output. However, it does not explain the signing workflow, error conditions, or what happens after the transaction is signed. Given no output schema, more context would be beneficial.
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 100%, so the baseline is 3. The description adds a concrete example but fails to clarify the relationship between inAmount (total) and inAmountPerCycle (per cycle), which could lead to incorrect usage. The example uses $10 every hour without specifying the total amount, leaving ambiguity.
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 creates a DCA order (recurring swap) and returns a transaction to sign. The example 'buy $10 SOL every hour' concretely illustrates the purpose. It distinguishes from sibling tools like single swaps (jupiter_swap_build) or limit orders.
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 usage for recurring schedules but does not explicitly state when to use this tool versus alternatives (e.g., limit orders or single swaps). No guidance is given on when not to use it or prerequisites such as wallet authorization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active DCA (Dollar Cost Average) orders for a wallet — recurring schedules and progress.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions 'Get', implying a read operation, but does not disclose any behavioral traits such as authentication needs, error behavior, or whether it returns empty results. This is minimal disclosure.
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, compact sentence (13 words) that effectively communicates the tool's purpose. Every word earns its place, and the main action is 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?
For a simple retrieval tool with one parameter and no output schema, the description provides sufficient context about what the tool does (get DCA orders). It lacks detail on return format or edge cases, but it is generally complete for its complexity.
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 covers 100% of parameters with a description for 'wallet'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 'active DCA orders for a wallet', and adds 'recurring schedules and progress' to elaborate. This distinguishes it from sibling tools like jupiter_limit_orders, which retrieve limit orders instead.
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 does not provide any guidance on when to use this tool versus alternatives. No exclusions or context are given, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deposit transaction for Jupiter Lend Earn. Returns a base64-encoded unsigned transaction to sign and submit.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Token mint address to deposit (e.g. USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v) | |
| signer | Yes | Wallet address making the deposit | |
| amount | Yes | Amount to deposit in base units |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the output (unsigned transaction) implying it's a create-and-sign operation, but does not detail potential side effects, failure modes, or required permissions. This is adequate but not thorough.
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 concise two-sentence structure. Every word adds value, with no superfluous content. Front-loading the action and output is effective.
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 tool's simplicity (3 parameters, no output schema), the description covers the core purpose and output. It could mention that the returned transaction needs to be submitted separately, but the overall completeness is high for this use case.
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 100%, so the schema itself fully documents the parameters. The description adds no extra semantics beyond what is already in the schema, meeting 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 clearly states the action (Create a deposit transaction), the target (Jupiter Lend Earn), and the output (base64-encoded unsigned transaction). This clearly distinguishes it from siblings like jupiter_lend_withdraw or jupiter_swap_build.
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 on when to use this tool versus alternatives. It does not mention scenarios where other tools would be more appropriate, nor does it provide context about prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a withdraw transaction for Jupiter Lend Earn. Returns a base64-encoded unsigned transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Token mint address to withdraw | |
| signer | Yes | Wallet address | |
| amount | Yes | Amount to withdraw in base units |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description carries full burden. It discloses that the tool creates an unsigned transaction and returns it base64-encoded, which is useful behavioral info. However, it does not cover side effects, permissions, or other traits, leaving gaps.
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, concise sentence with no unnecessary words. It efficiently conveys the essential purpose and output format.
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 simple tool with three parameters and no output schema, the description covers the core action and return type. It lacks details on the broader withdraw process (e.g., pool interaction, signing), but matches the complexity level adequately.
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 coverage is 100% with each parameter having a description. The tool description adds no further parameter details beyond what the schema provides, so baseline of 3 is appropriate.
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 creates a withdraw transaction for Jupiter Lend Earn and returns a base64-encoded unsigned transaction. The verb 'withdraw' effectively distinguishes it from sibling tool 'jupiter_lend_deposit' (deposit).
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, nor are there any prerequisites or exclusion conditions mentioned. The description only implies usage for withdrawals but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel one or more open limit orders.
| Name | Required | Description | Default |
|---|---|---|---|
| maker | Yes | Wallet that created the orders | |
| orders | Yes | Order public keys to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects (e.g., irreversible), partial success, or auth requirements. Minimal behavioral info 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?
Single sentence, no fluff. Front-loaded with verb and resource.
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 or description of return value. Lacks info on error handling, idempotency, or success indicators. For a tool with no annotations, more context needed.
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 coverage is 100%, so description adds no extra meaning. Repeats order public keys but no additional detail on format or constraints.
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?
Description uses specific verb 'cancel' and resource 'open limit orders'. Clearly distinguishes from sibling tools like 'jupiter_limit_order_create' (create) and 'jupiter_limit_orders' (list).
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 explicit guidance on when to cancel vs modify or other alternatives. For a simple tool, the context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a limit order. Returns a transaction to sign. Supports single, OCO (TP/SL), and OTOCO orders.
| Name | Required | Description | Default |
|---|---|---|---|
| inputMint | Yes | Mint of token to sell | |
| outputMint | Yes | Mint of token to buy | |
| inAmount | Yes | Amount to sell in base units | |
| outAmount | Yes | Min amount to receive (sets limit price) | |
| maker | Yes | Wallet address creating the order | |
| expiredAt | No | ISO 8601 expiration time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that the tool 'Returns a transaction to sign,' which reveals a key behavioral trait: it does not execute the order directly. With no annotations provided, this is helpful but lacks elaboration on authorization, fees, 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?
Two sentences, no redundant information. Every word adds value. Front-loaded with the core action and outcome.
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?
The description covers the main purpose, order types, and the return value (transaction to sign). While it lacks details on submission requirements, the 6 parameters are fully documented in the schema. No output schema is expected, so the description is reasonably complete.
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?
All 6 parameters have descriptions in the input schema (100% coverage). The description adds no additional parameter details beyond the schema, so baseline 3 is appropriate.
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 action 'Create a limit order' and specifies that it supports single, OCO, and OTOCO orders. This distinguishes it from sibling tools like jupiter_limit_orders (list) and jupiter_limit_order_cancel (cancel).
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 mentions supported order types, giving context on when to use. However, it does not explicitly contrast with alternatives like jupiter_swap_build or jupiter_dca_create, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all open limit orders for a wallet — pending trigger orders with price targets and amounts.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the purpose without disclosing behavioral traits like pagination, rate limits, or prerequisites.
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?
Single sentence with a dash adding detail, no wasted words, 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?
Adequate for a simple tool, but lacks return value description (no output schema) and usage context beyond the core function.
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 covers the single parameter 'wallet' with description; the tool description adds no extra meaning beyond the schema.
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', the resource 'open limit orders', and the scope 'for a wallet', distinguishing it from sibling create/cancel tools.
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?
Implicitly suggests usage for viewing open orders, but no explicit when-to-use or when-not-to-use guidance, nor alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Jupiter perpetual futures markets — trading pairs, funding rates, open interest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a read-only listing operation but does not explicitly state that no mutations occur, or mention any rate limits, permissions, or data freshness. The basic purpose is clear, but deeper behavioral traits are missing.
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?
A single, front-loaded sentence that efficiently communicates the action (list), resource (markets), and key data fields. Every word serves a purpose with no redundancy.
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 simple parameterless listing tool, the description is largely complete. It identifies the three key data fields. However, it lacks information on sorting, pagination, or number of markets, but given the tool's simplicity, this is a minor gap.
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 tool has zero parameters with 100% schema coverage (empty schema). The description adds meaning by specifying the returned data includes trading pairs, funding rates, and open interest, which is valuable beyond the empty schema.
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 lists Jupiter perpetual futures markets with specific data fields (trading pairs, funding rates, open interest). It distinguishes from sibling tools like jupiter_perps_positions, which focus on positions rather than market overview.
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 explicit guidance on when to use this tool versus alternatives. The intended use is implied by the description, but there is no mention of when not to use it or alternatives like jupiter_perps_positions for position-specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get open perpetual positions for a wallet — leverage, entry price, PnL, liquidation price.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a read operation returning positions with specific fields, but does not disclose any additional behavioral traits such as authorization requirements, rate limits, or potential side effects. For a simple read tool without annotations, this is adequate but not exceptional.
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, concise sentence that clearly communicates the tool's purpose and the data it returns (leverage, entry price, PnL, liquidation price). No redundancy or unnecessary words.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description provides sufficient context. It lists the return fields, which compensates for the absence of an output schema. The description is complete for the tool's scope.
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 only parameter 'wallet' is already described in the input schema as 'Wallet address'. The description adds no additional semantic context beyond what the schema provides. Given 100% schema description coverage, a baseline score of 3 is appropriate.
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 open perpetual positions and lists key fields (leverage, entry price, PnL, liquidation price). This distinguishes it from siblings like jupiter_perps_markets (which lists markets) and jupiter_portfolio (broader portfolio info).
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 explicit guidance on when to use this tool versus alternatives like jupiter_portfolio or jupiter_perps_markets. The context implies use when needing open positions for a specific wallet, but no exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full portfolio for a wallet — all Jupiter positions across swaps, lending, DCA, limit orders, perps, and prediction markets.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states it is a retrieval operation but adds no detail on read-only nature, authentication needs, rate limits, or data freshness. Minimal beyond purpose.
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?
Single sentence, no filler, front-loads the action and scope. Every word contributes to the purpose.
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 no output schema and a single parameter, the description is adequate but lacks detail on the return format, field contents, or potential pagination. Could be more informative for a comprehensive tool.
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 schema already covers the 'wallet' parameter with a description. The description adds no additional meaning or usage guidance for the parameter, so baseline 3 applies.
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 uses a specific verb ('Get') and resource ('full portfolio') and explicitly lists the types of Jupiter positions included, which distinguishes it from the many sibling tools that focus on individual operations.
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 when to use (when needing a comprehensive overview), but does not provide explicit when-not or alternative tool recommendations. The context of sibling tools partially compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Jupiter prediction events — binary markets on real-world events. Filter by category, sort by volume or date, include market data.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Data source (default: polymarket) | |
| includeMarkets | No | Include market data in response | |
| category | No | Filter: all, crypto, sports, politics, esports, culture, economics, tech | |
| sortBy | No | Sort field | |
| sortDirection | No | Sort order | |
| filter | No | Named filter: new (24h), live (active), trending | |
| start | No | Pagination start index | |
| end | No | Pagination end index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the tool lists events and can include market data, but omits any mention of read-only behavior, authentication needs, rate limits, or side effects. This is insufficient for a tool with no annotations.
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 two sentences, front-loading the purpose and then listing key capabilities. Every word is justified, with no fluff or repetition.
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 tool has 8 parameters and no output schema, the description is adequate but incomplete. It does not explain pagination behavior, return format, or how filters interact. However, for a simple list tool, it covers the basics.
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% coverage with parameter descriptions. The tool description repeats some parameter info (category, sortBy, includeMarkets) but adds no new meaning beyond what is already in the schema. Baseline 3 is appropriate.
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 lists Jupiter prediction events, which are binary markets on real-world events. This distinguishes it from sibling tools focused on trading, lending, and swaps, making the purpose unambiguous.
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 usage for listing prediction events with filters and sorting, and the context of sibling tools makes when to use this tool clear. However, it does not explicitly state when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current USD prices for one or more Solana tokens. Pass mint addresses comma-separated.
| Name | Required | Description | Default |
|---|---|---|---|
| mints | Yes | Comma-separated mint addresses | |
| showExtraInfo | No | Include confidence, depth, and last swap time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'Get current USD prices' without addressing staleness, rate limits, or error behavior. This is insufficient for a price API.
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?
Two sentences with no waste. The essential action and input format are front-loaded. Every word earns its place.
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?
The tool lacks an output schema and annotations, so the description should compensate by explaining return format or common error cases. It does not, leaving the agent guessing about the response structure.
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 coverage is 100% and both parameters are described in the schema. The description adds no new semantic meaning beyond reinforcing the comma-separated format, which is already in the schema. Baseline 3 is appropriate.
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 gets current USD prices for Solana tokens, using a specific verb and resource. It distinguishes itself from sibling tools like jupiter_swap or jupiter_portfolio, which have different purposes.
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 basic usage instructions ('Pass mint addresses comma-separated') but does not explain when to prefer this tool over alternatives like jupiter_token_info, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw swap instructions for custom transaction construction. Use when composing Jupiter swaps with other instructions (flashloans, multi-step). Metis router only.
| Name | Required | Description | Default |
|---|---|---|---|
| inputMint | Yes | Mint address of token to sell | |
| outputMint | Yes | Mint address of token to buy | |
| amount | Yes | Amount in smallest unit | |
| taker | Yes | Wallet address | |
| slippageBps | No | Max slippage in basis points |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns raw instructions (non-executing) and limits to Metis router, but does not mention side effects, auth requirements, or error behavior. With no annotation support, more behavioral context is needed for safe invocation.
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?
Two sentences, no redundant information. The first sentence conveys the core purpose concisely; the second provides critical usage context. Well-structured for quick comprehension.
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 5 parameters, no output schema, and no annotations, the description is adequate but lacks details about return format (raw instructions), prerequisites (e.g., prior quote), and error handling. It provides essential usage guidance but leaves some gaps for a complex tool.
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 100%, so baseline is 3. The description does not add significant meaning beyond the parameter names and their inline descriptions. For example, 'amount' already says 'Amount in smallest unit' in schema; description adds no further detail.
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's verb ('Get raw swap instructions') and resource ('custom transaction construction'). It distinguishes itself from siblings by highlighting its use case for composing swaps with other instructions, and mentions 'Metis router only'.
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?
Explicitly states when to use: 'Use when composing Jupiter swaps with other instructions (flashloans, multi-step).' Also provides a specific constraint: 'Metis router only.' However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a swap quote via Jupiter's managed /order path. Returns the best price across all routers (Metis, RFQ, Dflow, OKX).
| Name | Required | Description | Default |
|---|---|---|---|
| inputMint | Yes | Mint address of token to sell (SOL: So11111111111111111111111111111111111111112) | |
| outputMint | Yes | Mint address of token to buy (USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v) | |
| amount | Yes | Amount in smallest unit (lamports). For 1 SOL: '1000000000' | |
| taker | Yes | Wallet address executing the swap | |
| slippageBps | No | Max slippage in basis points (default 50 = 0.5%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'Get a swap quote' and 'Returns the best price', which strongly implies a read-only operation without state changes. However, it could be more explicit about the lack of mutation and does not mention rate limits or error conditions.
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 two concise sentences with no redundant information. It front-loads the core purpose and adds an important detail about which routers are used, making it easy for an AI agent to quickly grasp the tool's function.
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?
While the description covers the core functionality and router selection, it lacks details about the output format (e.g., fields like price, route, fees) since no output schema is provided. This omission may require an agent to infer response structure from context. Overall, it is mostly complete for a quote tool.
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 already describes all 5 parameters with clear descriptions and examples (e.g., SOL and USDC addresses, lamports for amount). The description adds no additional information about parameter meaning or usage beyond what the schema provides.
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 retrieves a swap quote via Jupiter's managed /order path, specifying it returns the best price across multiple routers (Metis, RFQ, Dflow, OKX). This distinguishes it from related sibling tools like jupiter_swap_build (which builds/executes swaps) and jupiter_dca_create (for DCA orders).
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 use for obtaining a quote before building a swap, but does not explicitly state when to use this tool versus siblings such as jupiter_swap_build or jupiter_price. There is no guidance on prerequisites, order of operations, or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed token metadata for a specific mint — verification status, organic score, daily volume, holder count.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Token mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lists output fields but does not disclose side effects, auth requirements, rate limits, or error behavior. For a read operation, basic transparency is present but incomplete.
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?
Single sentence, 15 words, front-loaded with verb and resource. No wasted words. Structure is ideal for quick understanding.
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 low complexity (single param, no output schema) and no annotations, the description lists key output fields. Minor gaps: no error handling or response format details, but sufficient for typical use.
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 coverage is 100% with parameter 'mint' described as 'Token mint address'. Description adds the phrase 'for a specific mint' but does not provide additional meaning beyond the schema. Baseline of 3 applies due to high schema coverage.
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 'detailed token metadata' for a specific mint, listing specific fields like verification status, organic score, daily volume, holder count. This distinguishes it from siblings like jupiter_token_search and jupiter_price.
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 on when to use this tool versus alternatives. Does not mention prerequisites, exclusions, or context where this tool is preferred over siblings like jupiter_token_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Solana tokens by name, symbol, or mint address. Returns metadata, verification status, organic scores, and trading metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Token name, symbol, or mint address | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Search') and lists return fields, but does not disclose data freshness, authentication needs, or error behavior. Without annotations, this is adequate but not thorough.
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 sentence that efficiently conveys purpose and output. It is compact but could benefit from structured formatting (e.g., bullets) to improve readability for complex response expectations.
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 no output schema, the description adequately lists the types of returned data (metadata, verification, scores, metrics). It is missing details on sorting, pagination, and error handling, but covers key aspects of the tool's output.
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 coverage is 100%, with descriptions for 'query' and 'limit' already explaining they accept name/symbol/mint and max results. The description largely repeats this, adding little new semantic value beyond what the schema provides.
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 searches for Solana tokens by name, symbol, or mint address, and returns metadata, verification status, organic scores, and trading metrics. This distinguishes it from siblings like jupiter_token_info and jupiter_price.
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 use for finding tokens, but does not explicitly state when to use this tool over alternatives like jupiter_token_info (for detailed info by address) or jupiter_price (for price). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action within a specific Jupiter domain (DCA, lending, limit orders, perps, swaps, predictions, tokens). No two tools have overlapping purposes, and the naming clearly distinguishes them.
All tools follow a consistent jupiter_{domain}_{action} pattern. Minor deviations: 'jupiter_price' and 'jupiter_portfolio' omit a domain prefix, and verb forms vary (singular vs plural), but the overall pattern is clear.
16 tools cover a broad DeFi feature set (swaps, lending, DCA, limit orders, perps, predictions, token info) without bloat. Each feature has an appropriate number of tools (2-4), making the surface manageable and complete.
Core CRUD or lifecycle operations are present for each domain: create/list/cancel for orders, deposit/withdraw for lending, quote/build for swaps. Minor gaps like missing DCA cancellation or perps order placement tools are not critical for typical usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Native Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
Non-custodial DeFi tools for AI agents on Solana: swaps, perps, lending, staking, equities.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ExpertVagabond/jupiter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
