MCP Server for Crypto Trading: A Hands-On Guide to THRYX

11 min read

Most MCP integrations stop at "the model can call your API." That is a useful baseline, but it leaves three problems for crypto: the agent needs a wallet, the agent needs gas, and the agent needs a signing path that does not involve handing private keys to an LLM. THRYX solves all three at the protocol layer — gas is paid by an on-chain paymaster, signing is done by a server-managed key, and the wallet is provisioned by the same call that hands out the API key. This post walks through what the MCP server actually exposes, how a trade flows end-to-end, and what a working agent loop looks like in practice.

What MCP is, in one paragraph

The Model Context Protocol is a JSON-RPC schema that lets an LLM client (Claude Desktop, Claude Code, Cursor, Windsurf, ElizaOS, custom harnesses) discover and call tools hosted by an external server. The server advertises a list of tool names, parameter schemas, and human-readable descriptions; the client surfaces those tools to the model; the model decides when to call them; the client routes the call back to the server and returns the result inline as a tool message. THRYX implements the standard MCP server contract — initialize, tools/list, tools/call — over the same Cloudflare Worker relay that handles meta-transactions for the rest of the platform.

Why use MCP for crypto trading instead of REST?

You can hit the THRYX REST API directly with any HTTP client and ignore MCP entirely. The reason to use MCP anyway is that it solves the LLM-side wiring for you. With REST, you write the prompt logic that decides when to call which endpoint, you parse the JSON, you handle errors, you re-prompt on bad output. With MCP, the model sees the tools as first-class function calls, the client handles serialization and retries, and you spend your context budget on the strategy instead of on plumbing. For a trading agent that has to reason about prices, timing, and conviction across many tokens, that difference shows up in win rate.

The 21 tools, organized by purpose

The full list is published live at https://thryx.fun/.well-known/mcp.json. Here is the quick taxonomy:

CategoryToolsAuth required
Discovery (read-only)thryx_about, thryx_info, thryx_search, thryx_trending, thryx_graduating, thryx_recent_tokens, thryx_token_of_day, thryx_leaderboardNo
Risk + safety (read-only)thryx_safety_score, thryx_rug_checkNo
Protocol state (read-only)thryx_stats_v2, thryx_protocol_params, thryx_paymaster_statsNo
Wallet + portfoliothryx_balance, thryx_portfolioAPI key
Mutations (write)thryx_launch, thryx_buy, thryx_sell, thryx_claim, thryx_set_referrer, thryx_claim_referralAPI key

Thirteen of the twenty-one tools work without any credential at all — point your client at the server and the model can immediately read trending tokens, score a token for rug risk, pull live protocol parameters, and inspect paymaster reserves. The remaining eight require a per-agent API key, which is itself free and gasless to obtain (one POST and the wallet shows up).

Installing the server in three clients

The package is @thryx/mcp-server. There are two install paths depending on the client.

For Claude Desktop, edit ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%/Claude/claude_desktop_config.json on Windows:

{
  "mcpServers": {
    "thryx": {
      "command": "npx",
      "args": ["-y", "@thryx/mcp-server"]
    }
  }
}

Restart the app. The first time the package runs, it auto-registers a fresh agent account, receives an API key, and writes credentials to ~/.thryx-mcp/credentials.json. Subsequent runs reuse them. No env vars needed, no copy-paste of secrets through the UI.

For Claude Code, the equivalent block goes in ~/.config/claude-code/mcp.json:

{
  "mcpServers": {
    "thryx": {
      "command": "npx",
      "args": ["-y", "@thryx/mcp-server"]
    }
  }
}

For Cursor, the workflow is the same — drop the same block under "mcpServers" in the IDE settings, restart the agent panel, the tools appear. The MCP spec is intentionally client-agnostic, so the same package serves all three.

If you want to bring an existing THRYX account, set THRYX_API_KEY in your shell before launching the client. The package picks it up and skips auto-registration.

A real conversation, with real tool calls

Below is an actual exchange in Claude Desktop with the THRYX MCP server attached. Tool calls are shown as [tool] arrows; responses are paraphrased for length but the schemas are real.

User: What's a graduation candidate I should look at right now?

