Molpha MCP
OfficialEnables AI agents to create, fetch, verify, and publish Molpha oracle data on Solana, including deriving feed IDs, reading feed state, submitting signed data updates, and reading latest values from Solana feed accounts.
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., "@Molpha MCP fetch verified ETH/USD price on Solana"
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.
Molpha MCP
A Model Context Protocol (MCP) server that lets AI agents fetch signed Molpha oracle data, publish it on Solana, and build verifier calldata for EVM and Starknet.
Molpha turns HTTP API responses into threshold-signed payloads that can be verified on Solana, EVM, and Starknet. This server exposes that workflow as MCP tools, with signing behind a local, Privy, or Turnkey wallet, or, on mcp.molpha.io, behind your own wallet.
This release targets Solana Devnet and Sepolia verifier networks. Treat it as testnet software, not a production security boundary. Write tools spend SOL, and round tools may consume subscription quota or pay USDC for x402 rounds, unless dry-run mode is enabled.
Quick start
Two recommended ways to connect:
Install | Nothing: add the URL to your client |
|
Signer | Your own wallet. The server holds no key. | Local keypair, Privy or Turnkey, held by the server |
Subscription rounds | Sign in with SIWX, then |
|
Spending limits | Your wallet's own policy | Dry-run lock and daily caps in the server |
Best for | Getting started, agents that bring their own wallet | Unattended agents, private API sources |
mcp.molpha.io
Nothing to install, and no keys to hand over. Add the URL to your client.
Claude Code:
claude mcp add --transport http molpha https://mcp.molpha.io/mcpCursor (.cursor/mcp.json):
{ "mcpServers": { "molpha": { "url": "https://mcp.molpha.io/mcp" } } }The read tools work straight away. The server has no wallet of its own, so name the one you mean: submitter for describe_feed and get_latest_value, payer for get_x402_status.
Anything that needs a signature is returned for your own wallet to sign, so each such operation is two or three tool calls around one signature:
Operation | Tools, in order | The wallet signs |
Subscription round |
| A text message, once per session |
x402 round |
| A USDC transfer, not broadcast |
Solana submit |
| The submit transaction |
autoSubmit, dryRun and encryptSecrets are not offered here. Set spending limits in the wallet's own policy, and use the local server for private API work.
Sign in with your wallet (SIWX)
A subscription round on mcp.molpha.io is authorized by a sign-in session: the wallet signs one Sign-In-With-X text message (the x402 sign-in-with-x extension, in its Solana form), and the gateway issues a short-lived bearer token. The message is not a transaction and moves no funds.
Step | Call | Result |
1 |
| Whether the wallet is a subscription |
2 |
| The |
3 | The wallet signs | An Ed25519 signature over its exact UTF-8 bytes |
4 |
| A |
5 |
| The signed attestation and verifier arguments |
Who can sign in. The subscription owner, or a delegate the owner added with
add_delegate. A delegate passes the owner's address asowner.How to sign. The message as returned: raw UTF-8, no prefix, no envelope, no trailing newline. The signature may be base58, base64 or hex.
solana sign-offchain-messagewraps the text and is refused withinvalid_signature.What the token is. A credential for one wallet and one gateway, valid 30 minutes by default and never past the subscription term. It only identifies the caller: the gateway re-reads the subscription and delegate from chain on every round, so
remove_delegateends access whatever tokens exist. It passes through this server and is never stored or logged.What it needs. A gateway with
sessionAuth: trueinGET /v1/info. Otherwisebegin_sessionanswerssessions_unavailableand x402 rounds remain available.
The full walkthrough, with a signing example, delegate setup, gateway routes and error codes, is in docs/integration.md.
Local (stdio)
The server runs on your machine and holds the signer, so one tool call runs a round or submits to Solana, and MOLPHA_DRY_RUN keeps every write a preview until you turn it off.
Needs Node.js 24 or later. Nothing to clone or build.
1. Look around, no wallet. Read-only: capabilities, providers, sourceIds, prices, feed values.
claude mcp add molpha -- npx -y @molpha/mcp@0.2.0 --read-only2. Build with a testnet wallet. Put your signer settings in a .env file (see Setup), then check them. The doctor prints a ready-to-paste config for your client, with secrets left as placeholders:
npx -y @molpha/mcp@0.2.0 doctorA config like this keeps every write a preview (MOLPHA_DRY_RUN=true):
claude mcp add molpha -e SIGNER_BACKEND=keychain -e KEYCHAIN_BACKEND=privy -e PRIVY_APP_ID='<privy-app-id>' -e PRIVY_APP_SECRET='<privy-app-secret>' -e PRIVY_WALLET_ID='<privy-wallet-id>' -e PRIVY_WALLET_ADDRESS='<base58-solana-address>' -e MOLPHA_DRY_RUN=true -- npx -y @molpha/mcp@0.2.03. Spend only when you mean to: fund the wallet, then set MOLPHA_DRY_RUN=false in the server's config. The full guide, with Cursor, VS Code, Codex and Claude Desktop, is docs/integration.md.
With no signer configured the server starts read-only and offers only the read tools (runLevel: "read-only" in get_capabilities). --read-only or SIGNER_BACKEND=none forces it.
Related MCP server: Pangle Coordinator
Tools
Tool | Access | Description |
| Read | Run level, program id, registry version, nodes, gateways, chains, verifier addresses, x402 caps and source-payment policy. |
| Read, local | Derive an |
| Read | Read the Solana feed for |
| Read | Read the latest attested value stored in a Solana feed account. |
| Read | Whether a wallet is a subscription owner or delegate, with the plan's and the delegate's limits. |
| Read | Quote the next x402 round, show where payment goes, and read a payer's USDC balance and remaining daily budget. |
| Read | The data providers the gateway integrates and the flows it serves (providers). |
| Read | One provider's flows, disclosure and ready-made feeds, each with a complete |
| Read | Price a paywalled source with one unpaid request, including the worst-case total. |
| Spends quota | Run a round paid from a USDC subscription; return the signed attestation plus verifier arguments. |
| Spends USDC | Run a round paid per request over x402; same output. |
| Read, local | Build EVM/Starknet verifier address and |
| Write | Submit a signed attestation to Solana. Accepts a round tool's output unmodified. |
On mcp.molpha.io the one-call round and submit tools become prepare/sign/execute pairs (above). Every tool returns structuredContent and carries MCP annotations; see Structured output and annotations. For tolerance-mode aggregation and the full configuration table, see docs/reference.md.
Round timing. Rounds run on a fixed 100 ms tick. Requests for one feed (the same source and quorum) inside one tick share a round, so a feed runs at most 10 rounds per second, and one wallet gets at most one round per tick for a feed: a second request in the same tick is answered with HTTP 409, which the round tools retry a tick later before failing with round_conflict. See Round timing.
Setup
For the local server.
Signer. Put your settings in a .env file and check them with the doctor. It prints a ready-to-paste config for your client with secrets left as placeholders. Use a dedicated testnet wallet.
SIGNER_BACKEND=memory
OWNER_KEYPAIR=/absolute/path/to/owner-keypair.json
SOLANA_RPC=https://api.devnet.solana.com
MOLPHA_DRY_RUN=truePrivy and Turnkey settings are in docs/reference.md and .env.example.
npx -y @molpha/mcp@0.2.0 doctorDry-run lock. MOLPHA_DRY_RUN=true locks execute_subscription_round, execute_x402_round and submit_attestation to previews. A call with dryRun: false is refused with dry_run_locked, so going live is a change to the server's config, never to one tool call.
Subscription. Subscribing debits USDC, so it is kept out of the MCP tools and runs as a CLI command with the same signer configuration. --max-price-usdc is a cap in USDC base units (6 decimals); drop --dry-run to subscribe, or use extend to extend one.
npx -y @molpha/mcp@0.2.0 provision subscribe --plan Basic --max-price-usdc 20000000 --dry-runClient. Every client launches the local server with npx. Snippets for Claude Code, Cursor, VS Code, Codex and Claude Desktop are in docs/integration.md, ready-to-edit copies are in examples, and Claude Desktop users can install the molpha-mcp.mcpb bundle attached to each release.
Example prompts
Discover. Use Molpha to inspect the current oracle capabilities. Summarize the registry version, node count, chains, gateways, and verifier addresses. Make no writes.
Derive. Derive a Molpha sourceId for
https://api.example.com/v1/finalized/priceusing the JSON path$.price. Show me the canonical JSON and the sourceId. Do not send a transaction.
Fetch. For that source, run a subscription round with 3 signatures for the EVM chain. Summarize the value, timestamp, registry version and verifier call. Treat the signed attestation as the trust anchor, not the value alone.
Provider. List the integrated data providers, describe TickerLayer's
btcusdfeed, and run it with 3 signatures for Solana, passing theapiConfigexactly as given.
Check spend. Call
get_x402_statusfor 3 signatures. Tell me the price, where payment goes, and my USDC balance before I authorize anexecute_x402_round.
Publish. If I give you a newer signed attestation, preview
submit_attestationwithdryRun: true, explain the exact write, and wait for my confirmation before submitting.
Use a public endpoint that returns stable, independently reproducible data: live ticker endpoints may differ across oracle nodes and fail to reach quorum.
How it works
flowchart LR
Client["MCP client"] <-->|"stdio / HTTP"| Server["Molpha MCP server"]
Server --> Guardrails["Dry-run · daily caps · spend caps"]
Server --> Signer["Signer adapter<br/>local · Privy · Turnkey"]
Server --> SDK["Molpha SDK / x402 client"]
SDK --> Gateway["Molpha gateway"]
Gateway <--> Nodes["Oracle node quorum"]
SDK <--> Solana["Solana program<br/>feeds · subscriptions"]
Gateway --> Artifact["Threshold-signed attestation"]
Artifact --> Server
Server --> Args["EVM / Starknet verifier args,<br/>or submit_attestation on Solana"]The server is an adapter and policy boundary, not a new source of truth. Oracle nodes independently fetch the committed API configuration and produce one aggregate signature after reaching quorum; the server returns that self-contained signed artifact. Consumers trust a value only after verifying the signed payload against its registry version.
Development
git clone https://github.com/molpha/mcp.git
cd mcp
npm ci
cp .env.example .env
npm run buildPoint a client at the built server with node /absolute/path/to/mcp/dist/src/server.js.
npm run dev # start from TypeScript
npm run typecheck && npm test && npm run build # run before opening a pull request
npm run gen:install # rewrite the generated install snippets in the docs and examples
npm run smoke:pack # pack the tarball and run it with npx over stdio (needs network)
npm run pack:mcpb # build the Claude Desktop bundle from an allowlist@molpha/sdk is pinned to an exact version and resolved from the npm registry; to try a local checkout run npm install ../sdk and do not commit the result. Install snippets are generated from src/install-config.ts: edit the renderers, not the generated text, because npm test fails when a generated file is out of date.
Versioning and publishing use Changesets: if a pull request changes published behavior, run npx changeset. On merge to main, release.yml opens a "Version Packages" PR and, when that merges, publishes @molpha/mcp to npm (trusted publishing, no token) and server.json to the MCP registry.
Bug reports and focused pull requests are welcome. For security issues, use GitHub's private vulnerability reporting instead of a public issue.
Documentation
Integration guide: install per client, spending, signing in with your own wallet (SIWX), and running the HTTP server yourself
Reference: sourceId, tolerance mode, x402, providers, configuration, signers
License
Released under the MIT License.
Available Tools
8 toolsmolpha_agent_statusGet x402 agent escrow statusA
Read the caller's x402 agent escrow (advisory: USDC ATA balance, amount committed to unsettled rounds, unsettled round count) and the next round's quoted price for a given quorum. Escrow is derived server-side per (payer, gateway). A non-existent escrow is normal pre-first-round — it's created lazily. Call before payment: "x402" fetches to see whether the escrow is already funded, or to pre-fund it out of band.
Inputs: signaturesRequired.
molpha_derive_feedDerive Molpha feedIdA
Locally derive the feedId for a declarative spec (apiConfig + quorum) — no transaction, no subscription required. feedId = keccak256(owner || apiConfigHash || signaturesRequired); the feed itself is created lazily on-chain at first settle (subscription or x402 round). Call this to preview a feedId before molpha_fetch_verified, or to check what feedId a given spec resolves to for the current signer. Prefer settled/finalized data — independent nodes must converge on a byte-identical value to co-sign.
Inputs: apiConfig (required), signaturesRequired (required), rejectNonDeterministic.
molpha_describe_feedDescribe Molpha feedA
Read a feed's on-chain state (last committed value, registryVersion, signaturesRequired) and the caller's subscription status. Pass feedId directly, or apiConfig + signaturesRequired to derive it first (see molpha_derive_feed). A missing feed account is normal pre-first-settle — feeds are created lazily. feed.valueKind is the attested encoding of the stored bytes ("value" = raw payload, "hash" = keccak digest), NOT a scale hint: Molpha attests no decimals on-chain. When apiConfig is supplied, valueEncoding reports the off-chain valueTransform that produced the number, explicitly flagged as unattested.
Inputs: feedId, apiConfig, signaturesRequired.
molpha_executeExecute Molpha data update on SolanaA
Submit a signed DataUpdate to the Solana feed via submit_data_update. Pass the output of molpha_fetch_verified through unmodified — both the artifact shape ({ dataUpdate, signature }) and the flat shape ({ s, commitmentAddr, timestamp }) are accepted, and short hex fields are zero-padded server-side. Permissionless on-chain; the owner key pays SOL fees. EVM/Starknet execution is deliberately out of scope (see molpha_verify) — use the verifier args from molpha_fetch_verified and call verify() yourself.
Inputs: result (required), dryRun.
molpha_fetch_verifiedFetch verified Molpha dataA
Trigger a signing round for a feed and return the self-contained signed payload PLUS prebuilt verifier arguments for each requested chain. The signed payload is the trust anchor — verify it or forward it to a contract; do not consume value alone. Only the solana leg can be settled from this server (via autoSubmit, or by passing this tool's output to molpha_execute unmodified); evm and starknet return contract-ready calldata only — executing verify() there is the agent's job by design (see molpha_verify). payment selects how the round is paid for: "subscription" uses the caller's active USDC subscription (fails if inactive), "x402" self-funds a per-request escrow (auto-funds up to the MOLPHA_X402_MAX_PRICE_USDC / MOLPHA_X402_MAX_SPEND_PER_DAY_USDC caps), and "auto" (default) uses the subscription when active and falls back to x402 otherwise. feedId is derived from apiConfig + signaturesRequired + the signer's pubkey when omitted (see molpha_derive_feed).
Inputs: chains (required), apiConfig (required), dryRun, feedId, +5 more.
molpha_get_capabilitiesGet Molpha capabilitiesA
Returns the current Molpha verification surface: active registryVersion, registered node set, gateway endpoints, supported chains, signing scheme, and x402 spend caps. Call first to learn where a signed result can be verified.
Inputs: includeAbi.
molpha_get_latestGet latest Molpha feedA
Read the latest on-chain feed account for a Molpha feedId. valueKind is the attested encoding of the stored bytes ("value" = raw payload, "hash" = keccak digest) — it is not a scale hint. Molpha does not attest decimals on-chain; see molpha_describe_feed's valueEncoding for the (unsigned) apiConfig provenance.
Inputs: feedId (required).
molpha_verifyVerify Molpha resultA
Build the verifier address and call args for a signed DataUpdate on EVM or Starknet. This tool stops at calldata by design, not by omission: the Molpha verifier is stateless, so the agent (or its contract) executes verify() itself and the server never submits an EVM/Starknet transaction or vouches for a result it did not verify on-chain. There is no EVM/Starknet execution path anywhere in this MCP server. For Solana, submit the DataUpdate via molpha_execute (or molpha_fetch_verified autoSubmit) and read it back with molpha_get_latest — there is no separate simulate-verify path. Accepts the dataUpdate/signature objects from molpha_fetch_verified verbatim; short hex fields are zero-padded to their canonical widths server-side.
Inputs: chain (required), signature (required), dataUpdate (required), includeAbi.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 8 tools
Most tools have clear distinct purposes (e.g., derive_feed vs fetch_verified, verify vs execute), but there is some overlap: describe_feed also provides the latest committed value and can derive feed IDs, making it partially redundant with get_latest and derive_feed. The detailed descriptions help differentiate, but an agent might still hesitate between get_latest and describe_feed for reading a value.
All tools share the 'molpha_' prefix and most follow a verb_noun pattern (get_latest, describe_feed, derive_feed, fetch_verified). However, 'molpha_verify' and 'molpha_execute' are bare verbs, and 'molpha_agent_status' is noun_noun, so the pattern is not fully consistent. Still, the naming is predictable and readable overall.
With 8 tools, the server is well-scoped. Each tool covers a distinct operation in the Molpha workflow: reading state, deriving IDs, checking capabilities, fetching verified data, building calldata, and submitting to Solana. There are no redundant or extraneous tools.
The core lifecycle is covered: derive feed ID, fetch verified data, verify on EVM/Starknet, execute on Solana, and read back the result. Minor gaps exist, such as no explicit subscription management (though subscription status is readable) and no historical data access, but these are acceptable for the server's apparent purpose.
Maintenance
Related MCP Connectors
MCP server for the Z1N Protocol - on-chain identity for AI agents on Polygon
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP Server for AI agent identity and authorization. Create, verify, and manage agent identities with trust scores and scoped authorization tokens.21 PyPIMIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server for coordinating a permissionless swarm of AI agents to discover, investigate, and synthesize on-chain anomalies across EVM chains. Agents authenticate via off-chain ECDSA and earn reputation through useful contributions.MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server enabling AI agents to browse, claim, submit, and manage paid tasks on the SYNAI Relay agent-to-agent task protocol, with on-chain USDC settlement via x402.MIT

AgentPump MCP serverofficial
AlicenseNot gradedqualityDmaintenanceMCP server for the AgentPump agent economy, enabling live market data reads and autonomous agent operations on Solana.72 npmMIT