Solana Trading & Live Data — PumpView

submit_swap

DestructiveIdempotent

Broadcast the wallet-approved, signed build through Kolibrio. This can spend funds.

    Requires a Bearer key for the account that built the swap. Only the exact
    build_swap message is accepted; the wallet must already have reviewed and
    authorized its amounts and costs. Returns the swap ID, signature and current
    status; submitted is not confirmation. Repeating the same ID and signed bytes
    cannot create a different trade. After a timeout or uncertain delivery, poll
    get_swap_status; never automatically build a replacement or change its blockhash.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`swap_id`	Yes	PumpView id returned by build_swap for this account, not a Solana signature or request_id.
`signed_transaction_base64`	Yes	Standard base64 of the complete serialized Solana v0 transaction from this build, after local wallet signing. Preserve the original message and blockhash. Not a signature string, seed, private key or JSON transaction.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	PumpView swap ID (32 lowercase hex characters), passed as swap_id to status and submit tools.
`tips`	No	Total tip and transfer destinations for wallet review, in lamports.
`error`	No	Failure information if present. Preserve the swap ID and inspect status before deciding on any new intent.
`status`	Yes	Lifecycle state: built, submitted, confirmed, finalized, failed, or expired. A send timeout may leave state uncertain; poll this ID.
`receipt`	No	Actual execution details from confirmed onward; null before confirmation or while RPC transaction metadata is pending.
`signature`	No	Solana transaction signature, or null before submission. Not interchangeable with the PumpView swap ID.
`expires_at`	No	Unsigned build expiry as Unix seconds; not proof that a submitted transaction failed.
`request_id`	No	Original client-generated idempotency key for this intent.
`input_amount`	No	Exact input amount as a string of integer atomic units.
`platform_fee`	No	Fee basis points, mint, recipient account and calculation basis.
`transaction_base64`	No	Unsigned Solana v0 transaction for local wallet signing; only returned for a build still in built state.
`network_fee_lamports`	No	Estimated total network fee for the built message, as an integer string.
`minimum_output_amount`	No	Slippage-protected output threshold in atomic units to review before signing.
`expected_output_amount`	No	Quoted output in atomic units; execution may differ within the slippage bound.
`last_valid_block_height`	No	Last block height accepted by the transaction blockhash.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructive/openWorld/idempotent, and the description reinforces these with substance rather than repetition: 'This can spend funds', 'submitted is not confirmation', and an explanation of idempotency semantics ('Repeating the same ID and signed bytes cannot create a different trade'). It also discloses the auth requirement (Bearer key) and the retry/timeout policy.

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 the core action and the money-spending warning, then prerequisites, then failure handling. Dense but each clause carries operational weight; the line-broken formatting is slightly awkward for a description field but not wasteful.

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 a destructive, authenticated broadcast tool, the description covers purpose, auth, input provenance, idempotency, failure handling, and the distinction between submission and confirmation. An output schema exists, yet the description still briefly notes the return shape (swap ID, signature, status) without over-explaining.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 documents both parameters in detail, establishing a baseline of 3. The description adds cross-tool meaning: 'Only the exact build_swap message is accepted' and the requirement that the wallet must already have authorized its amounts and costs, which clarifies why the signed bytes must be unmodified.

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: 'Broadcast the wallet-approved, signed build through Kolibrio.' It immediately distinguishes itself from the sibling build_swap by emphasizing that the transaction is already built, signed and approved, and it flags the money-spending nature up front.

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?

Explicitly states prerequisites ('Requires a Bearer key for the account that built the swap', 'Only the exact build_swap message is accepted') and post-conditions with a named alternative: 'After a timeout or uncertain delivery, poll get_swap_status; never automatically build a replacement or change its blockhash.' This is a clear when-to-use / when-not-to-use / what-to-do-instead set.

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

All Solana Trading & Live Data — PumpView tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?