Solana Trading & Live Data — PumpView

get_onboarding_instructions

Read-onlyIdempotent

Get API-key setup and integration instructions before your first PumpView call.

    Public: no key or data credits needed. Returns dashboard/Agent Kit/docs URLs,
    ordered HTTP wallet-challenge steps, and separate trading/data workflows.
    Does not create an account, sign, pay or trade. Once connected, use
    get_trading_config for swap policy or get_access_status for your purchased access.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Paid live-data requirements and URL of the current plan catalog.
`name`	Yes	Service name: PumpView.
`mcp_url`	Yes	Streamable HTTP MCP endpoint.
`network`	Yes	Solana network used by the API: solana-mainnet.
`trading`	Yes	Trading subscription requirements, policy URL, tool names and signing workflow.
`agent_kit`	Yes	Public PumpView examples and installable skill repository.
`documentation`	Yes	Markdown integration guide with HTTP onboarding and payment steps.
`skill_install`	Yes	Command to install the PumpView trading skill.
`wallet_access`	Yes	Ordered HTTP challenge, local message-signing and access-exchange steps; no private key is transmitted.
`account_access`	Yes	Dashboard URL for login, wallet linking and API keys.
`authentication`	Yes	Authorization header template; replace the placeholder with your own secret key.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes further: it specifies public access with no key or data credits, that it does not create an account, sign, pay, or trade, and that its output includes ordered HTTP wallet-challenge steps. This is meaningful behavioral context beyond the annotations.

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?

Front-loaded with the core purpose, then permissions, then return content, then sibling routing. Every clause carries information the agent needs; no filler.

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?

With an output schema present, return values need not be spelled out, yet the description still summarizes the payload (URLs, challenge steps, workflows) and covers prerequisites, exclusions, and next steps. Nothing an agent needs to invoke it correctly is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies for a no-parameter tool.

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 (get) and resource (onboarding/API-key setup and integration instructions) and scopes it temporally ('before your first PumpView call'). It is immediately distinguishable from siblings like get_payment_instructions or get_trading_config, which it names.

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 says when to use it (before the first call), when it is safe to use (public, no key or credits), and routes the agent afterward: 'use get_trading_config for swap policy or get_access_status for your purchased access.' Both condition and alternative are named.

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?