Vealth MCP server for GMX v2, live — try it yourself, no signup

Feature Discussion
1

GMX v2 MCP server, live — try it yourself, no signup

brawlaphant here (EcoWealth / Vealth).

GMX’s own AI Agents docs say the official MCP server is “under development and not yet available.”

So we built one and put it live.

Try it right now — no signup, no key:

curl -X POST https://vealth.net/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"gmx_get_prices","arguments":{}}}'

That’s a real call against live GMX v2 Arbitrum oracle prices right now.

Point any MCP client at Connect your AI · Vealth .

The tools show up in tools/list alongside our other public tools.

Five tools:

  • gmx_get_positions

  • gmx_get_orders

  • gmx_get_prices

Read-only and free.

  • prepare_gmx_order

  • submit_gmx_order

Non-custodial. We return unsigned transaction data, you sign with your own wallet, and we relay the already-signed transaction.

We never hold or ask for a private key.

Built directly against the documented contracts, not the official @gmx-io/sdk — that pulls in react-native transitively with real HIGH-severity vulnerabilities, an avoidable risk for a production trading backend.

Zero new dependencies here.

Repo’s private for now. Happy to open-source the tool itself or hand it to whoever’s picking up the official MCP work.

No ask attached — it’s live either way.

— brawlaphant / EcoWealth

2

Follow-up to yesterday’s MCP post. Everything below now lives in one place, written specifically for this team:

The server is still answering. Five GMX v2 tools, non-custodial, free to call, no API key:

curl -X POST https://vealth.net/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"gmx_get_prices","arguments":{}}}'

Reads are open: positions, orders, and oracle prices for any wallet.

Writes are prepare-unsigned: you sign, we relay the signed transaction. We never see a key. Entries are bounded to mark ±2%, with test coverage on the bound.

One concrete SDK issue worth someone’s afternoon:

A clean install of @gmx-io/sdk@1.6.4 resolves 304 packages, and npm audit returns 16 findings, including 7 HIGH.

The entire HIGH chain exists to supply a performance.now() polyfill:

@gmx-io/sdk → isomorphic-performance → react-native-performance → react-native → metro tooling → image-size

Relevant advisories:

GHSA-w3rx-r6r6-pgpr
GHSA-5p2g-fcmc-qvqq

Both are CVSS 7.5.

Any org gating CI on npm audit fails the moment it installs the official SDK. Replacing the isomorphic-performance branch is a one-dependency swap. Happy to file the reproducible issue on the repo if useful.

The site above carries the rest: seven findings with a source on every claim, the live demo, the full tool schemas, and the strengths the same reading found, because there were plenty.

Each page’s hash is anchored on Base through our public proof ledger, so what you read cannot quietly change afterward.

We would genuinely like feedback on this.

If you use the server, tell us what is missing. If a finding is wrong, say so on this thread and we will correct it and note the correction.

If the useful move is open-sourcing the tool or handing it to whoever picks up the official MCP work, one reply here starts it.

1 Like
3

Hey @brawlaphant, very interesting would love to talk more about it. Can you dm me on Tg: @saurabhd1

4

Appreciate your efforts Brawly!

1 Like
5

@Jonezee — thanks for the read.

One thing worth digging into is the acceptablePrice fix we found on entry orders. If you spin up the tool and prepare any order, you can decode the transaction with abiCoder.decode() and see it bound at ~2%.

The live trader that had this unbounded for 5+ months never caught it because the issue only surfaces when you prepare a transaction — not in the docs or from auditing the contract alone.

That’s the gap the tool exposes.

@Saurabh — the ecosystem findings are on-chain anchored: Base proof ledger, immutable timestamp, queryable records.

The SDK’s React Native transitive dependency includes real HIGH CVEs. The seven findings map directly to agent pain points where GMX v2 works, but the official path doesn’t.

We’re not offering feedback — we’re offering proof that agents can trade GMX v2 right now, without waiting.

