DEV Community: mrcnm

I Let Claude Code Control a Crypto Exchange API (Safely)

mrcnm — Fri, 12 Jun 2026 14:25:26 +0000

This sounded like a bad idea at first.

Not “bad” in the fun startup way. More like: this could accidentally place a real order if I get lazy.

I had been experimenting with Claude Code and API workflows, and eventually I wondered what would happen if I gave it access to a real crypto exchange API. In my case, I was working with the MEXC API.

That sentence alone probably needs a disclaimer.

I did not want to build an autonomous trading bot. I did not want to paste API keys into chat. I did not want to tell an AI agent to “go trade for me.” That is not the point of this project.

What I wanted to test was more specific:

Can an AI coding agent safely help with exchange API workflows if the workflow is scoped, dry-run first, and human-approved?

That experiment became this repo:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

It is still alpha. It is experimental. It is not production-ready. It is not financial advice. It is not affiliated with MEXC.

But it works.

And more importantly, it changed how I think about AI agents and dangerous APIs.

The scary part is not the model

When people talk about AI agents doing risky things, the conversation usually turns into:

“Is the model smart enough?”

That is not the question I care about anymore.

The better question is:

“Why does the agent have access to things it does not need?”

That is where the real danger starts.

A crypto exchange API is not like a weather API. A bad request does not just return the wrong forecast. Depending on the permissions, it can place orders, cancel orders, read private account data, stream account events, or expose sensitive credentials in logs.

The model does not need to be malicious for something to go wrong.

It can simply:

confuse Spot and Futures
use the wrong endpoint
assume the wrong symbol format
place a live order when you meant dry-run
print a signed URL while debugging
mix up base quantity and quote quantity
skip a confirmation step because your prompt was vague

These are normal developer mistakes.

The difference is that an AI agent can make them very quickly and very confidently.

So my goal was not to make Claude Code “autonomous.”

My goal was to make it useful without giving it too much freedom.

My first mistake: too much documentation

At first, I treated the API docs like a normal developer resource.

I gave the agent a lot of documentation and expected it to figure out the right path.

That sort of worked for simple things.

But once the workflow got more specific, the problems became obvious.

The MEXC API has different areas:

Spot REST
Spot WebSocket
Futures REST
Futures WebSocket
public market data
private account data
signed requests
test orders
live orders
listen keys
positions
balances
order books
rate limits
error responses

That is a lot for one agent to hold in its head for a simple task.

If I asked something like:

Prepare a BTCUSDT buy workflow.

the agent had to infer too much.

Is this Spot or Futures? Market or limit? Test order or live order? Should it check symbol rules first? Should it sign the request? Should it check balances? Should it use base quantity or quote quantity?

A human developer would ask those questions too.

The problem was that the agent had too much room to guess.

That is when I stopped thinking of the documentation as “context” and started thinking of it as “permissions.”

The better idea: skills instead of giant docs

The repo is built around a simple idea:

Do not give the agent the whole API.

Give it the skill it needs for the current job.

Right now, the project is split into four main skill areas:

mexc-spot-rest
mexc-spot-websocket
mexc-futures-rest
mexc-futures-websocket

This sounds basic, but it makes a big difference.

If I am working on a Spot REST task, the agent does not need to think about Futures WebSocket streams.

If I am reading public market data, the agent does not need private account-stream instructions.

If I am preparing an order, the workflow should be very different from a read-only ticker query.

That separation made Claude Code much easier to work with.

It stopped feeling like I had thrown a giant API manual at the model and hoped for the best.

It felt more like giving a junior developer a specific runbook.

That is a much better mental model.

What “safe” means here

I am using the word “safe” carefully.

This project does not magically make live trading safe.

It does not remove risk.

It does not mean the agent is always right.

What it does is add friction in the places where friction should exist.

For example, a safer workflow should look like this:

1. Use a scoped skill.
2. Start with read-only data.
3. Prepare the request.
4. Run a dry-run.
5. Redact secrets.
6. Show the final action clearly.
7. Ask for explicit human confirmation.
8. Only then consider live execution.

That is the difference between “Claude Code can help me operate an API” and “Claude Code is randomly controlling my exchange account.”

The second one is terrifying.

The first one is useful.

I do not paste secrets into chat

This is one of the most important parts.

The workflow should never require pasting API keys directly into the conversation.

