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.

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.