Solana Trading & Live Data — PumpView

confirm_invoice_payment

Idempotent

Verify an already-broadcast invoice payment and activate the purchased data package.

    Bearer key for the invoice owner required; no data credits consumed. Reads
    Solana at finalized and validates payer, recipient, USDC amount, memo and
    payment window. It never broadcasts a payment. Returns paid=true and
    invoice_id on settlement. Repeating the same invoice/signature is safe and
    never grants access twice. 409 means processing (landing, or unseen for under
    30 s): retry this confirmation with backoff, not the payment. 422 means the
    signature is still not on Solana: check it is the one your wallet broadcast,
    not the prepared transaction's; if it was never sent or its blockhash expired,
    prepare a new transaction. 410 means not found and invoice expired. 400 means
    mismatch or failed transaction; 404 missing/foreign invoice; 429 retry later
    (Retry-After); 503 RPC unavailable. After success,
    use get_access_status, then get_recent_trades or get_stream_connection.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "invoice_id": "<invoice_id>",
      "signature": "<signature>"
    },
    "name": "confirm_invoice_payment"
  }
}

Input Schema

Name	Required	Description	Default
`signature`	Yes	Base58 Solana transaction signature returned by your wallet after broadcasting this invoice payment. Not a signed transaction, wallet-login signature or private key.
`invoice_id`	Yes	Invoice id returned by get_payment_instructions for this API-key account. Not a swap id or Solana transaction signature.

Output Schema

Name	Required	Description	Default
`paid`	Yes	True once matching finalized payment is verified and the package has been activated.
`invoice_id`	Yes	Settled invoice ID. Reconfirming the same signature never grants access twice.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (idempotentHint=true, destructiveHint=false), the description adds substantial context: bearer key required, no credits consumed, read occurs at Solana 'finalized' commitment, it never broadcasts, repeat calls are safe and never double-grant, and it maps seven distinct HTTP status codes to meanings.

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?

The core purpose and the auth/read-only guarantees are front-loaded, and the error-code catalogue replaces documentation that exists nowhere else. It is dense but nearly every clause carries actionable information; the status-code run is long but earns its space.

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?

Given an output schema already exists, the description need not restate return fields, and it still names the key return values (paid=true, invoice_id). Combined with error semantics and the post-success tool chain, an agent has everything needed to call it correctly and recover from failures.

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 coverage is 100%, so the schema already defines both parameters. The description still adds real meaning by warning that the signature must be the wallet-broadcast one, not the prepared transaction's, which is a semantic distinction the schema pattern cannot express.

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 first sentence names a specific verb and resource pair ('verify an already-broadcast invoice payment and activate the purchased data package') and is clearly distinct from the sibling 'prepare_invoice_payment' (which builds the transaction) and 'get_invoice_status' (which only reads state).

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?

It gives explicit instructions for every outcome: retry with backoff on 409 rather than retrying the payment, prepare a new transaction on 422 if the blockhash expired, and follow success with get_access_status then get_recent_trades or get_stream_connection. Alternative actions are named for each branch.

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?