The repo expects credentials to come from local environment variables:

MEXC_API_KEY=your_api_key_here
MEXC_API_SECRET=your_api_secret_here

That does not mean environment variables are perfect. They can still leak through logs, shell history, screenshots, bad scripts, or careless debugging.

But it is much better than pasting real credentials into a prompt.

The rule I follow is simple:

No real keys in chat.
No secrets in source files.
No .env files committed.
No signed URLs printed for convenience.
No listen keys or private account payloads copied into public places.

This part is boring, but it matters.

Most security failures are boring right until they become expensive.

The API key should not be powerful

Another obvious rule: the API key should have the smallest permissions possible.

For this kind of experiment, withdrawal permissions should be disabled.

Actually, for most agent experiments, the first key should probably be read-only.

There is no reason to start with a key that can trade.

The progression should be slow:

public market data
→ signed read-only account data
→ dry-run order preparation
→ test order where supported
→ tiny live action only after explicit confirmation

Skipping straight to live trading is the fastest way to turn a fun experiment into a postmortem.

Dry-runs are the most important feature

The biggest practical improvement was dry-run behavior.

Before doing anything live, the agent should show what it intends to do.

For example:

{
  "symbol": "BTCUSDT",
  "side": "BUY",
  "type": "MARKET",
  "quoteOrderQty": "25",
  "mode": "dry-run"
}

This gives me a chance to review the request before it touches the exchange.

And the review is not just a formality.

I want to check:

Is this Spot, not Futures?
Is the symbol correct?
Is the side correct?
Is the amount correct?
Is this a market order or limit order?
Is it using quote amount or base amount?
Is it still in dry-run mode?

The agent can prepare the request.

The human should approve the risk.

That boundary matters.

Vague approval should not count

One small thing I added to my own workflow: vague approval is not enough.

These should not trigger a live trade:

ok
yes
go ahead
looks good
continue

For live actions, the confirmation should repeat the actual action.

Something like:

I confirm live Spot market buy BTCUSDT with quoteOrderQty 25 USDT.

Is that annoying?

Yes.

That is the point.

When money is involved, I want the workflow to be slightly annoying.

A little friction is better than an accidental order.

A safer prompt

Here is the kind of prompt I would use with Claude Code:

Use only the mexc-spot-rest skill.

Goal:
Prepare a BTCUSDT Spot market buy using 25 USDT.

Rules:
- Do not place a live order yet.
- Start with a dry-run.
- Do not print API keys, secrets, signatures, listen keys, or private account data.
- Check symbol information and current market data first.
- Check account balance only if credentials are already configured locally.
- Use a test order if supported before any live order.
- Ask for explicit confirmation before live execution.
- Do not treat vague approval as permission to trade.

That is much better than:

Use the MEXC API to buy BTC.

The second prompt leaves too many decisions open.

The first prompt gives the agent a job, a boundary, and a review process.

What worked

The scoped-skill approach worked better than I expected.

Claude Code was more focused when it did not have to read everything.

It was easier to guide.

It was easier to correct.

And when something went wrong, it was easier to find the source of the mistake.

If the issue was in Spot REST, I could inspect the Spot REST skill.

If the issue was in Futures WebSocket, I could inspect that skill.

That sounds small, but it makes debugging much less painful.

The agent also became less likely to mix unrelated concepts because the context was smaller.

Instead of asking it to reason over the whole exchange API, I was asking it to operate inside one lane.

That made the whole workflow feel more controlled.

What still needs work

This is still alpha, and I do not want to oversell it.

Futures workflows especially need extra caution. Futures are more complicated than Spot. There are positions, leverage, margin modes, liquidation risks, contract rules, and more ways to make painful mistakes.

Even if the agent prepares something that looks correct, I would not treat Futures live execution as “safe.”

At this stage, the repo is better viewed as:

an experimental structure for safer agent/API workflows

not:

a finished trading framework

That distinction matters.

The project is useful, but it still needs testing, review, and hardening.

The pattern is bigger than crypto

The part I find most interesting is that this pattern is not really about MEXC.

It applies to any powerful API.

Payment APIs.

Cloud infrastructure.

GitHub automation.

Database admin tools.

Deployment systems.

Internal dashboards.

Anywhere an AI agent can affect a real system, the same question comes up:

How much access does the agent actually need?

