MCP vs Helius REST: why Solana agents need the protocol

The Solana data layer has gone through three eras. Raw RPC (run your own validator, parse the JSON-RPC, build your own indexes). Hosted RPC + indexer APIs (Helius, Bitquery, Birdeye, GMGN — REST or GraphQL surfaces over indexed Solana data). And now MCP — a protocol-level surface designed specifically for AI agents to consume.

I see a lot of "isn't MCP just another Helius REST endpoint?" takes. They miss the point. This post walks through why MCP is structurally different from REST/GraphQL and why every serious Solana AI agent integration converges on it within a release cycle.

The three eras, briefly

Raw RPC. You run a Solana validator (or rent one from Triton/Helius), subscribe to the gossip layer, parse every block, write your own database schema, write your own query layer. Maximum control, maximum operational tax, and you need to be a real systems team.

Hosted indexer APIs. Helius indexes Solana for you and exposes REST + webhooks. Bitquery exposes GraphQL across Solana. Birdeye and GMGN have their own REST/aggregator surfaces. You get pre-indexed Solana data via a hosted query surface. This is where 90% of Solana products sit today.

MCP servers. Tool-shaped surfaces designed to be called by AI agents. Same underlying indexed Solana data as the era-2 APIs — but the contract is "the agent picks what to call based on the user prompt," not "the dev hardcodes which endpoints to hit."

The structural difference

Take a concrete workflow — "tell me which fresh pump.fun launches the dev still holds >50% of, with at least 100 holders, in the last 30 minutes."

With Helius REST, your code:

const launches = await fetch(`https://api.helius.xyz/pump/launches?since=30m`).then(r => r.json());
const filtered = [];
for (const l of launches) {
  const holders = await fetch(`https://api.helius.xyz/token/${l.mint}/holders`).then(r => r.json());
  if (holders.length < 100) continue;
  const devHold = holders.find(h => h.address === l.dev)?.pct ?? 0;
  if (devHold >= 50) filtered.push({ ...l, holders: holders.length, devHold });
}
return filtered;

You wrote that code. You decided which endpoints to hit, in what order, with what filters. The user types one query; your hardcoded pipeline runs.

With MCP, the user (or upstream agent) types:

> "Use techkern to find fresh pump.fun launches where dev still holds >50% with at least 100 holders, in the last 30 minutes."

The LLM reads its tool list. Picks query_pump_fun_launches(window_minutes=30, min_holders=100). Gets the list. Picks holder_distribution for each result. Filters where dev hold >= 50%. Returns the filtered list to you, the user.

You did not write the pipeline. The agent composed it from MCP tools based on the user's intent.

This is the structural shift. REST / GraphQL serves human-authored code. MCP serves agent-authored code.

Why agent-authored composition matters

Two reasons.

First, the long tail of one-off queries. With REST you have to hardcode every query shape into your product or build a generic query builder UI. The first does not scale; the second is a worse UX than a chat box. With MCP the chat box is the query builder.

Second, the cost of changing query shape. If the user asks a follow-up — "now also include the dev wallet's last 20 launches and their outcomes" — REST means you ship a code change. MCP means the agent makes one more tool call (dev_token_history) on the next turn. Zero deploy.

What about the obvious objections

"Helius REST is faster than letting a model decide." True for fixed workflows. False for variable workflows. If your product has one query shape, hardcode it. If it has fifty, the model will pick faster than you can ship fifty endpoints.

"REST is cheaper than running a model in the loop." Also true for fixed workflows. For variable workflows, the model cost is the cost of UX flexibility you would otherwise pay in engineering hours.

"GraphQL already does composition." GraphQL composes fields within a fixed schema. MCP composes tool calls across an open tool set. Different scale of composition. GraphQL is "let me pick which fields of a known shape I want." MCP is "let me pick which tools to call and how to chain them based on user intent."

"MCP is too new." It is 18 months old as of May 2026. Every major coding tool ships with it native. The protocol is stable and Anthropic-maintained but multi-vendor (OpenAI Agents SDK speaks it, so does Continue, so does Cursor). The WebMCP browser-side complement landed in May 2026. It is no longer "too new."

"SKYAI proved this works on BSC." Correct — and the Solana side of the same opportunity is wider. SKYAI broke CMC Top 100 with +245% in 7 days mostly on BSC volume. Solana has 3-5x the on-chain activity volume; the MCP layer here is the same idea executed on the larger market.

When raw RPC / Helius REST still wins

• Latency-critical (sub-100ms). MCP adds ~30-50ms over a direct call. For first-block sniping, you go direct.
• Cost-critical at extreme volumes. We charge per query; if you do 100M queries/month, our list pricing loses to direct Helius. We have an enterprise tier for that case.
• Server-to-server pipelines with zero LLM in the loop. If you have no model and never will, MCP is the wrong abstraction — use Helius REST.

For everything else — interactive agents, alerting, research, copy-trading, DD pipelines, KOL tracking — MCP wins on integration speed and runtime flexibility.

How the techkern MCP server is built

Under the hood: ClickHouse cluster (4 indexer shards — DEX swaps / pump.fun / holders / KOL wallets) holding 247B+ indexed Solana rows. Rust indexers per source subscribing to the source-of-truth feed (Helius for RPC, Jito for MEV bundles, custom listener on the pump.fun bonding-curve program, account subs on tracked KOL wallets). The MCP server itself is a thin TypeScript layer using the official Anthropic MCP SDK, translating MCP tool calls into parameterized ClickHouse queries.

The same data could be (and is) exposed via REST for legacy integrations. The MCP surface is the same indexed data, recontextualized for agent consumption.

The takeaway

MCP is not "Helius REST but newer." It is the surface designed for the case where an LLM is doing the calling. If you are building anything where a model is on the user side of the request, MCP collapses your integration to one install. If you are not — stick with Helius. Both will keep existing.