Solana Trading & Live Data — PumpView

get_payment_instructions

Create a new unpaid USDC invoice for a live-data package; this spends no funds.

    Call only after choosing a current plan with list_data_plans and checking get_access_status.
    Trading alone needs no data subscription. Requires a Bearer key and linked
    Solana wallet; missing wallet returns 409, unknown plan 404, disabled sales 503.
    Returns invoice id, payer, recipient, mint, atomic amount, memo and Unix expiry.
    Each call creates another invoice, so retain its ID rather than retry blindly.
    Next use prepare_invoice_payment, review/sign/broadcast with your wallet,
    then confirm_invoice_payment with the transaction signature. get_invoice_status
    checks settlement. submit_swap is for swaps, not invoice payments.
    Never pay an expired invoice or repeat a payment while confirmation is pending.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`plan`	Yes	Exact data-package id from list_data_plans. Current ids: day (Day Pass), starter (Starter), builder (Unlimited). Use the id, not the display name; confirm current price and availability first.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Invoice ID for prepare_invoice_payment, get_invoice_status and confirm_invoice_payment.
`memo`	Yes	Exact payment memo binding the transaction to this invoice.
`mint`	Yes	Native Solana USDC mint address required for this payment.
`paid`	Yes	Whether the invoice has been settled. A newly created invoice is unpaid.
`plan`	Yes	Selected plan ID from the current public plan catalog.
`payer`	Yes	Linked Solana wallet that must authorize payment.
`amount`	Yes	Exact invoice amount in USDC atomic units; divide by 10^decimals for USDC.
`created`	Yes	Invoice creation time as Unix seconds.
`expires`	Yes	Invoice expiry as Unix seconds; do not pay an expired invoice.
`network`	Yes	Required payment network: solana-mainnet.
`decimals`	Yes	USDC decimals: 6.
`recipient`	Yes	Public payment recipient to verify before signing.
`payment_protocol`	Yes	Payment workflow identifier: pumpview-invoice-v1.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / plan / description

Previous value: -"Exact data-package id from public GET https://api.pumpview.fun/v1/plans. Current ids: day (Day Pass), starter (Starter), builder (Unlimited). Use the id, not the display name; confirm current price and availability first."New value: +"Exact data-package id from list_data_plans. Current ids: day (Day Pass), starter (Starter), builder (Unlimited). Use the id, not the display name; confirm current price and availability first."

changedOutput schema / properties / id / description

Previous value: -"Invoice ID for HTTP transaction preparation, status and payment confirmation."New value: +"Invoice ID for prepare_invoice_payment, get_invoice_status and confirm_invoice_payment."

First observedOct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, destructive=false; the description adds far more: auth requirements (Bearer key, linked Solana wallet), specific failure codes (409 missing wallet, 404 unknown plan, 503 sales disabled), the returned field set, and the non-idempotent warning to retain the invoice ID rather than retry blindly — which directly aligns with idempotentHint=false. No contradiction with annotations.

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 purpose, then preconditions, error codes, return shape, and the payment lifecycle; nearly every sentence carries unique operational value. It is long for a one-parameter tool, but the density is justified rather than padded.

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?

Despite an output schema being present, the description still sketches the return values (invoice id, payer, recipient, mint, atomic amount, memo, expiry) and covers auth, error states, idempotency risk, and the full downstream workflow. Nothing an agent needs to call this correctly 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% and the single 'plan' parameter is already documented in the schema with valid ids and a display-name caveat. The description reinforces that a current plan must be chosen first but adds no new syntax or format detail, so the baseline 3 applies.

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?

Opens with a specific verb+resource: 'Create a new unpaid USDC invoice for a live-data package', plus the reassurance 'this spends no funds'. It goes further than most by naming several siblings it is not (submit_swap is for swaps, prepare_invoice_payment is the next step), so an agent can place it precisely in the workflow.

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?

Gives explicit preconditions ('Call only after choosing a current plan with list_data_plans and checking get_access_status'), an exclusion ('Trading alone needs no data subscription'), and the ordered follow-up chain (prepare_invoice_payment -> sign/broadcast -> confirm_invoice_payment). This is textbook when/when-not/alternatives guidance.

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?