okx/agent-trade-kit: an MCP server that turns an AI client into an OKX trading terminal

The gap between an AI client and an exchange account

An AI assistant can read a chart description you paste in and can reason about a funding rate you quote at it. It cannot see your OKX balance, cannot place the order it just recommended, and cannot check whether the position it is discussing still exists. The usual workaround is copy and paste between two windows, which is slow and introduces transcription errors on instrument IDs and sizes.

okx/agent-trade-kit closes that gap by implementing the Model Context Protocol on top of the OKX API. The README describes the intent plainly: instead of switching between your AI and the exchange UI, you describe what you want and the AI calls the right tools. The audience is therefore narrow and specific. It is for someone who already uses an MCP-compatible client such as Claude Desktop, Cursor or VS Code, holds an OKX account, and wants order placement and market data reachable from the same conversation. It is not aimed at someone who wants a hosted dashboard, a strategy backtester, or a portfolio manager that works across several venues.

Two packages, one tool surface, and where the boundary sits

The repository publishes two npm packages. okx-trade-mcp is the MCP server, consumed by an AI client over stdio. okx-trade-cli is a terminal client for the same functionality. They are standalone, so you can install one without the other, and the README presents them as a table of two rows rather than as a core plus a wrapper.

The tool inventory is the substance here: 167 tools across 11 modules and 17 sub-modules, covering market data, spot, swap, futures, options, account, event contracts, earn, trading bots, news and smart money analytics. The spread matters more than the total. A tool count of 167 tells you nothing about quality, but the module split tells you what the maintainers think an agent needs: not just order entry, but the surrounding context. The market module alone lists 19 tools including 70-plus technical indicators, an indicator list endpoint, a screener that filters by price, change, market cap, volume, funding rate and open interest, plus open interest history. None of that requires authentication according to the module table, which is an unusual and useful property. The smartmoney module is explicitly read-only and, per the README, is split by entry mode to help an agent disambiguate which call to make. That is a design decision worth noting: the maintainers are shaping the tool names around how a model chooses between similar options, not around how the REST API happens to be organised.

Local stdio, no server, and what that buys you

The architecture is deliberately small. The MCP server runs as a local process, communicates over stdio, and stores API keys on your machine. The README states there are no cloud services and no data leaving your device. For a trading integration this is the correct default. A hosted middleman holding exchange credentials would be a far larger trust surface, and the kit avoids it entirely.

The cost of that choice is operational. There is no shared state between sessions, no server-side audit trail beyond what the account module exposes, and no way for a second machine to see what the first one did. The account module does include an audit log tool, which is the closest thing to a record, but it is an exchange-side log rather than something the kit maintains. If you want a local history of what your agent attempted, that is your problem to solve, not the kit's. The zero-infrastructure claim is accurate as far as it goes, and the trade-off is that every piece of bookkeeping you would get from a hosted service is absent.

Getting it running: install, credentials, client registration

The README gives a three-step quick start. Prerequisites are Node.js 18 or later. Installation is a single global npm command for both packages:

npm install -g @okx_ai/okx-trade-mcp @okx_ai/okx-trade-cli

Credentials are configured through an interactive wizard, okx config init. Client registration is then a setup subcommand with a client flag. The documented values are claude-desktop, cursor, claude-code and vscode, and the VS Code path writes a .mcp.json file in the current directory rather than to a global location. The README also mentions a one-line install script in docs/configuration.md that checks for Node.js, installs, and detects the client automatically.

Server startup is where the module system becomes visible. The default invocation, okx-trade-mcp with no flags, loads spot, swap and account. Passing --modules market loads market data only and, per the module table, needs no authentication. Passing --modules spot,account loads exactly those two. The --profile live flag selects a live credential profile and the README pairs it with --modules all to include earn. The --read-only flag restricts the server to query tools. That flag is the single most important thing in the configuration surface, and it is documented as a boolean with no per-module granularity: you either get query tools only or you get the full set for the modules you loaded.

The naming trap between CLI and MCP

One documented detail will bite anyone who tries to move a command from the terminal into an agent prompt. CLI subcommands use spaces, so okx swap algo place is a valid terminal invocation. The corresponding MCP tool is named with underscores, swap_place_algo_order. The README is explicit that hyphen-joined forms are not valid and that you should not convert MCP identifiers into CLI commands. It gives okx swap place-algo as the counterexample.