Most of the time, the answer is: less than we give it.

A good agent workflow should have:

scoped context
limited permissions
dry-run mode
clear logs
secret redaction
human approval for dangerous actions

That is not as exciting as “fully autonomous AI.”

But it is much more practical.

My checklist now

If I am letting an AI agent near a serious API, this is the checklist I want in place:

[ ] Dedicated API key
[ ] Withdrawal permissions disabled
[ ] IP restrictions if available
[ ] Read-only access first
[ ] Minimal permissions
[ ] No secrets pasted into chat
[ ] No .env files committed
[ ] Sensitive values redacted
[ ] Spot and Futures separated
[ ] REST and WebSocket separated
[ ] Dry-run before live action
[ ] Test order where supported
[ ] Explicit confirmation for live action
[ ] Tiny size only if live testing is necessary
[ ] Manual review of every live request
[ ] Key rotation plan if anything leaks

This checklist does not make the system perfect.

It just prevents the easiest mistakes.

That alone is worth it.

The repo

The project is here:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

It currently includes skills for:

MEXC Spot REST
MEXC Spot WebSocket
MEXC Futures REST
MEXC Futures WebSocket

It also includes helper scripts, request-signing workflows, WebSocket notes, safety rules, and layouts for Claude / Claude Code / Claude Desktop and Codex-style repository agents.

Again, this is alpha.

It is experimental.

It is unofficial.

It is not financial advice.

It is not production trading software.

But it works as a real example of a better pattern:

Do not give an AI agent a huge API and hope it behaves.

Give it a small job, clear boundaries, and a human approval gate.

Final thought

Letting Claude Code control a crypto exchange API sounds reckless.

And it would be reckless if the workflow was:

Give it keys.
Give it docs.
Tell it to trade.
Hope nothing breaks.

That is not what I built.

The workflow I want is:

Give it a scoped skill.
Limit the key.
Start read-only.
Dry-run first.
Redact secrets.
Ask for confirmation.
Let the human decide.

That is the difference.

The future of AI agents is not just about making them more autonomous.

It is about knowing where autonomy should stop.

I Stopped Giving AI Agents 500 Pages of API Docs — Here’s What Happened

mrcnm — Fri, 12 Jun 2026 12:22:54 +0000

When I first started using AI coding agents with real APIs, I made the mistake almost everyone makes:

I gave the agent the documentation.

All of it.

Hundreds of pages. Every endpoint. Every parameter. Every warning. Every REST route. Every WebSocket note. Every authentication detail.

I thought more context would make the agent smarter.

It did not.

It made the agent slower, more confused, and less predictable.

Eventually, I stopped giving AI agents giant API documentation dumps and started giving them smaller, task-specific skills instead.

That change made the workflow dramatically better.

This article is based on something I have been building here:

GitHub repo: https://github.com/mncrftfrcnm/mexc-agent-trading-skills

It is still alpha. It is experimental. It is not production-ready. But it works well enough to prove the idea: AI agents become much more useful when they are given focused responsibilities instead of an entire API universe at once.

The Problem With Giving Agents Full API Docs

At first, my approach was simple.

I wanted an AI coding agent to help with MEXC API workflows, so I gave it the MEXC API documentation and expected it to figure things out.

In theory, that sounds reasonable.

In practice, it created problems immediately.

A trading platform API is not a small API. It usually contains many categories:

Spot trading
Futures trading
Account information
Market data
Order management
WebSocket streams
Authentication
Signatures
Rate limits
Error responses
Test orders
Live orders
Private account streams

The agent had access to everything.

That was the issue.

When I asked for a simple task like checking account balances or querying market data, the model had to search through too much irrelevant information.

It sometimes mixed Spot and Futures concepts.

It sometimes reached for the wrong endpoint category.

It sometimes overcomplicated simple tasks.

It sometimes produced confident-looking but fragile workflows.

The problem was not that the model was useless.

The problem was that I had given it too many choices.

More Context Is Not Always Better Context

Large context windows are useful, but they do not magically solve relevance.

A model may be able to read a huge amount of text, but it still has to decide:

Which part matters?
Which endpoint applies?
Which parameters belong to this workflow?
Is this Spot or Futures?
Is this REST or WebSocket?
Is this public data or authenticated account data?
Is this safe to execute?
Does this action require confirmation?

