Exchange-via-MCP Protocol v1.0

What this is

A community-owned standard for the shape of crypto-exchange MCP servers. We wrote v1.0 and implement it; nothing about the standard is Nextbridge-proprietary. The spec lives at https://github.com/zack40x/exchange-mcp-protocol under Apache 2.0.

What it specifies: tool names (place_spot_trade, get_balance,request_withdrawal, …), argument naming convention (snake_case), return shapes (string decimals, ISO timestamps, canonical field names), error envelope, scope model, rate-limit tiers, resource URI scheme, and prompt catalog.

What it does not specify: business model, custody architecture, regulatory posture, UI, marketing. The standard is about the agent-facing protocol surface.

Why it exists

Every existing exchange exposes itself with a custom REST API, custom auth, custom error shapes. Building an agent that trades across multiple exchanges means writing per-exchange integration code three times.

MCP gives us a shared protocol AI clients already speak — but without a per-domain convention, every MCP server is as bespoke as their REST was. v1.0 fixes that for crypto exchanges. An agent written against the canonical place_spot_trade tool works against any compliant server with no per-exchange code.

Nextbridge's compliance

We self-certify as v1.0 fully compliant. Our compliance manifest lives at the standard well-known location:

1curl https://nextbridge.exchange/.well-known/exchange-mcp-compliance.json

Coverage:

Canonical tool catalog (v1.0)

The full catalog with arg + return shapes lives in spec/tool-catalog.md. Required tools every compliant server implements:

Optional tools (cancel_order, get_market_candles, create_price_alert) are documented in the same catalog.

Error envelope

Every error returned by a v1.0-compliant tool uses this exact shape:

1{
2  "success": false,
3  "error": {
4    "code":    "INSUFFICIENT_FUNDS",
5    "message": "Need 100.50 USDT, have 87.23",
6    "details": {
7      "needed":    "100.50",
8      "available": "87.23",
9      "asset":     "USDT"
10    }
11  }
12}

The canonical code list — UNAUTHORIZED, FORBIDDEN_SCOPE, VALIDATION, INSUFFICIENT_FUNDS, RATE_LIMITED, MAINTENANCE, etc. — lives in spec/error-codes.md.

Auth + scopes

Bearer API keys, four canonical scopes:

• read — all read-only tools (market data, balances, transactions, KYC status)
• trade — spot trade placement, alerts
• withdraw — withdrawals + withdraw-address allowlist management
• admin — platform admin operations (server-defined)

Issue keys with exactly the scopes you need from /settings/security.

Extension namespace

v1.0 covers the surface common to every spot exchange. For exchange-specific features — P2P fiat markets, copy-trade marketplaces, staking, derivatives — implementers use theextensions.{slug}. namespace. Cross-exchange agents ignore extension tools; exchange-specific agents can target them directly.

Nextbridge's extensions today: extensions.nextbridge.list_p2p_offers, extensions.nextbridge.subscribe_strategy, extensions.nextbridge.portfolio_history, … Full list in our compliance manifest.

For other exchanges adopting v1.0

1. Read the full spec in the repo. It's ~600 lines of markdown and one TypeScript example.
2. Implement every required tool from spec/tool-catalog.md with the canonical names + arg shapes.
3. Wire your existing API key system to the four canonical scopes.
4. Standardise your error returns to the v1.0 envelope.
5. Publish a compliance manifest at /.well-known/exchange-mcp-compliance.json.
6. Open a PR against compliance/ in the spec repo so agents can discover you.

The standard is community-owned. We'll merge compliance PRs from any good-faith exchange. Substantial RFCs (new tool surface, v1.1 additions) go through GitHub discussion.