This is a small thing that causes real failures, because a model that has seen the CLI docs will happily invent a hyphenated command. The kit ships Agent Skills files in the skills/ directory, described as pre-built instructions covering market data, trading, portfolio, bots and earn, which appear to exist precisely to keep an agent on the correct naming convention. If you are wiring this into a custom agent rather than a supported client, those skill files are worth reading before you write your own tool descriptions.

Where it is the wrong tool

The kit exposes exchange actions. It does not decide which actions are wise. There is a rate limiter and a read-only mode, and that is the extent of the safety story described in the README. There is no position sizing rule, no maximum notional per order, no daily loss limit, and no confirmation step before a write. An agent that misreads a request can place the order. The read-only flag is a startup-time decision, so switching between analysis and execution means restarting the server with different flags, which in a client-managed stdio setup usually means editing the client configuration and reloading.

The second limitation is scope. Everything routes to OKX. If your workflow spans two exchanges, this gives you one leg of it. The third is that the earn module and the bot module expose products with their own terms, lockups and payout mechanics, and the kit presents them as tools with parameters. Understanding what a dual currency deposit or a fixed-term product actually does to your capital is on you; the tool surface does not encode that risk. Anyone treating the presence of a tool as an endorsement of the product behind it is misreading the project.

Finally, there are no releases retrieved for this repository. Installation is from npm, and the README points at the published packages rather than at tagged GitHub artifacts. If you need versioned, auditable release notes tied to a git tag, that path is not documented in the material available.

What it is not: a comparison with ccxt-style libraries

The obvious alternative for programmatic exchange access is a unified exchange library such as ccxt, or the OKX REST API directly. The difference is in what the abstraction is built for. A library like ccxt gives you a normalised function call surface across many exchanges, and you write the orchestration: which endpoint, in what order, with what error handling. It assumes a human developer writing code.

okx/agent-trade-kit assumes a language model choosing tools. That changes the shape of the interface. Tool descriptions have to be unambiguous enough for a model to pick correctly, which is why the smartmoney module is split by entry mode and why the README warns about the CLI and MCP naming divergence. It also changes the failure mode: with ccxt, a bug is a bug in your code. Here, a wrong choice is a model selecting a valid tool with wrong arguments, and the kit's answer to that is the read-only flag and module filtering rather than validation logic.

If you are building a systematic strategy with deterministic logic, ccxt or the raw API is the better fit, because you want the orchestration in code you can test. If you are building an assistant that answers questions and occasionally acts, the MCP shape is the right one, and this kit is a fairly complete implementation of it for a single venue.

Licence, maintenance and what to check before funding an account

The project is MIT licensed, which permits commercial use, modification and redistribution with the licence and copyright notice retained. That is permissive and imposes no copyleft obligation on your own code. It also means the maintainers offer no warranty, and nothing in the licence or the README describes a support commitment. This is not legal advice; if you are embedding the kit in a product, read the LICENSE file in the repository.

On maintenance, the repository shows a CI workflow badge and a codecov badge, and the last push recorded is 2026-09-07. No releases were retrieved, so there is no changelog to read for upgrade guidance. Because installation is from npm, an upgrade is a version bump on the global install, and the practical risk is a tool renaming or a module reshuffle that breaks a saved agent prompt or a client configuration. The CLI and MCP naming divergence documented in the README is exactly the kind of detail that can shift between versions.

Before pointing this at a funded account, do three concrete things. Confirm which modules your client configuration actually starts, since the default is spot, swap and account rather than everything. Check the scope of the API key you generated during okx config init, and create a read-only key first so you can exercise the market module and the account query tools without write permission. Then read the docs/modules page for whichever module you intend to enable next, because that is where the per-module tool behaviour lives and the README only summarises it.

Editorial conclusion

Adopt it if you already run an MCP-capable client and want exchange actions inside the same conversation as your analysis, starting with okx-trade-mcp --modules market, which needs no credentials at all. Do not adopt it if you need a portfolio-level risk layer, cross-exchange routing, or a guarantee that an agent cannot place an order it should not; the kit exposes tools and a read-only switch, not a strategy engine. Before funding anything, verify three things in the repository: which module list your client configuration actually loads, whether your API key is scoped to trade or only to read, and the docs/modules pages for the specific module you intend to enable.

Official sources

1. Issues
2. License: MIT
3. okx/agent-trade-kit on GitHub
4. README