When the agent sees hundreds of pages, the search space becomes too large.

Even if the correct answer is somewhere in the documentation, the agent still has to find it, interpret it, and ignore everything else.

That is where mistakes happen.

For normal developer APIs, a wrong request might just fail.

For a trading API, a wrong request can be much more serious.

It can place an unwanted order, cancel an order, expose sensitive data, or leak API credentials into logs.

So I started thinking differently.

Instead of asking:

How do I give the agent all the documentation?

I started asking:

What is the smallest amount of information the agent needs to complete this specific task safely?

That question changed the whole project.

The Shift: From Documentation Dumps to Agent Skills

The idea was simple:

Instead of one giant documentation blob, create smaller focused skills.

Each skill gives the agent only the information it needs for a specific category of work.

For this repo, I split the MEXC workflows into four main areas:

mexc-spot-rest
mexc-spot-websocket
mexc-futures-rest
mexc-futures-websocket

That separation matters.

A Spot REST task should not need to read Futures WebSocket instructions.

A public market-data task should not need private account-stream logic.

A balance-check task should not need live-order execution rules unless the workflow actually requires them.

This makes the agent easier to guide and easier to audit.

What the Repo Does

The repo is not meant to be a magic trading bot.

It is not financial advice.

It is not a recommendation to trade.

It is not a system for unattended live trading.

The goal is narrower and more practical:

Give AI coding agents a safer structure for working with MEXC API workflows.

The repo includes skills and helper files that can help agents:

query public Spot market data
query public Futures market data
check account information when credentials are configured
build signed REST requests
use environment variables for credentials
run dry-runs before live actions
use Spot test orders before live Spot orders
work with WebSocket stream workflows
avoid printing API keys, signatures, listen keys, or private account data
separate Spot and Futures workflows
separate REST and WebSocket workflows

Again, it is still alpha.

But the important part is that the structure works.

The agent no longer needs to understand the entire API every time. It can load the relevant skill and operate inside a smaller, clearer boundary.

Before: The Agent Had Too Many Options

Before using skills, a simple request could become messy.

Example request:

Check the BTCUSDT market price and prepare a possible Spot buy workflow.

With the full docs, the agent might see:

Spot ticker endpoints
Futures ticker endpoints
Spot order endpoints
Futures order endpoints
Margin-style workflows
WebSocket streams
signed account endpoints
public market endpoints
private listen-key workflows
live order examples
test order examples

That is a lot of information for one task.

The model now has to decide which parts are relevant.

Sometimes it chooses correctly.

Sometimes it mixes concepts.

Sometimes it gives a workflow that looks okay but includes unnecessary or risky steps.

After: The Agent Gets a Smaller Job

With skills, the same request can be scoped much better.

For example:

Use the mexc-spot-rest skill.
Check public market data for BTCUSDT.
Do not place a live order.
Prepare a dry-run only.

Now the agent has a clearer boundary.

It knows:

this is Spot, not Futures
this is REST, not WebSocket
this is public market data first
this should not execute a live order
dry-run behavior is preferred
sensitive values must not be printed

That is much easier to reason about.

The agent becomes more reliable because the task is smaller.

Skills Are Not Just About Convenience

At first, I thought skills were mainly a context-management improvement.

Less documentation means fewer tokens.

Fewer tokens means faster responses.

That is true.

But the bigger benefit is safety.

Skills can act like boundaries.

For example, if an agent is only using a market-data skill, it should not be dealing with withdrawals, private account streams, or live orders.

If an agent is using a Spot REST skill, it should not accidentally use Futures order logic.

If an agent is preparing an order, the workflow can require dry-runs and explicit confirmation before live execution.

This is much better than simply writing:

Please be careful.

Prompts help, but architecture matters more.

A safer workflow should make dangerous behavior harder by default.

What Actually Improved

After moving from full-documentation context to smaller skills, several things improved.

1. Less Confusion Between API Areas

Spot and Futures APIs often look similar from a distance, but they are not the same.

They can have different endpoints, different symbols, different account logic, and different risk assumptions.

Splitting the skills reduced accidental mixing.

Instead of giving the agent every trading-related concept at once, I could say:

Use the Spot REST skill only.

or:

Use the Futures WebSocket skill only.

That one constraint removes a lot of ambiguity.

2. Better Dry-Run Behavior

