Provides access to Solana on-chain data, including current network health, token prices and liquidity, account SPL token balances, transaction status and transfers, and trending DEX pairs. Payments for data access are settled in USDC on Solana via x402.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@47620 Solana Data What are the top trending Solana DEX pairs right now?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give any MCP-capable AI agent (Claude, Cursor, Windsurf, OpenClaw, …) native access to 47620 pay-per-call Solana data, settled over x402 (HTTP 402) in USDC on Solana — non-custodial, no signup, no API key.
Tool | What it returns | Price |
| Current slot, epoch, SOL/USD | $0.001 |
| Price, liquidity, 24h volume, DEX pairs for an SPL mint | $0.002 |
| SOL + all SPL token balances for an address | $0.002 |
| Status, slot, fee, transfers for a tx signature | $0.003 |
| Trending Solana DEX pairs by 24h volume | $0.005 |
Each tool call is an x402 paid request: the server gets a 402, pays USDC to the merchant
wallet on Solana, and retries with the payment header. Funds go directly to the seller's
wallet; a 1% platform fee is a second on-chain transfer.
Related MCP server: boo-x402-mcp
Run straight from GitHub (no npm publish needed):
npx -y github:47620-xyz/solana-data-mcpOr clone and run:
git clone https://github.com/47620-xyz/solana-data-mcp
cd solana-data-mcp && npm install && node src/index.js{
"mcpServers": {
"47620-solana-data": {
"command": "npx",
"args": ["-y", "github:47620-xyz/solana-data-mcp"],
"env": {
"X402_BASE_URL": "https://47620.xyz",
"X402_WALLET_KEY": "<base58 Solana secret key>"
}
}
}
}X402_WALLET_KEY — base58 secret key of a Solana wallet that holds a little USDC + SOL.
The server signs the transfer and retries automatically. Fully autonomous (best for agents).
X402_PAY_URL — an HTTP payment broker: POST { url, challenge } → { header }. For hosted /
MPC wallets where the key never touches the process.
neither — the tool returns the 402 challenge plus a ready-to-run
npx awal x402 pay "<url>" command, so the agent (or its x402-aware runtime) pays.
Var | Default | Notes |
|
| API base |
| — | base58 Solana secret key (payment mode 1) |
| — | payment broker (payment mode 2) |
| mainnet-beta | Solana RPC for settlement |
// agent prompt
"Use solana_trending to get the top Solana DEX pairs right now."HTTP API directly: GET https://47620.xyz/x/solana/trending → 402 (pay & retry)
Agent Skill: npx skills add 47620-xyz/solana-data-skills
Gateway: https://47620.xyz — payment buttons for ecommerce, non-custodial
MIT
Native SOL balance plus every SPL token balance (incl. USDC) for a Solana address. Pay-per-call ($0.002 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Solana wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses the monetary cost ($0.002 USDC) and the comprehensive scope of the balance lookup, but it does not state whether the operation is read-only, how errors are surfaced, or any rate-limit constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core behavior, scope, and cost with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description sufficiently explains what the call returns (native and SPL balances) and the cost. It does not detail response formatting or failure modes, but the low complexity and full schema coverage keep the gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is adequately described as 'Solana wallet address'. The tool description adds no further semantic detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (a Solana address) and the exact data returned: native SOL balance plus all SPL token balances including USDC. It is distinguishable from sibling tools by content focus, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of siblings like solana_token, solana_tx, or solana_trending. It states the pay-per-call cost but not the conditions or contexts in which this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solana network health: current slot, epoch, and SOL/USD price. Pay-per-call ($0.001 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the call's expected outputs and the pay-per-call cost of $0.001 USDC, which is useful. However, it does not mention auth requirements, rate limits, availability, or response format, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the resource, immediately lists the three returned metrics, and ends with the pricing detail. There is no filler and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, low-complexity read-only health tool, the description provides all essential selection information: the resource, the exact returned values, and the cost. The lack of an output schema is acceptable because the expected data points are stated directly in prose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because parameter documentation is effectively a non-issue.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports Solana network health and names three concrete outputs: current slot, epoch, and SOL/USD price. This is specific enough to distinguish it from the token, account, transaction, and trending siblings, even though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use, when-not-to-use, or alternative tool guidance is provided. The agent must infer from the 'network health' label and the sibling names that this is the right tool for chain status and price checks. For a zero-parameter health endpoint this is acceptable, but the usage context remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live price, liquidity, 24h volume and DEX pairs for any Solana SPL token mint. Pay-per-call ($0.002 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | SPL token mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add meaningful context by stating the tool is pay-per-call at $0.002 USDC and that data is live, which goes beyond a generic fetch. However, it does not mention error behavior, rate limits, or what happens for invalid mint addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clause states the returned data and input scope, and one clause states the cost. There is no redundant or filler content, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-style tool with no output schema, the description covers the input, the returned fields, and the cost model. It does not describe response format or failure cases, but the tool's low complexity and the description's directness make it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the single 'mint' parameter as an SPL token mint address. The description adds only 'any' and 'Solana' context, which does not materially improve understanding beyond the schema. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (Solana SPL token mint) and the data returned (price, liquidity, 24h volume, DEX pairs), which clearly distinguishes it from the account, transaction, health, and trending siblings. It lacks an explicit verb like 'get' or 'fetch', but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over the sibling tools. The phrase 'for any Solana SPL token mint' implies the input condition, but there is no explicit when-to-use, exclusions, or reference to alternatives such as solana_account or solana_trending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live trending / new Solana DEX pairs by 24h volume. A fresh feed for agents. Pay-per-call ($0.005 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses pay-per-call cost and the notion of being a live feed, but does not state whether the operation is read-only, what error handling or rate limits exist, or how the response is structured. For a tool that agents will call, these are significant omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three short sentences that front-load the core purpose first. The second sentence about being a fresh feed adds a slight redundancy but still conveys usage context. The cost mention is important and well placed. There is minimal fluff, and it is easily skimmable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description should at least indicate the nature of the returned data (e.g., an array of pair objects with volume fields), but it only says 'DEX pairs' without structural details. It also omits any authentication or setup prerequisites. For a simple tool with no parameters, this is still incomplete for an agent that needs to consume the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. The description does not need to explain parameters. The baseline for 0 parameters is 4, and no additional parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live trending/new Solana DEX pairs ranked by 24h volume. The resource and sorting criterion are specific, and the purpose is distinct from sibling tools like solana_token or solana_account. Even though the verb is implicit, the meaning is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving current market data (trending/new pairs) and mentions it is a 'fresh feed for agents', suggesting repeated polling. However, it gives no explicit guidance on when to use this tool versus the siblings (e.g., solana_health for network status, solana_token for token details) nor any exclusions. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status, slot, fee, block time and transfer summary for a Solana transaction signature. Pay-per-call ($0.003 USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Transaction signature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a meaningful behavioral trait: pay-per-call with a specific cost ($0.003 USDC), which is valuable for an agent deciding whether to invoke it. It also describes the output categories, but it does not mention potential errors, signature format requirements, or whether the call is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that front-loads the core output information and appends the pay-per-call cost. Every clause adds useful information, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is largely complete: it tells the agent what data will be returned and warns about the cost. It could be improved by noting any special formatting requirements for the signature, such as base58 encoding or mainnet specificity, but these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The schema already documents the single 'signature' parameter. The description adds confirmation that the signature is for a Solana transaction, but it does not add format details, network context, or example values beyond what the schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: a Solana transaction signature, and lists the exact data it returns (status, slot, fee, block time, transfer summary). It lacks an explicit verb like 'retrieves' or 'gets', but the noun-phrase style is still unambiguous and distinguishes it from the sibling tools, which cover health, token, account, and trending data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the siblings solana_health, solana_token, solana_account, or solana_trending. The use case is implied by the resource type, but no explicit context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0solana_accountsolana_healthsolana_tokensolana_trendingsolana_txScored across 5 tools
Each tool targets a distinct Solana data resource: network health, token price, account balances, transaction status, and trending pairs. There is no overlap in purpose.
All tools follow the exact verb_noun-like pattern 'solana_' plus a clear resource name (health, token, account, tx, trending). Perfectly consistent.
Five tools cover the core Solana data access needs without bloat. The count is well-scoped for a data-focused server.
Provides essential reads: network status, token prices, account balances, transaction details, and trending activity. Minor gaps like historical account transfers or block details exist, but the main domain is well covered.
Curated marketplace of real-world data APIs for AI agents, paid per call in USDC on Solana.
Pay-per-call MCP tools over x402 (USDC/Solana): LLM, utilities, x402 market and model prices.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
