Skip to main content
Glama

Build an unsigned swap transaction

justi_build_swap

Builds an unsigned Solana v0 transaction to buy or sell a justi.fun coin for a wallet. Quotes fresh, simulates, sets compute limit and priority fee, and returns the base64 transaction for the user to sign.

Instructions

Build an unsigned Solana v0 transaction that buys or sells a justi.fun coin for a wallet. Nothing is signed or sent: the user's wallet must sign it. The server quotes fresh, simulates, and sets the compute limit and priority fee. Returns swapId, the base64 transaction, the quote and how to submit.

Input Schema

NameRequiredDescriptionDefault
mintYes
sideYes
walletYesThe wallet that pays and signs
amountRawNoRaw units instead of the decimal amounts
amountSolNoBuy: SOL to spend
priorityFeeNo"auto" or micro-lamports per compute unit
slippageBpsNo
amountTokensNoSell: whole tokens

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: nothing is signed or sent, the user's wallet must sign, the server re-quotes, simulates, and sets compute limit and priority fee. That explains the non-destructive but state-changing workflow clearly. It stops short of stating auth requirements or whether the quote can expire.

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?

Four sentences, front-loaded with purpose, then the no-signing constraint, then server behavior, then the return shape. No filler and every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, spelling out the return (swapId, base64 tx, quote, submission instructions) is genuinely useful, and the simulation/priority-fee behavior is covered. The gaps are the amount-parameter selection rules and slippage defaults for an 8-parameter tool.

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 coverage is 63%, so the schema already documents most fields, including the buy/sell amount fields. The description only mentions priority fee indirectly and adds no guidance on which amount parameter to use per side or on slippage defaults, so it doesn't compensate for the uncovered parameters.

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?

States a specific verb and resource ('Build an unsigned Solana v0 transaction that buys or sells a justi.fun coin') and its scope (unsigned, per-wallet). The 'unsigned build' framing clearly separates it from justi_quote and from the signing/submission siblings like justi_tx_status.

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?

Usage is implied: you call this to get a swap transaction to sign. It never explicitly says when to prefer justi_quote first, or when not to use this (e.g. for launches, which belong to justi_build_launch). No alternatives or exclusions are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.