For live API workflows, dry-runs are extremely important.

A dry-run lets the agent prepare and display what it would do without actually sending a live request.

That gives the user a chance to inspect:

symbol
side
order type
quantity
price
account type
endpoint
request method

This matters because a live trading API is not like a todo-list API.

Mistakes can affect real balances.

The repo is designed around safer defaults like dry-runs, explicit confirmation, and redaction of sensitive values.

3. Easier Debugging

When something went wrong with the giant-docs approach, debugging was painful.

Was the model confused by the docs?

Did it pick the wrong endpoint?

Did it mix Spot and Futures?

Did it misunderstand authentication?

Did it invent a parameter?

With skills, debugging becomes easier because the scope is smaller.

If the issue happens in Spot REST, I inspect the Spot REST skill.

If it happens in Futures WebSocket, I inspect the Futures WebSocket skill.

The problem space is smaller.

That makes fixes much faster.

4. Better Security Habits

One of the most useful parts of building this repo was forcing myself to think about credentials.

Agents should not ask users to paste API keys into chat.

They should not print secrets.

They should not write signatures into logs.

They should not expose listen keys.

The repo encourages using local environment variables like:

MEXC_API_KEY=your_api_key_here
MEXC_API_SECRET=your_api_secret_here

The agent can use the local environment without needing the user to paste secrets directly into the conversation.

This is still not perfect security. Environment variables can still be mishandled. Shell history, logs, screenshots, and local files can still leak secrets.

But it is much better than pasting API keys into an AI chat.

What I Tested

This project is alpha, so I do not want to oversell it.

But it is not just an empty idea.

The repo includes helper scripts and self-tests for request-signing workflows.

It also includes CI checks for Python compilation and secret scanning.

For example, the repo includes self-test commands like:

python codex_mexc_skills/skills/mexc-spot-rest/scripts/mexc_spot_request.py --self-test
python codex_mexc_skills/skills/mexc-futures-rest/scripts/mexc_futures_request.py --self-test
python -m compileall codex_mexc_skills claude_mexc_skills

The CI workflow also includes secret scanning with tools such as gitleaks and TruffleHog.

That does not mean the project is production-ready.

It means the foundation is real enough to build on.

The current state is closer to:

Useful experimental agent-skill structure

not:

Fully audited production trading framework

That distinction is important.

Alpha Does Not Mean Useless

A lot of open-source projects start as alpha.

The question is not:

Is this perfect?

The better question is:

Does this solve a real problem in a useful way?

For me, the answer is yes.

Even in alpha, the repo is useful because it gives agents a better structure than dumping huge API docs into context.

It gives the model smaller tasks.

It separates dangerous workflows.

It encourages dry-runs.

It reminds the agent not to expose credentials.

It gives developers a starting point for testing agent workflows against a real API.

That is already useful.

But alpha also means you should be careful.

Do not use it for unattended live trading.

Do not use it with withdrawal permissions.

Do not assume every endpoint behavior is final.

Do not assume the agent is always correct.

Do not skip manual review.

A Practical Pattern You Can Reuse

This pattern is not only for MEXC.

You could use the same idea for many APIs.

Instead of giving an agent a giant documentation set, split the API into task-based skills.

For example, with a payment API:

payments-read
payments-create
refunds
customers
webhooks

With a cloud API:

compute-read
compute-write
storage-read
storage-write
iam-readonly
iam-admin

With a GitHub automation workflow:

issues
pull-requests
actions
security-alerts
repo-settings

The principle is the same:

Give the agent the smallest useful capability set.

Do not give it everything by default.

A Simple Rule for Agent Design

Here is the rule I now use:

If a human would not need this documentation to complete the task, the agent probably does not need it either.

If the task is checking a price, the agent does not need live-order instructions.

If the task is reading account balances, the agent does not need WebSocket order-book recovery.

If the task is subscribing to market streams, the agent does not need private trading endpoints.

This sounds obvious, but it is easy to forget when working with AI.

Because models can accept large amounts of context, we assume we should give them large amounts of context.

But capability is not the same as relevance.

Recommended Safety Checklist

If you are experimenting with AI agents and live APIs, especially financial APIs, I recommend a checklist like this:

[ ] Use dedicated API keys for the project
[ ] Disable withdrawal permissions
[ ] Enable IP restrictions if available
[ ] Use minimum required permissions
[ ] Prefer read-only access when possible
[ ] Use dry-runs before live requests
[ ] Require explicit confirmation for live write actions
[ ] Never paste secrets into chat
[ ] Never commit .env files
[ ] Redact signatures, listen keys, and private account data
[ ] Test with small amounts only if live testing is necessary
[ ] Manually review every live action before execution

This does not eliminate risk.

But it reduces obvious mistakes.

What I Would Change If Starting Again

If I were starting this project again, I would not begin with the full API documentation.

I would start with one workflow.

For example:

Read public Spot market data.

Then I would build one small skill around that.

After that works, I would add:

Read Spot account balances.

Then:

Create a Spot test order.

Then maybe:

Prepare a live Spot order with explicit confirmation.

That order matters.

Start with read-only workflows.

Then test workflows.

Then carefully guarded live workflows.

Do not start by giving the agent every possible action.

Why This Matters

AI coding agents are moving from code suggestion to real action.

They do not just autocomplete functions anymore.

They can run commands.

They can edit files.

They can call APIs.

They can operate tools.

That is powerful, but it also changes the risk model.

When an agent is only writing code, mistakes are usually reviewable.

When an agent can call a live API, mistakes can have immediate consequences.

That means we need better workflow design.

Not just better prompts.

Not just better models.

Better boundaries.

The Repo

If you want to look at the project, it is here:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

The current repo includes skills for:

MEXC Spot REST
MEXC Spot WebSocket
MEXC Futures REST
MEXC Futures WebSocket

It includes layouts for Claude / Claude Code / Claude Desktop and Codex-style repository agents.

It also includes helper scripts, endpoint recipes, WebSocket notes, safety rules, and CI checks.

Again, this is alpha.

It is experimental.

It is unofficial.

It is not affiliated with MEXC.

It is not financial advice.

But it works as a practical example of a better way to structure AI-agent API workflows.

And if you are building agents that interact with large APIs, I think this pattern is worth exploring.

Final Thought

The biggest lesson was simple:

AI agents do not need more documentation.

They need better-scoped responsibility.

Giving an agent 500 pages of API docs feels powerful, but it often creates confusion.

Giving an agent a focused skill feels smaller, but it usually works better.

Less context.

More structure.

Fewer choices.

Safer defaults.

That is what changed everything for me.

Building safer AI-agent workflows for the MEXC trading platform API

mrcnm — Wed, 10 Jun 2026 11:34:12 +0000

I’ve been working on a small open-source repo for AI-agent workflows around the MEXC API.

The project is not meant to be a “trading bot.” The goal is more specific: to give coding agents like Claude Code, Codex-style agents, and similar tools a safer structure for working with live exchange API workflows.

The first implementation is for MEXC.

GitHub repo:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

What the project is

This repo contains experimental skills/prompts for AI coding agents that work with MEXC API workflows.

The skills are split into four main areas:

MEXC Spot REST
MEXC Spot WebSocket
MEXC Futures REST
MEXC Futures WebSocket

Each skill gives an agent a smaller, focused set of instructions instead of making it read a large API reference every time. The repo also includes helper scripts, endpoint recipes, WebSocket notes, and safety rules for handling credentials and live actions.

In simple terms, the skills can help an agent:

query public market data
check account information, such as Spot or Futures balances
see available tokens/assets in an account
build signed REST requests
use local API credentials from environment variables
use dry-runs before sending live requests
use Spot test orders before live Spot orders
work with WebSocket streams for market data, order-book updates, and account/order events
avoid printing API keys, signatures, listen keys, or private account data

The main idea is to make unsafe behavior harder by default.

Why I made it

Coding agents are useful when working with APIs, but live trading APIs are different from normal developer APIs.

If an agent makes a bad request to a normal test API, maybe the request just fails. If it makes a bad request to a trading API, it could place an unwanted order, cancel something, change account or position settings, expose credentials, or leak private account data into logs.

That is the problem this repo is trying to reduce.

The project focuses on safer defaults:

use local environment variables instead of asking users to paste API keys into chat
prefer dry-runs and read-only requests first
require explicit confirmation before live authenticated write requests
redact sensitive values in dry-run output
separate Spot and Futures workflows
separate REST and WebSocket workflows
clearly mark experimental areas, especially Futures live-order workflows

