ProofNetwork's MCP: docs-as-a-tool for building proof-backed Solana apps

ProofNetwork is a serverless JavaScript runtime with a twist: every execution is proof-backed. You paste a contract, get an HTTP endpoint, and each result comes with a cryptographic proof — fairness is verifiable, not promised. It's Solana-integrated, with built-in VRF, sandboxed key storage, and DEX/launchpad APIs.

But the interesting thing for a developer in 2026 isn't the runtime — it's how ProofNetwork expects you to learn it. Instead of a docs site you read, it ships an MCP server your coding agent reads. This is the "docs-as-a-tool" pattern, and ProofNetwork is a clean example worth dissecting.

The server

It lives at https://proofnetwork.lol/api/mcp, speaks Streamable HTTP (JSON-RPC over POST, responses as SSE), and identifies itself on initialize as:

{
  "protocolVersion": "2024-11-05",
  "capabilities": { "tools": { "listChanged": true },
                    "resources": { "listChanged": true } },
  "serverInfo": { "name": "proofnetwork-skills", "version": "1.0.0" }
}

Add it to Claude Code in one line:

claude mcp add --transport http proofnetwork https://proofnetwork.lol/api/mcp

Four tools, zero side effects

Notably, none of the tools execute code or move funds — taskSupport: "forbidden" on every one. They only read documentation. The whole server is a token-efficient lens onto a ~96KB skill doc:

• list_skills — every skill with title, byte size, and its table of contents. "Call this first to discover what is available."
• get_skill — the full markdown of one skill (it warns you the contract skill is ~90KB and "burns a lot of tokens").
• get_skill_section — a single heading-bounded section. Case-insensitive with substring fallback, so "VRF" resolves to "VRF (Verifiable Random Functions)."
• search_skills — substring search across skills, returning hits with their enclosing heading and context lines.

That four-tool shape — list → search → section → full — is the template for any docs-as-MCP server. It lets an agent pull exactly the 300 tokens it needs instead of inhaling a 90KB file, which is the difference between a usable tool and a context-window bomb.

What the skills actually teach

Two skills are served: proofnetwork-contract (the "Contract Expert," 54 sections) and proofnetwork-frontend. The first defines the mandatory contract shape — a state object plus lifecycle functions, no imports, no boilerplate runtime:

const state = {
  metadata: { name: "Coin Flip", description: "Provably-fair flip", version: "1.0.0" },
  deployer: null,
}

function onDeploy(inputs) {
  state.deployer = inputs.deployer        // wallet that deployed
  // const kp = blackbox.generateSolanaKeypair()  // optional house wallet
  return { success: true, message: "deployed" }
}

// every other exported function becomes an HTTP endpoint

The section list reads like an on-chain app's shopping list: Blackbox (key storage), UMI (Solana transactions, umi.safeSend, atomic multi-transfers), VRF, Pump.fun and Bags.fm (bonding-curve launches/trading), OKX DEX (swaps), signature verification, timers, background tasks, and a @parallel directive for concurrent execution.

VRF — randomness that ships with a proof

The verifiable-randomness API is the core primitive. Every call returns a result and a proof string:

const num   = await vrfApi.selectNumber(0, 24)       // { result: N, proof: "..." }
const picks = await vrfApi.selectFromArray(arr, 3)   // { result: [...], proof: "..." }

// house-edge profiles for games:
const win  = await vrfApi.selectProfile("fG0jD2")            // 50% win, { result: bool, proof }
const roll = await vrfApi.selectProfileRange("wD2hP5", 1, 100, true)  // 90% win, high=win

The proof is what makes the outcome auditable after the fact — a player can verify the flip wasn't rigged. That's ProofNetwork's whole pitch in one return value.

Blackbox — secrets that structurally can't leak

For an app that signs Solana transactions, key custody is the hard part. ProofNetwork's answer is the blackbox: a per-contract secret store the skill documents with an unusually precise security model.

• Sandboxed per contract — blackbox.getKey(0) always means this contract's key; there's no API to read another's.
• generateSolanaKeypair() returns only { id, publicKey } — the secret bytes never leave the sandbox, not via any read endpoint, websocket, webhook, or tx log.
• Function name, inputs, and result are logged; blackbox values are never serialized into a response.

Why route docs through MCP at all

Three concrete wins, and they generalise well beyond ProofNetwork:

• Always-current. The agent reads the live server, not a months-old copy of the docs baked into its training data. Ship a new API, the next search_skills call sees it.
• Token-bounded. A 96KB skill never enters context whole. The agent searches, reads one section, writes the contract.
• Authoritative patterns. ProofNetwork's contracts have a mandatory structure and "critical rules." Serving those through a tool the agent must consult is far more reliable than hoping it remembers the right shape.

The honest read

This MCP is a documentation server, not an execution server — every tool is read-only (taskSupport: forbidden). It makes your agent good at writing ProofNetwork contracts; deploying and calling them still happens through ProofNetwork's normal HTTP API. That's a sensible boundary (no agent is moving funds through this server), but don't expect it to run anything.

ProofNetwork itself is a centralised, proprietary runtime — "contract" is branding for a sandboxed serverless function, not an on-chain Solana program. The proofs make individual executions verifiable, but you are trusting ProofNetwork's platform to run the code and guard the blackbox. For provably-fair games and agent backends that need VRF plus custodial signing without standing up infra, that trade is reasonable; for trustless DeFi it isn't the same thing as a deployed program.

References

• proofnetwork.lol — the runtime
• https://proofnetwork.lol/api/mcp — the MCP server (Streamable HTTP)
• github.com/proofnetworks
• Solana AI agents — the broader landscape

The pattern is the takeaway: if your protocol wants agents building on it, the most useful thing you can ship isn't an SDK — it's an MCP server that hands the agent exactly the docs it needs, one section at a time.