Skip to main content
Glama

jupiter_dca_create

Create a DCA order for recurring token swaps on Solana—automate buying a fixed amount of one token with another at regular intervals.

Instructions

Create a DCA order — recurring swap on a schedule. Returns transaction to sign. Example: buy $10 SOL every hour.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputMintYesMint of token to spend (e.g. USDC)
outputMintYesMint of token to accumulate (e.g. SOL)
inAmountYesTotal amount to spend over DCA period (base units)
inAmountPerCycleYesAmount per cycle (base units)
cycleSecondsApartYesSeconds between cycles (3600 = hourly)
makerYesWallet address
minOutAmountPerCycleNoMin output per cycle (slippage protection)
maxOutAmountPerCycleNoMax output per cycle

Implementation Reference

  • Handler function for the 'jupiter_dca_create' tool — calls client.recurringCreate(args) with the schema-validated arguments and returns the JSON result.
    async (args) => {
      const result = await client.recurringCreate(args);
      return JSON.stringify(result, null, 2);
    },
  • Zod schema definitions for the 'jupiter_dca_create' tool — defines inputMint, outputMint, inAmount, inAmountPerCycle, cycleSecondsApart, maker, and optional minOutAmountPerCycle and maxOutAmountPerCycle
    "Create a DCA order — recurring swap on a schedule. Returns transaction to sign. Example: buy $10 SOL every hour.",
    {
      inputMint: z.string().describe("Mint of token to spend (e.g. USDC)"),
      outputMint: z.string().describe("Mint of token to accumulate (e.g. SOL)"),
      inAmount: z.string().describe("Total amount to spend over DCA period (base units)"),
      inAmountPerCycle: z.string().describe("Amount per cycle (base units)"),
      cycleSecondsApart: z.number().describe("Seconds between cycles (3600 = hourly)"),
      maker: z.string().describe("Wallet address"),
      minOutAmountPerCycle: z.string().optional().describe("Min output per cycle (slippage protection)"),
      maxOutAmountPerCycle: z.string().optional().describe("Max output per cycle"),
    },
  • Registration function registerRecurringTools that calls register() to register 'jupiter_dca_create' (and 'jupiter_dca_orders') as MCP tools on the server
    export function registerRecurringTools(register: ToolRegistrar, client: JupiterClient) {
      register(
        "jupiter_dca_orders",
        "Get active DCA (Dollar Cost Average) orders for a wallet — recurring schedules and progress.",
        {
          wallet: z.string().describe("Wallet address"),
        },
        async (args) => {
          const result = await client.recurringOrders(args.wallet);
          return JSON.stringify(result, null, 2);
        },
      );
    
      register(
        "jupiter_dca_create",
        "Create a DCA order — recurring swap on a schedule. Returns transaction to sign. Example: buy $10 SOL every hour.",
        {
          inputMint: z.string().describe("Mint of token to spend (e.g. USDC)"),
          outputMint: z.string().describe("Mint of token to accumulate (e.g. SOL)"),
          inAmount: z.string().describe("Total amount to spend over DCA period (base units)"),
          inAmountPerCycle: z.string().describe("Amount per cycle (base units)"),
          cycleSecondsApart: z.number().describe("Seconds between cycles (3600 = hourly)"),
          maker: z.string().describe("Wallet address"),
          minOutAmountPerCycle: z.string().optional().describe("Min output per cycle (slippage protection)"),
          maxOutAmountPerCycle: z.string().optional().describe("Max output per cycle"),
        },
        async (args) => {
          const result = await client.recurringCreate(args);
          return JSON.stringify(result, null, 2);
        },
      );
  • Helper method recurringCreate on JupiterClient — sends a POST request to /recurring/v1/createOrder with the DCA parameters to create the transaction
    async recurringCreate(params: {
      inputMint: string;
      outputMint: string;
      inAmount: string;
      inAmountPerCycle: string;
      cycleSecondsApart: number;
      maker: string;
      minOutAmountPerCycle?: string;
      maxOutAmountPerCycle?: string;
    }) {
      return this.request("/recurring/v1/createOrder", {
        method: "POST",
        body: params,
      });
    }
  • src/index.ts:66-69 (registration)
    Top-level registration call that wires registerRecurringTools into the MCP server via the register function
    registerRecurringTools(register, client);
    registerPredictionTools(register, client);
    registerPerpsTools(register, client);
    registerPortfolioTools(register, client);
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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