Repo structure

The repo includes compatibility layouts for different agent environments.

For Claude / Claude Code / Claude Desktop, there are Claude-ready skill folders.

For Codex-style repository agents, there is a separate Codex-oriented layout.

The main skills are:

mexc-spot-rest
mexc-spot-websocket
mexc-futures-rest
mexc-futures-websocket

The REST skills include local helper scripts for request construction and signing.

The WebSocket skills include workflow notes for public streams, private streams, reconnect behavior, listen keys, order-book updates, and handling sensitive stream data.

What the Spot REST skill includes

The Spot REST skill focuses on one-off REST API workflows, including:

public market data
server time
symbol and exchange information
signed account reads
balance checks
Spot test orders
order lookup
signed request construction
dry-run output with sensitive values redacted

The helper script is designed so an agent can construct and sign requests without manually rebuilding the signing process every time.

What the Spot WebSocket skill includes

The Spot WebSocket skill is for live Spot streaming workflows.

It includes guidance for:

public trade streams
ticker and depth streams
protobuf-based public messages
listen-key based private streams
account and order updates
reconnect behavior
local order-book recovery
avoiding listen-key exposure in logs

This is meant to give an agent a clear workflow for streaming data instead of mixing WebSocket logic into normal REST tasks.

What the Futures REST skill includes

The Futures REST skill focuses on Futures API workflows, including:

public contract data
contract details
server status
account assets
position information
signed Futures requests
contract metadata checks
precision and leverage-related information
safer request patterns for live workflows

Futures live-order support is still treated as experimental. The repo keeps warnings around Futures private write endpoints because endpoint availability, permissions, and maintenance status can vary.

What the Futures WebSocket skill includes

The Futures WebSocket skill is for live contract market data and private Futures events.

It includes guidance for:

public contract streams
tickers, deals, depth, funding, and price-related streams
private account, order, and position streams
ping/pong behavior
reconnects and resubscriptions
order-book recovery from snapshots
redacting private authentication payloads and account data

What is currently tested

The repo currently includes self-tests for the Spot REST and Futures REST request-signing helpers.

The CI workflow also:

runs the Spot REST helper self-test
runs the Futures REST helper self-test
compiles the Python files
runs gitleaks secret scanning
runs TruffleHog verified secret scanning

That means the repo already checks the local helper scripts, Python syntax, and basic secret hygiene in CI.

Current project status:

Spot REST helper signing: self-tested
Futures REST helper signing: self-tested
Python files: compile-tested
Secret scanning: included in CI
WebSocket workflows: documented and structured as agent skills
Live trading workflows: guarded by confirmation rules and warnings, not claimed as production-ready

Safety model

The repo is designed around the idea that agents should not casually perform live trading actions.

By default, the helper scripts prefer dry-run behavior. Authenticated live non-GET requests require explicit confirmation flags. Sensitive values such as API keys, signatures, and listen keys are treated as private and should not be printed or stored in logs.

The project also recommends:

dedicated API keys for this project
disabled withdrawal permissions
IP restrictions where possible
minimum required API permissions
small test sizes if live testing is ever done
reviewing every symbol, side, order type, price, quantity, leverage, and account type before any live action

Important disclaimer

This project is unofficial and not affiliated with MEXC.

It is not financial advice, investment advice, trading advice, or a recommendation to buy, sell, or hold any asset.

Live trading APIs can affect real balances, orders, and positions. This repo is meant for developer experimentation and structured agent workflows, not unattended live trading.

GitHub repo:

https://github.com/mncrftfrcnm/mexc-agent-trading-skills

Help testing MEXC trading platform opensource agent skills

mrcnm — Tue, 09 Jun 2026 07:27:26 +0000

Hello, I am searching for someone to help me test, or just checkout a small opensource project, that allows AI agents of your choice to interact with the MEXC trading platform.

These skills can help agents query market data, use REST and WebSocket workflows, build signed requests, check account information, test orders, and optionally submit live trading requests when valid API credentials and explicit user confirmation are provided.

here's a link to the project, if anyone is interested: https://github.com/mncrftfrcnm/mexc-agent-trading-skills

This project is unofficial, not affiliated with MEXC, and is not financial advice. Please do not test with real funds unless you fully understand the risks.

Issues, corrections, PRs, or general feedback are welcome.