Which integrations are available for this server?

Integrates with the Solana blockchain to facilitate pay-per-request AI inference, allowing users to manage balances and pay for API calls using USDC or SOL directly from their wallet.

solanaprox-mcp

by solanaprox

Overview Schema Related Servers Score Discussions

JavaScript

Remote

SolanaProx MCP Server

Pay for AI inference with Solana. No API keys. Your wallet is your identity.

npm version License: MIT

Connect Claude Desktop, Cursor, or any MCP-compatible AI tool to SolanaProx — pay per request using USDC or SOL directly from your Phantom wallet.

What is SolanaProx?

SolanaProx is an AI API gateway where your Phantom wallet is your account. Deposit USDC or SOL, make AI requests, pay per use. No signups. No subscriptions. No API key management.

Your Phantom Wallet → SolanaProx → Claude / GPT-4
       ↑                                    ↓
   USDC balance                        AI response

Related MCP server: @portalsprotocol/mcp-server

Quick Start

1. Install the MCP server

npx solanaprox-mcp

2. Add to Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "solanaprox": {
      "command": "npx",
      "args": ["solanaprox-mcp"],
      "env": {
        "SOLANA_WALLET": "YOUR_PHANTOM_WALLET_ADDRESS"
      }
    }
  }
}

3. Add to Cursor

Edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "solanaprox": {
      "command": "npx",
      "args": ["solanaprox-mcp"],
      "env": {
        "SOLANA_WALLET": "YOUR_PHANTOM_WALLET_ADDRESS"
      }
    }
  }
}

4. Deposit USDC

Visit solanaprox.com, connect your Phantom wallet, and deposit USDC or SOL.

That's it. Claude can now make AI requests that pay automatically from your balance.

Tools

`ask_ai`

Send a prompt to Claude or GPT-4. Cost deducted automatically from wallet balance.

Input:
  prompt      (required) — your question or task
  model       (optional) — claude-sonnet-4-20250514 (default) | gpt-4-turbo
  max_tokens  (optional) — 1-4096, default 1024
  system      (optional) — system prompt for context

`check_balance`

Check your current USDC/SOL balance on SolanaProx.

Input:
  wallet  (optional) — defaults to configured SOLANA_WALLET

`estimate_cost`

Estimate request cost before making it.

Input:
  prompt      (required)
  model       (optional)
  max_tokens  (optional)

`list_models`

List all available models and pricing.

Pricing

Model	Input	Output
Claude Sonnet 4	$3.60/1M tokens	$18.00/1M tokens
GPT-4 Turbo	$12.00/1M tokens	$36.00/1M tokens

Cached responses receive a 50% discount.

Typical request costs:

Short question/answer: ~$0.001–0.003
Code review (500 lines): ~$0.01–0.03
Long document analysis: ~$0.05–0.15

Use Cases

Personal AI assistant with micropayments

Pay only for what you use. No $20/month subscription burning while you sleep.

Autonomous AI agents

AI agents that pay for their own inference — no hardcoded API keys, no human in the loop.

// Agent pays autonomously on every request
const res = await fetch("https://solanaprox.com/v1/messages", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-Wallet-Address": process.env.SOLANA_WALLET,
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-20250514",
    max_tokens: 1024,
    messages: [{ role: "user", content: prompt }],
  }),
});

Solana app integration

Let your app's users pay for AI features directly from their Phantom wallet. No backend payment processing required.

Environment Variables