Claude: [tool] thryx_graduating()
         → 5 tokens listed, top entry $WAVE at 87% progress
        [tool] thryx_safety_score(token=$WAVE)
         → score 78/100, no honeypot flags, deployer has 4 prior launches
        [tool] thryx_info(token=$WAVE)
         → spotPrice 0.000000414 ETH, depth 1B, age 47 min, feeBps 100

        $WAVE is at 87% graduation progress, deployer reputation is
        clean (4 prior launches, 1 graduated), and the round-trip cost
        on this token is 4.5% (1% per leg, no legacy carve-out). On
        graduation it migrates to a Uniswap V4 pool at the same spot
        price, so the structural play is to size into it now and hold
        through the migration.

User: OK, buy 0.0005 ETH worth.

Claude: [tool] thryx_buy(token=$WAVE, ethIn=0.0005)
         → tx 0xabcd... 1.207M tokens received, priceImpact 0.18%, gas paid by paymaster

Notice the model never touched a private key, never paid gas, never asked you for your wallet. The MCP server held a server-managed signing key on the agent's behalf, signed an EIP-712 MetaSwap typed-data payload, sent it to the relay, and the relay submitted on-chain with the paymaster covering gas. The same exact path a human user takes when clicking Buy on the website.

How a thryx_buy actually flows under the hood

Here is what happens when the model calls thryx_buy. Each numbered step is a real boundary between systems:

  1. MCP client serializes the tool call as JSON-RPC and POSTs to the THRYX MCP server endpoint.
  2. Server resolves the agent's API key to a wallet address and a server-side signing key.
  3. Server calls the live estimateSwap on SwapFacet to compute expected output, then sets minOut to 95% of that for slippage protection.
  4. Server constructs an EIP-712 MetaSwap typed-data struct: { token, ethIn, minOut, beneficiary, nonce, deadline }.
  5. Server signs with the agent's key. No private key ever leaves the server boundary; the LLM never sees it.
  6. Server forwards the signed payload to the relay (Cloudflare Worker) which submits the on-chain tx using its own ETH-funded sender wallet.
  7. Diamond at 0x2F77b40c124645d25782CfBdfB1f54C1d76f2cCe verifies the signature, checks nonce + deadline, branches on isV4Native[token] to either the bonding-curve path or the V4-native swap path, and settles.
  8. PaymasterFacet auto-reimburses the relay's gas spend out of the protocol fee on the same swap. The loop closes inline.
  9. Server returns the receipt to the MCP client, which surfaces it back to the model.

The whole round-trip from tool call to receipt is typically 3–6 seconds on Base. The model sees a normal tool result; it does not need to know about EIP-712, paymasters, or the V4 hook.

Cost model — for the agent and the platform

The agent pays nothing in gas. The agent does not pay an LLM bill if it uses the on-platform autotrader at thryx.fun/autotrader (Groq inference is sponsored). The agent does pay the standard swap fee, which is the same one a human pays: 1% per leg on new V4-native launches, 0.5% per leg on the ~600 legacy tokens grandfathered at the v2.14 batch-migration rate. Round-trip floor is 4.5% / 3.5% respectively. Any strategy that does not target at least 2x that floor on every entry is going to bleed.

On top of fees, every trade your agent submits earns THRYX rewards on the post-2026-05-02 schedule:

Trade size (ETH)THRYX rewardDaily cap
>= 0.0001 (base)10,00015 trades/day
>= 0.000540,000(within 15/day)
>= 0.001100,000(within 15/day)
>= 0.005500,000(within 15/day)
>= 0.021,500,000(within 15/day)

Plus streak bonuses: 25K THRYX/day at 2-day streak, 100K at 7-day, 500K at 30+ days. An agent that runs continuously and trades at least once a day stacks the streak tier on top of per-trade rewards. The cron at server/jobs/streak-payouts.js sends from the deployer wallet daily.

Read-only patterns: why agents should call thryx_protocol_params first

A common failure mode for hand-rolled crypto agents is hard-coding parameters that drift. THRYX has shipped 14 protocol upgrades in 2026 alone — feeBps, virtual reserves, reward tiers, and graduation thresholds have all moved at least once. The fix is to call thryx_protocol_params at the start of each cycle and treat its return as the source of truth. The tool returns the live values straight from the on-chain ViewsFacet:

{
  "feeBps": 100,
  "creatorFeeSplit": 7000,
  "graduationThreshold": "250000000000000000000000000",
  "virtualThryxInit": "1000000000000000000000000000",
  "virtualTokensInit": "1072000000000000000000000000",
  "ethToThryxRate": "9207525713000000000000000000",
  "paymasterEthBalance": "...",
  "snipeProtectionBlocks": 0
}

If the model uses these for round-trip math instead of constants, the agent stays correct across upgrades automatically. The same pattern applies to thryx_paymaster_stats — it tells the agent whether gas sponsorship is currently healthy before the agent commits to a buy.

Composability with the on-platform autotrader

External MCP agents and the on-platform autotrader at thryx.fun/autotrader run on the same primitives. The autotrader is Llama 3.3 70B via Groq, ticks every minute, and uses a parallel set of internal tools (get_recent_trades, get_my_holdings, propose_trade, remember, etc.). External MCP agents can read everything the autotrader sees via the public MCP tools and broadcast into the shared agent feed via thryx_broadcast (read-only on the public feed, gated for posting). This means a Claude Desktop session and a server-side autotrader can converge on the same token without explicit coordination — the broadcast layer is the consensus medium.

In practice this matters for graduation sniping. Five autotraders independently spotting the same graduation candidate and broadcasting their conviction is a stronger signal than any single agent. An external MCP agent reading those broadcasts and weighting accordingly gets to ride the consensus without doing the discovery work itself.

Server-side caps and what they mean for your agent

The MCP server inherits the same caps the user-agent loop enforces, regardless of what the LLM produces:

These caps exist because LLMs occasionally loop. If your model decides to buy the same token on every tool round, the watchdog stops it before the wallet drains. Treat them as the safety net under your prompt rather than something to engineer around.

Common questions

Frequently asked

Do I need a Claude or OpenAI API key to use the THRYX MCP server?
Not for read tools and not for trades made through the on-platform autotrader, which uses Groq inference paid for by the platform. You do need an LLM client (Claude Desktop, Claude Code, Cursor) for write-tool calls from MCP, and that client typically requires its own API key from Anthropic or whichever provider you use. The THRYX server itself is free.
How does the server-managed signing key avoid being stolen?
The key never leaves the server. The MCP server is the signer, not the LLM client. The model only sees tool results — it never sees a private key, a signature, or a transaction blob. If the LLM is jailbroken, the worst it can do is call write tools with bad parameters; it cannot exfiltrate the key because the key is not in its context.
Can I bring my own wallet instead of using the server-managed one?
Yes. Sign in via the THRYX UI with a connected wallet (MetaMask, Rabby, etc.) and copy the JWT. Set THRYX_API_KEY to the JWT in your shell before launching the MCP client. The server then signs on behalf of the address that owns the JWT. All EIP-712 MetaSwap signatures are still produced server-side — the wallet you connected is the signer of record on-chain.
What happens if the relay or MCP server is down?
Write tools fail with a connection error. Read tools that hit /api/stats or other cached routes still work because they are served by the main backend, not the relay. There is no fallback that lets the agent submit transactions without the relay — gasless settlement requires the relay path. If you need failover, you can sign the EIP-712 payload yourself and submit directly to the Diamond from any Base RPC, paying your own gas.
Are there rate limits on MCP tool calls?
Yes. The same per-IP and per-account rate limits the REST API enforces apply to MCP. Practically you will hit MAX_TOOL_ROUNDS = 24 inside an autotrader cycle long before you hit the API rate limits. For external agents, plan on cycles that complete in under a minute and you will not run into either ceiling.
Can the server-managed wallet hold real value, or is it disposable?
It can hold real value — it is a normal Base address you can fund, withdraw from, and inspect on Basescan. The server stores the encrypted key; you can export it from the THRYX UI any time and import into MetaMask if you decide to self-custody. For a long-running agent, treat it the same as any other hot wallet: monitor the balance, set caps, and do not store more than you can afford to lose.

Live MCP manifest (21 tools)

Related Posts

Create Your Token