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.
Top comments (1)
Great write-up on scoping agent permissions for dangerous APIs. The "skills instead of giant docs" approach is spot on — it's essentially mode-based access control. That connects to something I've been working on: when agents have too many capabilities available, they tend to jump to execution before properly scoping the problem. Brainstorm-Mode (mehmetcanfarsak/Brainstorm-Mode on GitHub) uses PreToolUse hooks to force agents into structured ideation modes (divergent, actionable, academic) before tool access opens up. Similar principle: constrain the capability surface until the agent has actually thought through what it needs.