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.
Top comments (0)