Skip to main content
Glama

Solana Trading & Live Data — PumpView

build_swap

Idempotent

Build and simulate an unsigned ExactIn swap, without spending funds.

    Requires a Bearer API key and its linked wallet, but no data subscription or
    credits. Check get_trading_config first. At least one leg must be SOL/WSOL or
    USDC; minimum value is $5 unless Unlimited is active. Execution costs 0.5%
    plus tips and network fees. Returns id, unsigned transaction_base64, expiry,
    expected/minimum output and cost breakdown. Review them, sign locally, then
    call submit_swap. Persist request_id; retry the identical intent after a build
    timeout. A 409 means conflicting intent; 410 means expired build and requires
    an explicit decision to create a new intent. Never silently increase slippage.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesExact input amount in atomic units, encoded as a decimal integer string, at most u64. SOL/WSOL has 9 decimals and USDC 6; resolve other token decimals first. Example: 0.06 SOL is "60000000".
walletYesBase58 public key of the signing wallet linked to this API-key account. Obtain/link it through onboarding; never pass a private key.
input_mintYesAsset to spend: SOL for native balance, WSOL for SPL wrapped balance, USDC, or a base58 token mint. One leg must resolve to SOL/WSOL/USDC.
request_idYesClient-generated idempotency key, persisted before calling. Reuse with identical arguments after a timeout; changing the intent under this ID returns 409.
output_mintYesAsset to receive using the same aliases or a base58 mint. Must differ from the input after alias resolution; SOL-to-WSOL wrapping alone is unsupported.
slippage_bpsYesExplicit signer-approved slippage tolerance. 100 basis points = 1%; 10000 allows 100%. Never silently increase it to fix a failed route.
tip_lamportsNoTotal acceleration tip in SOL lamports, separate from platform and network fees. 2000000 lamports = 0.002 SOL; charged only if the signed transaction executes.
max_priority_fee_lamportsNoCap on the compute-unit priority fee in lamports. Excludes the base network fee, tips, token-account rent and platform fee; 1000000 = 0.001 SOL.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPumpView swap ID (32 lowercase hex characters), passed as swap_id to status and submit tools.
tipsNoTotal tip and transfer destinations for wallet review, in lamports.
errorNoFailure information if present. Preserve the swap ID and inspect status before deciding on any new intent.
statusYesLifecycle state: built, submitted, confirmed, finalized, failed, or expired. A send timeout may leave state uncertain; poll this ID.
receiptNoActual execution details from confirmed onward; null before confirmation or while RPC transaction metadata is pending.
signatureNoSolana transaction signature, or null before submission. Not interchangeable with the PumpView swap ID.
expires_atNoUnsigned build expiry as Unix seconds; not proof that a submitted transaction failed.
request_idNoOriginal client-generated idempotency key for this intent.
input_amountNoExact input amount as a string of integer atomic units.
platform_feeNoFee basis points, mint, recipient account and calculation basis.
transaction_base64NoUnsigned Solana v0 transaction for local wallet signing; only returned for a build still in built state.
network_fee_lamportsNoEstimated total network fee for the built message, as an integer string.
minimum_output_amountNoSlippage-protected output threshold in atomic units to review before signing.
expected_output_amountNoQuoted output in atomic units; execution may differ within the slippage bound.
last_valid_block_heightNoLast block height accepted by the transaction blockhash.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: auth requirement (Bearer key + linked wallet), cost model (0.5% + tips + network fees), what is returned, timeout/retry behavior, and the meaning of 409 vs 410. The annotations only flag non-read-only/idempotent, so this extra context is genuinely additive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and then proceeds through prerequisites, costs, output, and error handling in a logical order; each sentence carries operational weight. It is dense and run-on in places, which costs a little readability.

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

Completeness5/5

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

For an 8-parameter mutation tool with an output schema, the description still covers auth, funding requirements, cost breakdown, retry/idempotency, and error semantics — everything needed to invoke and follow up correctly. Nothing material is missing.

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 schema already explains every parameter thoroughly; baseline is 3. The description reinforces request_id persistence/409 coupling and the slippage policy, but adds little parameter syntax or meaning not already in the schema fields.

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 and simulate an unsigned ExactIn swap') plus scope ('without spending funds'), and names the sibling (submit_swap) that completes the workflow. An agent can immediately distinguish it from get_swap_status and submit_swap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit sequencing: check get_trading_config first, then build, sign locally, and call submit_swap. Adds concrete exclusion conditions (no data subscription/credits needed, min $5 unless Unlimited) and error-code routing for 409/410 plus the 'never silently increase slippage' rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources