Solana MCP Servers — Connecting AI Agents to On-Chain Tools | BoltTx Blog

If you're building AI-powered applications that need to interact with Solana, you'll eventually run into MCP (Model Context Protocol). It's the standard for connecting language models to external tools — and for Solana, that means an MCP server is what lets an AI agent query chain state, simulate transactions, and submit them.

This piece covers what Solana MCP servers are, what they expose, and the infrastructure decisions that distinguish toy demos from production-grade deployments.

What MCP Is, Briefly

Model Context Protocol (MCP) is a protocol for language models to call external tools. You define tools your model can use; the model decides when to call them; the protocol handles the call/response handshake.

For Solana specifically, an MCP server might expose tools like:

get_account_info(address) — query account state
get_token_balance(wallet, mint) — query token holdings
get_pool_state(pool_address) — query DEX pool reserves
simulate_swap(input, output, amount) — return expected output
submit_transaction(serialized_tx) — execute a transaction
query_recent_transactions(address) — recent activity

The agent uses these tools as part of its reasoning. The execution flow looks like:

Agent decides it needs information
Agent calls the appropriate MCP tool
MCP server executes the tool, returns the result
Agent uses the result to decide what to do next

This is much cleaner than embedding raw RPC calls in prompts. The structure constrains what the agent can do; it scales to many capabilities without prompt bloat.

Why MCP for Solana Specifically

A few reasons MCP is well-suited for Solana agentic use:

Solana's RPC is rich. Many methods, many account types, many possible queries. MCP gives the agent a curated subset.

Action latency matters. Solana has fast slots; the agent's tools should be fast too. MCP's structured calls are faster than agent-parses-prompt-output approaches.

Composability. Solana programs interact in complex ways. MCP tools can compose multiple RPC calls into useful agent-facing operations.

Type safety. MCP supports structured inputs/outputs. The agent gets clean data structures, not raw JSON.

For agentic applications on Solana — trading agents, research agents, on-chain analytics agents — MCP is the right architectural primitive.

What a Production Solana MCP Server Needs

Building one is straightforward; making it production-grade is harder. The pieces:

Robust RPC backend. Every MCP tool call ultimately translates to RPC calls. The MCP server's quality is bounded by the RPC's quality.

Caching where appropriate. Not all data changes every slot. Cache slow-changing state (token metadata, program owners) and avoid re-querying.

Rate limiting. Agents can be quite chatty. Without rate limiting, an agent loop can hit RPC limits fast.

Authentication. Production agents shouldn't have unrestricted access. Per-agent API keys, per-tool authorization.

Logging. Every tool call should be logged with full context. For debugging agent behaviour, this is essential.

Error handling. Solana errors are sometimes cryptic. Translate them into agent-friendly responses.

Transaction safety. Tools that submit transactions need extra guards — position size limits, daily loss limits, allowlisted target programs.

Tools Worth Exposing

A reasonable starting tool set:

# Read tools (low risk)
get_balance(address) -> SOL balance
get_token_balance(wallet, mint) -> token balance
get_account_info(address) -> account data (decoded if possible)
get_recent_transactions(address, limit) -> recent activity
get_pool_state(pool_address) -> reserves, recent trades
get_token_info(mint) -> metadata, holder distribution

# Simulation tools (low risk)
simulate_swap(input, output, amount) -> expected output, price impact
estimate_priority_fee() -> recommended priority fee for current network state

# Action tools (higher risk - need guards)
submit_swap(input, output, amount, slippage) -> signature
submit_transaction(serialized_tx) -> signature
sign_message(message) -> signature

# Specialised
get_smart_money_signals() -> wallets/tokens worth watching

For action tools, hard guards are mandatory: position size limits, allowed-program lists, daily transaction caps. The agent should not be able to bypass these via clever prompts.

Common Mistakes Building MCP Servers

Exposing too much. "Submit any transaction" is too broad. Constrain to specific operations.

No rate limiting. Agents loop. Loops can call tools fast. Without limits, you'll exceed RPC quotas.

Returning raw RPC errors. "InstructionError [3, 'Custom: 0x1771']" tells an LLM nothing useful. Translate.

Synchronous-only tool calls. Some Solana operations are slow (transaction confirmation). Provide async patterns where appropriate.

No authentication. MCP servers exposed to the internet without auth get abused. Per-agent keys at minimum.

No tool versioning. When tool signatures change, agent behaviour breaks. Version your tools and provide migration paths.

Insufficient logging. When the agent does something weird, you need to know what it called and what it got back. Log everything.

How RPC Choice Affects MCP Performance

Every MCP tool call eventually calls RPC. The RPC's properties propagate:

RPC latency adds to tool latency — slow RPC = slow agent
RPC reliability becomes tool reliability — flaky RPC = flaky agent
RPC method support determines tool capabilities — what RPC can do is what tools can do
Anti-MEV at the RPC layer means agent transactions aren't sandwiched — without it, the agent's submit_transaction tool is a sandwich target

For agents that submit transactions, the write RPC must have Anti-MEV routing and sub-second confirmation. For agents that read heavily, the read RPC must have generous rate limits and good performance.

Architectural Patterns

A typical production MCP-Solana setup:

AI Agent (any MCP-compatible language model)
    ↓ MCP protocol
MCP Server
    ↓ HTTPS
Read RPC (for queries)
Write RPC (for sends, with Anti-MEV)
    ↓
Solana network

The MCP server is the orchestration layer. It handles tool calls, caches where appropriate, applies rate limits and auth, and routes to the right RPC.

For trading-focused agents, the write RPC is the critical piece. That's where transactions actually become reality.

What to Do This Week

If you're building a Solana MCP server:

Start with read-only tools. Get the agent integration working before adding action capabilities.
Pick a good RPC backend. The MCP server's quality is bounded by the RPC's.
Add rate limiting from day one. Agent loops will surprise you.
Translate errors helpfully. Don't pass raw RPC errors to the LLM.
For action tools, build guards. Position limits, allowlisted operations, daily caps.
Log every tool call. Essential for debugging.
Test with realistic agent workloads. Not just synthetic calls — real LLM-driven traffic.

Try BoltTx as Your MCP Server's Write Backend

For agentic applications that submit transactions:

import { Connection } from "@solana/web3.js";

const writeConnection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

// In your MCP server's submit_transaction tool:
async function submitTransaction(serializedTx) {
  const tx = VersionedTransaction.deserialize(serializedTx);
  const signature = await writeConnection.sendTransaction(tx, {
    skipPreflight: true,
    maxRetries: 0,
  });
  return signature;
}

Native Anti-MEV routing protects agent-driven transactions from sandwich attacks. Sub-second confirmation makes the agent feel responsive. Per-signature telemetry lets you debug what the agent actually did.

Free tier signup — adequate for evaluation and small production.

FAQ

What's the difference between MCP and a regular API? MCP is structured for LLM tool use. Regular APIs are for human-coded clients. MCP makes the agent's call/response loop clean.

Can I use MCP without being tied to a specific LLM? The protocol is open. Any system that implements MCP can use the tools.

Do I need to write an MCP server from scratch? Existing SDKs handle the protocol layer in Python, TypeScript, and other languages. For Solana specifically, writing custom tool definitions on top of the SDK is the typical pattern.

Should action tools have human-in-the-loop? For high-value or high-risk actions, yes. The agent proposes; a human approves. Lower-risk actions (small position trades, info queries) can be fully autonomous within guardrails.

How do I handle agent runaway loops? Iteration limits in your agent framework. Rate limits in the MCP server. Daily loss caps for trading agents. Multiple layers.