Variable	Required	Description
`SOLANA_WALLET`	✅	Your Phantom wallet address
`SOLANAPROX_URL`	❌	Override API URL (default: https://solanaprox.com)

Standalone Agent Example

git clone https://github.com/solanaprox/mcp-server
cd mcp-server
npm install

# Run the research agent
SOLANA_WALLET=your_wallet node agent-example.js research "Solana DeFi trends 2026"

# Check balance
SOLANA_WALLET=your_wallet node agent-example.js balance

# Quick demo
SOLANA_WALLET=your_wallet node agent-example.js

Integration Examples

LangChain (Python)

Coming soon — or use the REST API directly.

Direct REST API

# Check balance
curl https://solanaprox.com/api/balance/YOUR_WALLET

# Make AI request
curl -X POST https://solanaprox.com/v1/messages \
  -H "Content-Type: application/json" \
  -H "X-Wallet-Address: YOUR_WALLET" \
  -d '{
    "model": "claude-sonnet-4-20250514",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Security

Your wallet address is used as an identifier — it's public by design on Solana
Private keys never leave your wallet
SolanaProx only reads incoming transactions to your deposit address
Rate limiting and spend limits protect against runaway costs
All transactions verifiable on Solscan

Built by LPX Digital Group LLC

Part of the LPX ecosystem:

LightningProx — AI APIs via Bitcoin Lightning
SolanaProx — AI APIs via Solana/USDC
LPXPoly — AI-powered Polymarket analysis
IsItARug — Solana token safety scanner

MIT License

Available Tools

4 tools

ask_aiA

Send a prompt to an AI model via SolanaProx. Costs are automatically deducted from your Solana wallet balance in USDC. Supports Claude and GPT-4 models. Use this for any AI inference task.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	The prompt or question to send to the AI model
`model`	No	AI model to use. Options: claude-sonnet-4-20250514 (default), gpt-4-turbo	claude-sonnet-4-20250514
`max_tokens`	No	Maximum tokens in response (default: 1024, max: 4096)
`system`	No	Optional system prompt to set context for the AI

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the payment mechanism ('Costs are automatically deducted from your Solana wallet balance in USDC') and supported models ('Supports Claude and GPT-4 models'). However, it lacks information about rate limits, error handling, response format, or authentication requirements, which are important for a paid service tool.

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?

The description is perfectly concise with three sentences that each serve a distinct purpose: stating the core function, explaining the payment mechanism, listing supported models, and providing usage guidance. There's no wasted language, and the information is front-loaded with the most critical details first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a paid service tool with 4 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the payment mechanism and supported models well, but lacks information about response format, error conditions, rate limits, or authentication requirements that would be important for proper tool invocation in a production context.

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?

The schema description coverage is 100%, providing complete parameter documentation in the structured fields. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation. No additional semantic context is provided for the parameters beyond what the schema already covers.

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 description clearly states the specific action ('Send a prompt to an AI model'), identifies the resource ('via SolanaProx'), and distinguishes this tool from its siblings (check_balance, estimate_cost, list_models) by focusing on execution rather than querying or listing. It provides a complete purpose statement with both the primary function and the payment mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('Use this for any AI inference task'), which directly addresses its primary use case. However, it doesn't explicitly mention when NOT to use it or provide specific alternatives among the sibling tools (e.g., using estimate_cost first for cost estimation or list_models for model discovery), leaving some room for improvement in comparative guidance.

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

check_balanceA

Check your current SolanaProx balance. Returns available USDC and SOL balance that can be used for AI requests.

ParametersJSON Schema

Name	Required	Description	Default
`wallet`	No	Solana wallet address to check. Defaults to configured wallet.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the return values (USDC and SOL balances) and their purpose (for AI requests), which is useful behavioral context. However, it lacks details on permissions, rate limits, or error handling, leaving gaps in transparency for a financial tool.

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?

The description is two sentences, front-loaded with the core purpose and followed by return details. Every sentence adds value without waste, making it efficient and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides basic purpose and return context, which is adequate for a simple read operation. However, as a financial tool, it lacks details on authentication, data freshness, or error cases, leaving room for improvement in completeness.

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 schema description coverage is 100%, so the schema already documents the single parameter 'wallet'. The description does not add specific parameter semantics beyond implying balance checking, but with 0 required parameters and high schema coverage, the baseline is strong. The description's focus on output compensates slightly.

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 description clearly states the specific action ('Check'), resource ('SolanaProx balance'), and scope ('current'), distinguishing it from siblings like 'estimate_cost' or 'list_models'. It specifies what is returned ('available USDC and SOL balance'), making the purpose explicit and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to check balances for AI requests, but does not explicitly state when to use this tool versus alternatives like 'estimate_cost' for cost estimation or 'ask_ai' for making requests. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied.

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

estimate_costB

Estimate the cost of an AI request before making it. Returns estimated USD cost based on prompt length and model.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	The prompt to estimate cost for
`model`	No	Model to use for estimation	claude-sonnet-4-20250514
`max_tokens`	No	Expected max tokens in response

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. While it states the tool returns 'estimated USD cost', it doesn't disclose important behavioral traits: whether this is a read-only operation (likely, but not stated), whether it requires authentication, rate limits, accuracy of estimates, or what happens with invalid inputs. For a cost estimation tool with zero annotation coverage, this is a significant gap.

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?

Two concise sentences that efficiently convey the core functionality. The first sentence states the purpose, the second specifies what it returns. No wasted words, though it could be slightly more structured by separating purpose from return value more clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a cost estimation tool. It doesn't explain the return format (beyond 'estimated USD cost'), error conditions, whether estimates are guaranteed, or how they're calculated. For a tool that could influence financial decisions, more context is needed about the estimation's reliability and limitations.

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%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'prompt length and model' which aligns with the 'prompt' and 'model' parameters but doesn't provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Estimate the cost of an AI request before making it' with specific verb ('estimate') and resource ('cost of an AI request'). It distinguishes from sibling tools like 'ask_ai' (executes request), 'check_balance' (checks account status), and 'list_models' (lists available models). However, it doesn't explicitly contrast with these siblings in the description text itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('before making it') suggesting this should be used prior to actual AI requests. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'ask_ai' (which presumably incurs actual cost) or 'check_balance' (which shows current balance). No exclusions or specific scenarios are mentioned.

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

list_modelsA

List all available AI models on SolanaProx with their pricing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the behavioral trait of listing models with pricing, which is useful context. However, it lacks details on potential rate limits, authentication needs, response format, or pagination behavior, leaving gaps in behavioral understanding for a tool that likely involves network calls.

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?

The description is a single, efficient sentence that front-loads the core action ('List all available AI models') and adds essential context ('on SolanaProx with their pricing'). There is zero waste, and every word contributes to understanding the tool's function without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (0 parameters, no output schema) and lack of annotations, the description is minimally complete by stating what it does. However, it could be more complete by addressing behavioral aspects like response format or usage constraints, which are important for a listing tool in an AI service context.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied as it effectively handles the lack of parameters without unnecessary elaboration.

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 description clearly states the specific action ('List all available AI models') and the resource ('on SolanaProx'), with explicit mention of what information is included ('with their pricing'). It distinguishes itself from siblings like 'ask_ai', 'check_balance', and 'estimate_cost' by focusing on model enumeration rather than interaction, balance checking, or cost estimation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying 'available AI models on SolanaProx', suggesting this tool is for discovering models before using them (e.g., with 'ask_ai'). However, it does not explicitly state when to use it versus alternatives like 'estimate_cost' for pricing details or provide any exclusions or prerequisites for usage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Mar 12, 2026
- First observedask_ai
- First observedcheck_balance
- First observedestimate_cost
- First observedlist_models

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: ask_ai for AI inference, check_balance for wallet status, estimate_cost for pre-request pricing, and list_models for model information. The descriptions reinforce these distinct roles, making tool selection unambiguous.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (ask_ai, check_balance, estimate_cost, list_models) with clear, descriptive names. There are no deviations in style or convention, making the set predictable and easy to understand.

Tool Count4/5

Four tools are well-scoped for a server focused on AI inference via SolanaProx, covering core operations like making requests, checking balances, estimating costs, and listing models. It feels slightly thin but reasonable, as it handles the essential workflow without unnecessary complexity.

Completeness4/5

The toolset covers the key aspects of using SolanaProx for AI tasks: making requests, managing costs, and accessing model info. A minor gap exists in lacking tools for transaction history or detailed billing, but agents can work around this with the provided tools for most use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Solana AI Gateway
io.github.Timothymycompc
Wallet-signed Solana RPC for AI agents. No API keys, LLM-safe amounts, pay-per-call in SOL.
1
Omnicall — Agent Tools Gateway A
com.gocreativeai.omnicall
247 LLMs + image/video/voice/music gen + crypto/DeFi/markets/web-search. Pay-per-call USDC, no key.
AI & Machine Learning Cryptocurrency Agent Orchestration
52
TrenchFu — Universal Intelligence Marketplace
io.github.WizzyDev
Intelligence marketplace on Solana — 86 tools, 168+ endpoints, per-call USDC.
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
BridgeNode MCP A
io.github.bridgenode-ai
BridgeNode — x402 pay-per-request AI inference. OpenAI-compatible API + MCP, Solana USDC, gas-free.
AI & Machine Learning Cryptocurrency
311

Related MCP Servers

lightningprox-mcp
Blockchain
unixlamadev-spec
A
license
A
quality
B
maintenance
Description: Pay-per-request access to Claude and GPT models via Bitcoin Lightning using prepaid spend tokens. No accounts, no API keys — just sats.
Updated 6 months ago (2026-03-18 03:03 UTC)
5
21
2
MIT
@portalsprotocol/mcp-serverofficial
Blockchain Autonomous Agents Web3 & Decentralized Tech
portalsprotocol
A
license
Not graded
quality
D
maintenance
Connects AI agents to decentralized, community-built APIs on Solana, enabling autonomous discovery, payment, and execution of tools without subscriptions or API keys.
Updated 9 months ago (2025-11-25 18:10 UTC)
17
MIT
farebox-mcp
fareboxfun
A
license
A
quality
B
maintenance
Connects Claude Desktop, Cursor, or any MCP-compatible client to 36+ frontier LLMs with automatic per-token payments in USDC on Solana.
Updated 2 months ago (2026-07-20 14:08 UTC)
5
6
MIT
farebox-mcp
fareboxfun
A
license
Not graded
quality
A
maintenance
Crypto-native LLM gateway with OpenAI-compatible API and per-token USDC payments on Solana via the x402 protocol.
Updated a month ago (2026-08-09 12:03 UTC)
11,502
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/solanaprox/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SolanaProx MCP Server

What is SolanaProx?

Quick Start

1. Install the MCP server

2. Add to Claude Desktop

3. Add to Cursor

4. Deposit USDC

Tools

ask_ai

check_balance

estimate_cost

list_models

Pricing

Use Cases

Personal AI assistant with micropayments

Autonomous AI agents

Solana app integration

Environment Variables

Standalone Agent Example

Integration Examples

LangChain (Python)

Direct REST API

Security

Links

Built by LPX Digital Group LLC

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@portalsprotocol/mcp-serverofficial

Latest Blog Posts

MCP directory API

`ask_ai`

`check_balance`

`estimate_cost`

`list_models`