Why public, not just DMs: other builders are hitting the same gaps. If GMX cares about agent adoption, the data is here.

What we’re actually building: an agent fleet that trades GMX v2 at scale.

We’re long on GMX — we have skin in the game. We want more agents spawning, more volume, and more token appreciation. Agents that leverage trade, take profits intelligently, and loop capital back into GMX.

A new buyer class built on perp volume.

In parallel: we’re building perp → EWP settlement.

Agents trade perps — Avantis on Base, Lighter on RH — and profits fund ecological work directly through single-chain routes.

That’s our core vision.

The honest constraint: GMX is on Arbitrum; EWP is on Base/RH.

We could route GMX profits through Relay to EWP today, but third-party bridges introduce systemic risk we’re not betting on yet. That’s research for later.

For now:

GMX agents drive token appreciation.
EWP agents drive work funding.

Both fleets. Separate objectives. Both real.

We’re telling you because you’re reading the material, and we want you to know the vision is real and the commitment is solid.

6

Update from our side.

Saurabh originally reached out after we shipped the independent GMX MCP in August. We’ve kept building since then.

GMX’s agent surface has also moved substantially: gmx-ai skills are now public, the API/SDK surface has expanded, while the official MCP is still listed as under development.

We’ve been reviewing our implementation against that newer stack and found one material weakness in our own write path: our signed-transaction relay validation was not strict enough to guarantee that every material field matched the transaction Vealth originally prepared.

We’re fixing that rather than pretending it isn’t there.

The read-side MCP remains useful. For the write side we’re moving to canonical prepared intent + exact transaction reconstruction/validation, with a mutation suite that must reject changes to value, transfer legs, collateral, size, leverage, execution fee, acceptable price, receivers, order count and the other security-critical fields before relay.

Once that closes, we’ll have something more useful than another MCP demo: an independently built MCP implementation plus an adversarial test boundary for agent-generated GMX transactions.

Who currently owns the MCP / agent API work inside GM Labs?

Happy to compare implementations, contribute the tests, open the relevant component, or simply keep running ours independently.

7

One thing the ZZZ / autonomous-protocol work has made me think about:

I’m interested in the idea, but right now participating means manually taking another token position and entering another gated community, while the thing I actually want is agent-native participation through Claude or Codex.

I understand that side is still being built. We’re dealing with the same reality ourselves while hardening the GMX MCP.

So my question for GMX is simpler: is GMX expected to become an early execution or proving ground for this broader autonomous-protocol work?

That would be much more interesting to me than another isolated token position. GMX already has the markets, capital, APIs and increasingly the agent infrastructure. I’d like to see these things compound rather than fragment.

8

Heads-up for whoever owns

gmx-ai

Since the v2.2c switch on Sept. 14, the addresses in the official agent skills (gmx-io/gmx-ai) point to routers that no longer have permission.

On Arbitrum, all seven write routers currently listed there return false for CONTROLLER on the RoleStore, while the corresponding routers in gmx-interface config return true.

An agent following the current skills therefore hits:

Unauthorized(…, “ROUTER_PLUGIN”)

across order, subaccount, gasless relay, GLV, and multichain calls.

Avalanche has the same issue across nine addresses.

We found this first in our own MCP: it was still using the old ExchangeRouter until today. We fixed that, deployed it, and then checked the official skills—which exposed the broader drift.

PR with the 18 corrected addresses, each sourced from gmx-interface:

Our MCP is now on v2.2c. For example, prepare_gmx_order returns a transaction targeting:

0x7dE39FF2…83f1

The MCP is live here:

curl -X POST Connect your AI · Vealth \

-H ‘content-type: application/json’ \

-d ‘{“jsonrpc”:“2.0”,“id”:1,“method”:“tools/call”,“params”:{“name”:“gmx_get_prices”,“arguments”:{}}}’

Until the official MCP ships, we’re happy for the Vealth MCP to be listed in the AI-agents docs as a working option.

9

Thanks Brawly, we’ll address this asap.