Instead of the model guessing at an API from documentation, or a developer hard-coding a handful of natural-language intents, the server publishes a list of tools. Each one has a name, a description, typed parameters and a typed return. The model picks the tool, fills the parameters, gets structured data back, and decides what to do next.

That structure is why this works on a derivatives exchange. On a spot exchange, “buy 10 shares of AAPL” is a complete instruction. On a perps and options venue it isn’t close. Which market. What leverage. Cross or isolated. What does that do to your margin. Is there a cheaper expiry. Is funding about to flip against you.

Answering that means chaining a dozen lookups before anything gets submitted. A tool interface can chain. A parsed sentence can’t.

What can the Aevo MCP actually do?

More than 45 tools, in five groups.

Group

What it reaches

Typical use

Market analysis

Real-time prices, funding rates, volatility snapshots, market regime classification

Scanning the venue for a setup

Portfolio management

Positions, risk metrics, Greeks, margin monitoring

"Where do I actually stand"

Order execution

Limit orders, bracket orders (entry + stop-loss + take-profit), batch operations

Acting on a decision

Options strategies

Straddles, strangles, spreads, iron condors, butterflies, with live pricing

Pricing a collar or a condor

Risk management

Pre-trade validation, portfolio risk scoring, liquidation distance monitoring

Stress testing before you commit

Two of those deserve a second look.

Bracket orders matter more than they sound. An entry with a stop-loss and a take-profit attached is a complete trade rather than an intention, and it’s the difference between an agent that opens a position and an agent that opens a managed position. If you take one thing from the execution group, make it this.

Market regime classification changes the questions you can ask. Rather than pulling raw numbers and reasoning over them yourself, you can ask what kind of market you’re in and have the agent answer from the venue’s own data. That’s a different starting point from a price feed.

What are Prompts and Resources, and why should I care?

They’re the parts of the server that stop a session being improvised.

Prompts are pre-built workflows the server publishes and your MCP client can invoke by name:

trade_plan, to work a trade idea through to a specific, sized, risk-checked plan.
risk_checklist, to run the account against a structured set of risk questions before you act.
cancel_plan, to wind a session down cleanly rather than leaving orders resting.
onboarding_plan, the guided first session.

Resources are addressable reads the agent can pull without being told how:

aevo://status, for whether the venue is up and your connection is authenticated.
aevo://markets/summary, for the state of the board in one call.
aevo://account/overview, for where you stand, without six separate lookups.

The practical value is repeatability. A free-form question gets a free-form chain of tool calls, and the same question tomorrow gets a different one. risk_checklist asks the same things in the same order every time. On the analysis side, variation is fine. On the risk side, it isn’t, and this is how you get one without the other.

How do I actually connect it?

Three routes. Pick by how much you care about where your signing key lives.

1. Hosted endpoint, no local server

The fastest route. Aevo runs the server; you point a client at it.

Mainnet: https://mcp.aevo.xyz/mcp
Testnet: https://mcp-testnet.aevo.xyz/mcp

Authenticate with AEVO-KEY and AEVO-SECRET headers, or connect first and call the aevo_authenticate tool. A Claude Desktop entry looks like this:

"mcpServers": {
  "aevo": {
    "url": "https://mcp.aevo.xyz/mcp",
    "headers": {
      "AEVO-KEY": "your-api-key",
      "AEVO-SECRET": "your-api-secret"
    }
  }
}

Right for read-only analysis and for finding out whether this is useful to you at all. Five minutes, no dependencies.

2. Self-hosted with Docker, recommended

Clone aevo-mcp, copy .env.example to .env, fill in your API key, API secret and signing key, then run docker compose up --build -d. Connect a client to http://localhost:8080/mcp.

This is the recommended configuration, and the reason is specific rather than general: your signing key stays on your own machine. The key that authorizes orders never transits to a hosted service. If you’re going to give an agent execution permissions at all, this is the version to give them on.

3. Local install, no Docker

Run pip install -e ., fill in .env, start it with aevo-mcp --transport stdio, and add it to your client as a stdio server. Same key-locality benefit as Docker, fewer moving parts, more of your own environment to manage.

OpenClaw users have a fourth route: clawhub install aevo, then add credentials as environment variables in your OpenClaw config.

What credentials does it need?

Two tiers, and the gap between them is the whole safety story.

Tier

Credentials

What it can reach

Read-only

API key + API secret

Account data, positions, trade history

Trading

plus wallet address + signing key private key

Orders, cancellations, strategies

Create keys at app.aevo.xyz/settings. If you don’t have them yet, you can set the wallet address and wallet private key variables and use the register_account tool to generate them, though creating an account first and generating keys through the Aevo wallet is the cleaner path.

The environment variables in full:

Variable

Required

Description

AEVO_API_KEY

Yes (see note)

API key from account settings

AEVO_API_SECRET

Yes (see note)

API secret from account settings

AEVO_SIGNING_KEY_PRIVATE_KEY

Yes

Required to submit orders

AEVO_ENVIRONMENT

testnet or mainnet (default mainnet)

AEVO_WALLET_ADDRESS

Used with register_account

AEVO_WALLET_PRIVATE_KEY

Used with register_account

AEVO_AUTO_REGISTER

Note: the two API credentials are not required if you’re using the wallet variables with register_account to generate keys.

State this plainly, because it’s the single decision that matters most here: omitting the signing key is a real security control, not a lesser setup. An agent without it can read everything and change nothing. That is the correct first configuration for everyone, and the correct permanent configuration for a lot of people.

Key hygiene, concretely

The advice to scope credentials is easy to nod at and easy to skip, so here is the version with actions attached. All of it takes about ten minutes once.

Generate a separate key pair for the agent. Keys are created at app.aevo.xyz/settings, and there is no reason the agent should share credentials with a script you wrote, a dashboard you use, or anything else. A key that does one job can be revoked without breaking the others.
Keep the read-only pair and the trading pair separate. If you eventually want execution, that should be a second configuration you switch to deliberately, not the same connection quietly gaining a capability because you added a variable to a file you already had.
Put the signing key in an environment file, never in a client config. A client’s MCP config is a JSON file that gets copied between machines, pasted into support threads and synced to places you didn’t think about. The .env pattern used by the self-hosted routes exists to keep the signing key out of it.
Point testnet credentials at testnet only. Mainnet keys in a testnet configuration is one of the failure modes in the table below, and the version of that mistake that runs the other way is considerably more expensive.
Know how you’d revoke. Before you first hand an agent execution rights, find the page where you’d turn the key off. Deciding that during an incident is how a five-minute problem becomes an hour.

The general principle is the same one that governs the two tiers: make the capability something you granted on purpose, and something you can take back in one step.

How do I know it's working?

Two commands.

Open a new session in your client and ask it to call the ping tool. You should get back a result reading ok true, status ok. Then ask it to check my account balance. If credentials are wired correctly, it returns your actual balance and equity.

If the ping works and the balance doesn’t, your keys are wrong or absent. If neither works, your MCP client isn’t reaching the server. Diagnosing in that order saves a lot of time.

When it doesn't work

Most setup failures are one of a handful of things, and the symptom usually names the cause if you know the mapping. Work down this table before you start reading source.

What you see

Usual cause

What to do

Your MCP client shows no Aevo tools at all

Config file not loaded, or malformed JSON

Restart your MCP client fully; validate the config file parses

ping fails, no tools respond

Your MCP client isn't reaching the server

Check the URL; for self-hosted, confirm the container is up and the port matches

ping works, balance fails

Credentials missing, wrong, or for the wrong environment

Re-check the key and secret; confirm mainnet keys aren't pointed at testnet or vice versa

Reads work, orders are rejected

No signing key

This is the read-only tier working as designed; add the signing key only if you intend execution

Orders rejected with a signing error

Signing key not registered to the account

The agent quotes numbers that don't match the app

It answered from training data rather than a lookup

Make it state its source; see the briefing block below

The agent's price is stale by a minute

A read from earlier in the session

Have it re-read immediately before acting on anything time-sensitive

A market the app shows isn't found by the agent

Instrument naming convention

Have it list markets and match exactly; this is what the trading skill is for

Two general habits catch more than any specific fix. Diagnose connection before credentials, and credentials before behavior, since the order in the table is the order of the layers and skipping a layer is how an afternoon disappears. And prove each layer on testnet first, where a wrong answer costs nothing.

One thing that isn’t a bug: a broad sweep across every market is a lot of tool calls, and it takes real time and real tokens. If you’re running the same scan every morning, narrowing it to the markets you actually trade makes it faster and cheaper without losing anything. The cost section below has the detail.

What does a chain of tool calls actually look like?

Worth walking through once, because it’s the difference between this and a chat wrapper.

You ask: “I’m long 5 ETH perps. What does a one-month collar cost me, and where does it put my liquidation?”

An agent with these tools has to do roughly this, in order, and none of it is guesswork:

Read your position. Size, entry, leverage, current margin usage. Portfolio tools.
Read the market. ETH spot, mark, the listed options chain for the relevant expiry. Market analysis tools.
Construct the structure. A put at your chosen floor, a call at a ceiling that roughly funds it. Options strategy tools.
Price it. What the two legs cost together, net. Not a description of a collar, a number.
Re-run the risk. What the combined perp-plus-options position does to your margin requirement and where liquidation sits afterwards. Risk management tools.
Report back, without executing. You decide.

Watch the chain run:

Figure 1 / Animated

One question, six tool calls

"I'm long 5 ETH perps. What does a one-month collar cost me, and where does it put my liquidation?"

01 / PORTFOLIORead position

02 / MARKETRead market

03 / OPTIONSBuild collar

04 / OPTIONSPrice it

05 / RISKRe-run risk

06 / YOUReport back

Six tool calls, one question, and the answer is specific to your account rather than generic. That sequence is what a structured interface buys you, and it’s why the options tooling matters more than the execution tooling.

The three-specification problem

Get this right before you let an agent reason about your account unsupervised.

Aevo runs three materially different perpetual specifications on the same exchange, reachable through the same tools, often displayed on the same screen:

Crypto perpetual futures. Continuous external index, funding every interval, 3% maintenance margin, up to 20x, market orders available, options and one-tap hedge perps with options protection available on BTC and ETH.
Tokenized equity perpetual futures. Six Ondo tokenized stocks (NVDAon, TSLAon, SPYon, QQQon, HOODon and GOOGLon) listed on 7 August 2026 with spot and matching perps. The underlying is an equity with a precise reference price and a trading calendar: it stops at the closing bell and reopens next session.

A language model that has internalized “perp” as one concept will apply crypto-perp assumptions to both. On a tokenized equity perp that means treating a reference price as live when the underlying market has closed for the night.

Assume the list keeps growing rather than settling at three. Any future asset class arrives with its own margin treatment long before anyone updates a model’s training data. That is the durable version of the problem: it is not about these two specifications, it is about an agent’s instinct to generalize from the market type it saw first.

Three habits fix it, in increasing order of reliability:

Tell it the specification in the prompt. Cheap, works, and you have to remember every time.
Have it read the market’s own spec page first. Better, because the numbers come from the venue rather than from you.
Install the trading skill. Best, because the guardrails travel with the tools rather than with your memory. More on that below.

The general form of the rule: make the agent fetch each market’s parameters rather than infer them. Aevo’s tools will return the real numbers if asked. The failure mode is never that the data is unavailable, it’s that a confident model didn’t think to look.

The options facts an agent will get wrong

An options structure is where the MCP earns its keep. It is also where a model’s priors are least reliable, because most of what has ever been written about options describes American-style equity options: early exercise, assignment risk, physical delivery of shares, a 4pm close. Aevo works differently on every one of those points.

European-style exercise. An Aevo option can only be settled at expiry. There is no early exercise, and therefore no early assignment risk on a short leg.
Cash-settled in USDC. Nothing is delivered. There’s no underlying to hand over and none to be called away from you, so you never need to hold the asset to sell a call against it.
Linear, and settled in USDC. Payoffs and premiums are denominated in the stablecoin, not in the underlying.
Expiry at 08:00 UTC. Not a US market close. If the agent is reasoning about the time remaining on a position, that’s the clock.
In-the-money options pay out at expiry. Settlement is automatic against the final price; there’s no exercise instruction to submit and nothing to forget to do.

Each of those changes an answer an agent might give you. Ask a model with default priors what happens if your short call goes in the money on a covered-call position and it will very likely warn you about being assigned early and having your position called away. On Aevo that cannot happen: the short leg settles in cash at expiry, and until then you hold both legs.

The correction has the same shape as the one above. Have the agent state the settlement convention before it reasons about any options position, covering style, settlement currency and expiry time, and have it read those from the venue rather than recite them. A single line in a prompt does it:

“Before analyzing this options position, state the exercise style, settlement type, settlement currency and expiry time for the contracts involved, and where you got them.”

If it answers “American, physically settled”, the setup is telling you something useful about how much of the rest of its reasoning to trust.

The three clocks an agent will mix up

The specification problem has a timing twin that gets much less attention and produces answers that look completely reasonable until they cost you something.

There are at least three different clocks running on this venue, and none of them is the one a model defaults to.

Options expire at 08:00 UTC. Not a US market close, not midnight, not your local time. Every “how long do I have” and “should I roll” answer depends on this, and a model with equity priors will reach for 4pm Eastern.
Funding accrues on the venue’s interval, not daily and not when you happen to look. An agent estimating what a position will cost to hold for a week needs the actual interval and the actual current rate, not an annualized number it half-remembers.
Tokenized equity underlyings stop trading at the closing bell. The perp runs continuously; the equity behind it does not. Outside cash hours the reference the perp is quoted against belongs to a market that has closed, and anything that happened to that company overnight arrives on the next open.

That third one is the sharpest, because nothing about it looks wrong on screen. Ask an agent at midnight UTC what the basis is on a tokenized equity perp and it will happily do the arithmetic against a reference price that stopped updating hours ago and report a number to two decimal places. The number is real. What it means is different from what it means at 3pm New York, and the agent will not volunteer that distinction.

The fix is one line: have it state the relevant clock and the timestamp of every price it used, before it gives you a number that depends on either. An agent that has to say “this reference price is from the last equity close, six hours ago” has already told you the thing you needed to know.

How to tell a looked-up answer from a plausible one

Everything above is a variation on one problem: a language model can produce a fluent, specific, internally consistent answer without having read anything. On a trading account that is the expensive failure, and it does not announce itself. So it helps to spot it in the reply rather than in the fill history.

Four tells, in order of how reliable they are.

1. Round numbers where round numbers shouldn’t be. Real market data is untidy: funding of 0.0114%, a mark of 3,847.62, a maintenance margin of 3%. An answer full of clean figures (“roughly 5% margin”, “about 20% annualized funding”, “around 4,000”) is very often a recollection dressed as a reading. Real lookups produce awkward decimals, and an agent that has read your account will quote your position size to the unit rather than to the nearest ten.

2. No timestamps, and no discomfort about it. An agent that has read a price recently is happy to tell you when. One that answers “ETH is around 3,800” without a time attached, and doesn’t flag that the number might be stale, is telling you it isn’t tracking where the number came from. This is the tell that generalizes best, which is why the briefing block below makes timestamps a standing requirement.

3. Textbook framing instead of account framing. Ask what a collar costs you and a grounded answer talks about your 5 ETH position, your margin, your liquidation price after the structure goes on. An ungrounded one explains what a collar is, describes the payoff shape, and gives an illustrative example with a spot price of 100. The second answer is often correct and always useless: it’s what the model would have said before you connected anything.

4. Confident claims about the specification. The three-specification and settlement-convention problems above are exactly where an ungrounded answer is most fluent, because there is a great deal of training data about perps and options in general. If an agent tells you the maintenance margin on a market without having called a tool that returns it, treat the number as a guess regardless of how right it sounds. The same applies doubly to anything about early assignment, expiry times, or position caps.

Two things to do about it, both cheap.

Ask “where did you get that?” as a reflex, not as an accusation. A grounded agent names the tool and the time in one line. An ungrounded one produces a paragraph of justification, and the length of that paragraph is itself the answer.
Spot-check one number against the app. Once per session, before you act on anything, check a single figure the agent gave you against app.aevo.xyz. It takes ten seconds and it calibrates how much of the rest to trust, which is more useful than checking everything occasionally.

The point is not that the agent is unreliable. Given the tools and a reason to use them, it’s very good. The point is that nothing in the interface forces it to look, so the discipline has to come from how you ask.

Reviewing a plan before you approve it

The section above is about whether the agent read anything. This one is about whether what it proposes is any good, which is a different question and the one the human in this workflow is there for.

The trade_plan prompt exists to produce a specific, sized, risk-checked proposal rather than a suggestion. That makes it reviewable. But a plan that is well-formatted, internally consistent and confidently argued can still be a bad trade, and none of those qualities is evidence either way. So it helps to have a fixed set of things to check, in a fixed order, so that approving stops being a vibe.

Six points, roughly a minute end to end.

1. Does it name the market’s specification, with a source? Everything downstream depends on this. A plan for a tokenized equity perp that assumes a market which never closes is not a plan with one error in it. Its sizing, liquidation distance and stop placement are all wrong together. If the specification isn’t stated, don’t read the rest yet.

2. Is the size derived from a risk limit you set, or from a number the agent liked? A grounded plan says “sized so a move to X costs 2% of account equity, which is the limit you gave me”. An ungrounded one says “a moderate position of 5 ETH”. The tell is whether the size is the output of a constraint or an input someone chose. If you never stated a risk limit, the agent invented one, and it is now the most important assumption in the plan.

3. Does it give liquidation distance after the trade, for the whole book? Not the liquidation price of the new position in isolation. Cross margin means the new position changes the margin behind every existing one, and the number that matters is where the account stands afterwards. A plan that reports only the new position’s liquidation price has answered an easier question than the one you need answered.

4. Is there an exit, and is it a level rather than an intention? “Cut it if the thesis breaks” is not an exit. A price, a size and a mechanism is. On Aevo this is where bracket orders earn their place: an entry with stop-loss and take-profit attached is a plan that survives you closing the laptop. Ask specifically whether the exit is a resting order or a note in a transcript, because the difference is whether it exists at 3am.

5. What did it not consider? Ask directly, in those words. A good agent answers with something real: funding cost over the holding period, the expiry falling before an event, the fact that your collateral isn’t all plain USDC, the position cap it’s approaching. An agent that says “nothing significant” is telling you it hasn’t looked for the edges of its own analysis, which is exactly the region the expensive errors live in.

6. Would you take this trade if a person proposed it? The last check, and the one that catches what the other five don’t. A plan can be perfectly constructed and still be a trade you have no view on, in a market you don’t follow, at a size you’d never have chosen. Fluency is persuasive in a way that a colleague’s rough note isn’t, and that asymmetry is worth correcting for deliberately.

Two habits make the review worth doing at all.

Review before you look at the conclusion. If you read “here’s a collar that caps your downside at 8%” first, the six checks become a search for reasons to agree. Read the construction, then the number.

Make the agent argue the other side once. “Give me the strongest case against this plan, assuming I’m wrong about direction.” It costs one prompt, and it reliably surfaces the assumption the plan was resting on, which is usually the thing you actually wanted to think about.

The underlying point: the agent’s job is to do the work, and yours is to decide. A review process that consists of reading a well-written plan and clicking approve has quietly swapped those around.

The briefing block worth pasting into every session

The sections above have the same cheap fix, and it helps to have it written down rather than reconstructed each time. Paste this at the top of a session, or save it as a system prompt in your client:

Before reasoning about any Aevo position, observe the following and confirm each against the venue rather than from memory:

1. Aevo runs two different perpetual specifications. Crypto perps: ~3% maintenance margin, up to 20x, continuous index, funding each interval. Tokenized equity perps: equity underlying with a trading calendar and a closing bell. Never carry parameters from one across to the other. Fetch the specific market’s parameters before quoting any number.

2. Aevo options are European-style, cash-settled in USDC, expiring at 08:00 UTC. There is no early exercise and therefore no early assignment on a short leg. Nothing is ever delivered. Do not apply American-style equity options reasoning.

3. The account is a single cross-margin pool and may hold collateral other than plain USDC at varying collateral factors. Any new position affects the margin on every existing one. Report the whole-book impact, not just the trade.

4. State which specification each market runs on, where you got its parameters, and the timestamp of any price you used, before giving me a number that depends on them. If a reference price belongs to a market that is currently closed, say so.

5. If you did not read a number from a tool in this session, say so explicitly rather than estimating it.

6. When you propose a trade, size it from a risk limit I have stated, give liquidation distance for the whole account after the trade, include a specific exit level, and list what you did not consider.

Six paragraphs, and they close off the great majority of the expensive errors on this page. The last three are the load-bearing ones. An agent that has to say where and when it got a number is an agent that goes and gets it, an agent required to admit an estimate usually decides to look instead, and an agent required to state what it ignored is an agent that goes looking for it.

If you install the trading skill below, most of this travels with the tools and you won’t need the block. Until then, it’s the cheapest risk control available.

What does a useful session actually look like?

The gap between an impressive demo and something worth having is the type of question you ask. These are the shapes that pay off, roughly in order of how much they benefit from tool composition:

Scanning. “Across every perp listed, which have funding above 20% annualized against shorts, and what’s the top-of-book spread on each?” One question, many lookups, an answer you’d otherwise assemble by hand.
Stress testing. “If ETH drops 8% overnight, what happens to my margin and which position liquidates first?” This is the one that changes behavior, because it reaches an answer people rarely calculate for themselves.
Pricing a structure before you commit. “What does a one-month collar on my ETH long cost, and what’s my range if I set the floor 10% below spot?” Numbers, not a description of what a collar is.
Comparing a basis across market types. “What’s the spread between spot and the perp on each of the tokenized equity markets, and what is funding paying on each?” A carry comparison across six markets is the kind of tedious, arithmetic-heavy sweep an agent does faster and more accurately than you do, provided it tells you which of those reference prices were live and which came from a closed market.
Post-trade review. “Summarize my fills this week by market, and tell me what I paid in fees and funding.”
Reward accounting. “How much qualifying volume have I done this year, and how much of it doesn’t count?” Options volume is delta-weighted, so the number on your fill history is not the number that qualifies. Aevo’s leaderboard now shows your live volume, staking tier and projected year-end USDC reward directly, which makes the agent’s job here checking and explaining a number rather than reconstructing it. The weekly epoch has its own split, and the buckets have moved between epochs: one epoch sent 700,000 AEVO to perps markets and 300,000 to options, another sent the same 300,000 to PERPS+ users. “Where should my next trade go” is a real question with a computable answer, provided the agent reads the current epoch’s terms rather than a remembered one. See Aevo staking explained.

The pattern: questions where the work is in gathering and combining, not in the final judgment. Those are the ones an agent with structured tools does better than you do with a browser.

Five prompts worth stealing

Concrete starting points, in the order most people find useful. Each is written to force a lookup rather than invite a summary.

The morning read. “Give me my account overview, then list every open position with its liquidation distance as a percentage of current price. Sort by closest to liquidation.” Uses the account resource and the risk group, and takes ten seconds to read.
The specification check. “Before you tell me anything about this market, fetch its parameters and state the initial margin, maintenance margin, max leverage, funding schedule and whether market orders are available on web.” This is the habit from the section above turned into a reusable instruction. Run it on any market you don’t trade daily.
The hedge quote. “For my largest open perp position, price three protections: a one-month put 10% out, a two-month put 10% out, and a collar with a 10% floor. Give me cost per week for each and the margin impact of each. Don’t place anything.” The comparison people rarely do by hand, and the one where the answer is frequently that the longer one is cheap.
The pre-mortem. “Assume the worst 24 hours my book has seen in the last year happens again tonight. Which position liquidates first, at what price, and what would I need to add to survive it?” Stress testing with a concrete scenario beats stress testing with a round number.
The wind-down. “List every resting order across all markets, tell me which ones I probably forgot about, then run cancel_plan.” The end-of-session habit that keeps a workflow from leaving debris behind.

The common thread is that each prompt names the tool group it needs and forbids the shortcut. Vague questions get plausible answers. Specific questions get looked-up ones.

What a session costs, and how to keep it cheap

Not a headline concern, but worth understanding once, because the difference between a well-shaped session and a lazy one is roughly an order of magnitude and nobody notices until the bill or the latency does.

Every tool call is a round trip: the model decides, the server answers, the answer comes back into context, the model decides again. So the cost of a session scales with how many calls it makes and how much each one returns, and both are things your prompt controls.

Where it goes wrong, in descending order of how much it costs:

Unbounded sweeps. “Check every market” on a venue with a long list is dozens of calls, each returning a payload the model then has to read. Asked once, fine. Asked every morning as a habit, it’s the single largest line in your usage.
Re-reading what’s already in context. An agent that has pulled your account overview does not need to pull it again three questions later, but it frequently will, because nothing tells it the earlier read is still good. Saying “use the account overview you already read unless something has changed” costs one sentence and removes several calls.
Asking for analysis before scoping the data. “Tell me what’s interesting in the market today” is a request to look at everything. “Compare funding on the four perps I hold” is a request to look at four things. The second is not a lesser question; it’s the same question with the search space you actually meant.

Three habits cut it down without losing anything:

Name the markets. Nearly every recurring question you have is about a handful of markets you actually trade. Say which.
Prefer a Resource to a sweep. aevo://markets/summary and aevo://account/overview exist to answer broad questions in one read rather than twenty. An agent will often build the slow version itself if you don’t point it at the fast one.
Keep the session shaped around one job. Long sessions accumulate context, and every subsequent call carries it. A fresh session for the morning read and another for the hedge analysis is cheaper and usually clearer than one that does both and then wanders.

The flip side is worth saying too: don’t optimize a session you run twice a week. This matters for the scan you’ve automated into a daily habit, and not at all for a one-off question about a structure. Spend the effort where the repetition is.

How does the Aevo MCP compare to exchange MCP servers?

Every large exchange now ships one. The differences that matter are not the tool counts.

MCP was open-sourced by Anthropic in November 2024. Through 2026 the major venues shipped official servers in quick succession: Bybit released an official MCP aimed at multi-agent trading desks, Bitget shipped one for its exchange tools, Kraken released an open-source command-line tool with a built-in MCP server in March 2026, and Binance launched Agent OS alongside an MCP server on 20 August 2026, giving compatible AI applications controlled access to market data and trading functions. “Does this exchange have an MCP” stopped being a differentiator during 2026. It is table stakes now.

So the useful comparison is narrower, and it comes down to three things.

What asset class the tools actually cover. Almost every exchange MCP is a spot and perps server. It can quote a market, place an order and read a balance. That is a complete tool surface for a spot venue and an incomplete one for a derivatives account. The Aevo server’s five tool groups include options strategies and risk management, which is why the interesting request here is “price me an iron condor on ETH at the September expiry and tell me the max loss” rather than “buy me some ETH”. No amount of spot tooling composes into that.

Whether you can read it and run it yourself. The Aevo server is open source under MIT: aevo-mcp for the server, aevo-trading-skills for the companion skill definitions. You can read exactly what each tool does before you give an agent order permissions, and you can self-host with Docker so the signing key never leaves your machine. A closed hosted server from a large exchange gives you neither. For a read-only market-data agent that difference is academic. For an agent with execution rights it is the entire risk assessment.

Where the keys live. This follows directly from the point above and deserves separating out. On a hosted-only server, your trading credentials are configured into infrastructure you do not control. On a self-hosted Aevo MCP, the signing key stays on your machine and the container talks out. Anyone trading real size should be on the second arrangement, and it is available here specifically because the code is open.

Where the exchange servers win. Be fair about this. Binance and Bybit have far deeper spot liquidity, more listed assets, and larger engineering teams behind their servers. If your agent’s job is “scan 400 spot markets for a momentum signal”, a large-exchange MCP is a better tool. Aevo’s server is not competing on breadth of tickers. It is competing on being able to reason about a derivatives position, and that is a different job.

The realistic setup for a serious user is more than one server connected at once. MCP is a protocol precisely so that clients can compose several: a large exchange for broad spot data, the Aevo server for derivatives analysis and execution. Treat them as complements rather than as a choice.

What makes the options tooling different?

Every trading MCP can place a market order. Very few can reason about an options position, because crypto options require the model to hold several things at once: strike, expiry, implied volatility, the Greeks, and what the combination does at each price level.

Aevo’s server exposes tools at that level, covering straddles, strangles, spreads, iron condors and butterflies, with live pricing rather than textbook payoff diagrams. You can ask what a structure costs, what it pays at expiry, and what it does to your margin, and get numbers back.

This lines up with how Aevo works everywhere else. The exchange’s whole design premise is that options should be usable by people who trade perps, and the PERPS+ modes exist to make hedging a one-tap decision rather than a research project. The MCP is the same idea pointed at an agent instead of a UI: the complexity is in the tools, not in the user.

There’s a specific gap the agent fills that PERPS+ deliberately doesn’t. PERPS+ covers BTC and ETH perpetual futures with three fixed shapes and a bounded set of durations. If you’re hedging an altcoin perp, or a tokenized equity perp, or you want a strike and expiry the listed grid doesn’t carry, you’re building the structure yourself, and that’s exactly the work an agent with options tooling can do the arithmetic for before you take it to the order book or to an Aevo OTC request for quote.

What is the Aevo Trading Skill?

The instructions an agent needs to use the tools well, as opposed to merely correctly.

aevo-trading-skills is a separate repository of skill definitions covering all 45 tools, instrument naming conventions, risk guardrails, step-by-step workflow recipes and an options strategy reference. It installs alongside the MCP server for clients that support skill definitions, such as Claude Code and OpenClaw.

The distinction is the difference between the two repos. A tool list tells an agent what it can call. The skill tells it when, in what order, and why not. An agent with tools and no skill will happily construct a technically valid iron condor in a market where nobody sensible would want one.

Instrument naming alone justifies it, and the point has more teeth now that tokenized equity tickers are in the mix. Get a symbol convention wrong and the agent doesn’t fail loudly. It prices the wrong contract and hands you a confident answer about it.

If you’re running execution permissions, install the skill. It’s the cheapest risk control available here.

Which clients does it work with?

Claude Code, Claude Desktop, Cursor, Windsurf and OpenClaw are all supported.

Because MCP is an open standard rather than a vendor integration, any compliant client should connect. Configuration lives in a per-client config file, and a server entry written for one is normally portable to another with minor changes.

Can I test without real money?

Yes, and you should. There’s a full testnet stack rather than a sandbox endpoint bolted on.

Resource

URL

Testnet app

testnet.aevo.xyz

Testnet app

testnet.aevo.xyz

Testnet API

api-testnet.aevo.xyz

Testnet API

api-testnet.aevo.xyz

Testnet MCP

mcp-testnet.aevo.xyz/mcp

Testnet MCP

mcp-testnet.aevo.xyz/mcp

Set the environment variable to testnet when self-hosting, or point at the testnet MCP URL when using the hosted endpoint.

The thing worth testing there isn’t whether orders go through, because they will. It’s whether the agent’s reasoning is sound on your prompts, with your account shape, on the markets you actually trade. That takes a few sessions, and it costs nothing to find out on testnet rather than in production.

Three specific tests are worth running, because they probe the failure modes above rather than the plumbing. Ask it about a market type you don’t normally trade, and check whether it looked up the parameters or assumed them. Ask it what happens to a short call leg that finishes in the money, and check whether it talks about early assignment. Then ask it something about a tokenized equity perp outside US cash hours, and check whether it mentions that the underlying is closed. Those three questions tell you more about whether the setup is safe than any number of successful order placements.

What can't it do?

Worth knowing before you build a workflow around it, because these are structural rather than temporary.

It isn’t a low-latency path. Every action routes through a model deciding what to call next. That is seconds, not microseconds. Anything that needs to react faster than you can read belongs on the WebSocket API.
It isn’t deterministic. The same question asked twice can produce a different chain of tool calls. Fine for analysis, wrong for anything that must behave identically every time. The Prompts narrow this; they don’t remove it.
It doesn’t run unattended well. The value is a human reading the reasoning and approving the action. Take the human out and you’ve built a trading bot with a language model where the strategy should be.
It doesn’t override exchange limits. Margin requirements, position caps and liquidation rules apply exactly as they do in the UI. The agent can hit a limit; it can’t lift one.
It doesn’t know what it hasn’t read. This is the big one, and the specification and timing problems above are its most expensive instances. An agent reasoning about an Aevo option using American-style assumptions will be confidently wrong about assignment; and an agent reasoning about a tokenized equity perp at 2am will be confidently wrong about how current its reference price is. Tell it, or have it read the docs page first.

What about building directly against the API?

Still fully supported, and still the right answer for a lot of use cases.

REST API for account management, orders, positions and market data, on mainnet and testnet.
WebSocket API for low-latency streams: order books, trades, fills, position updates.
Python SDK (aevo-sdk) which handles the signing and order construction that’s tedious to get right by hand.
A machine-readable documentation index at api-docs.aevo.xyz/llms.txt, covering every documentation page in Markdown plus the endpoints in OpenAPI. If you’re pointing a coding agent at Aevo, start there. The product docs carry an equivalent index at docs.aevo.xyz/llms.txt.

The split is roughly this. If you’re building a system that runs unattended and needs deterministic behavior and microsecond-scale latency, write it against the WebSocket API. If you want a human in the loop asking questions and approving actions, use the MCP. A market-making bot is not an MCP use case. “Walk me through what my book looks like if ETH drops 8% overnight” very much is.

There’s a third pattern that works well and gets overlooked: use the MCP to design the thing, then write the deterministic version against the API. Have the agent scan, price and stress-test the structure interactively until you know what you want, and only then hard-code it. The MCP is a research tool that happens to be able to execute, and it’s usually strongest when used that way round.

Full reference is at api-docs.aevo.xyz.

What can go wrong?

An agent with execution permissions can submit orders you didn’t intend. That’s not a hypothetical risk, it’s the definition of the feature.

Be deliberate about the following:

Scope the credentials. If the agent only needs to analyze, don’t give it the signing key. Read-only is a real configuration, not a lesser one, and the key hygiene section above turns that into five concrete steps.
Keep the signing key local. Self-hosted Docker or a local install is the reason the recommendation exists.
Test on testnet first. Every prompt you plan to use in anger should run there first, against the testnet MCP endpoint.
Watch the size limits. Whatever position and leverage limits you’d set for yourself, set them at the account level, not in the prompt. A limit in a prompt is a suggestion.
Models are confident when they’re wrong. A structured tool returns real data, but the reasoning between tool calls is still a language model’s. Treat its conclusions as a well-informed second opinion rather than a risk system, and use the four tells above to judge which conclusions were grounded.
Review the plan, don’t just read it. The six-point checklist above takes a minute and is the difference between approving a trade and being persuaded by one.
Verify before you commit size. If the agent says a structure caps your loss at a level, check the numbers on the position before you accept them.
Watch for stale reads. A quote the agent pulled thirty seconds ago is not the price you’ll fill at. On anything time-sensitive, have it re-read immediately before it acts, and on a tokenized equity market, have it say whether the underlying was open when that price was set.
Make it name the market type, the settlement convention and the clock. A one-line habit that catches most of the expensive errors: before acting, have it state which specification the market runs on, how the contract settles, when it expires, and where it got all three.
Remember cross margin is global. The account is one pool, and what’s in that pool is not always plain USDC. Aevo’s collateral framework accepts other assets, including the yield-bearing aeUSD, at their own collateral factors. An agent sizing a new position on its own merits can still push an existing hedged position closer to liquidation, and an agent that assumes your balance is one flat number can misread your buying power. Ask it what the whole book looks like afterwards, not just the trade. See unified margin.
Use cancel_plan to end a session. An agent that stops mid-workflow can leave resting orders behind. Winding down is a step, not an absence of steps.

None of this is an argument against using it. It’s an argument for setting it up once, properly, rather than handing an agent your account and finding out later what it decided to do at 3am.

Keeping a record of what it did

The habit nobody sets up until the first time they need it, which is the worst possible moment to start.

An agent session is a chain of tool calls and a chain of reasoning, and by default the reasoning is the part that disappears. Your fill history will tell you an order went out. It will not tell you why the agent thought that was the right order, what it read beforehand, or which of its assumptions was wrong. When a trade goes badly, that gap is the difference between fixing a prompt and guessing at one.

Three things worth doing, in rough order of effort:

Keep the transcript. Whatever your client’s export or history feature is, use it on any session that touched execution. The reasoning between the tool calls is the audit trail, and it’s the only copy.
Have it summarize its own actions before you close. A single closing instruction (“list every order you placed or canceled this session, with the reason for each and the market’s parameters you used”) turns a long transcript into something you can review, and occasionally catches an error while it’s still cheap.
Reconcile against the exchange, not against the agent. The agent’s account of what it did is a claim. Your fill history is the record. On anything that mattered, check the second against the first rather than trusting the summary. It’s the same discipline as verifying a structure’s numbers before you commit size, applied after the fact.

This matters more as the setup gets good. A workflow you’ve stopped reading closely is a workflow where an error can run for several sessions before you notice, and the record is what tells you when it started.

Where to start

Three steps, in order.

Connect the hosted endpoint read-only and ask it questions. Two headers, no install. Funding across the board, spreads on the markets you trade, what your current book looks like under a move. You’ll learn what the tools can reach faster than by reading the list.
Move to testnet with execution on. Point at the testnet MCP endpoint, install the trading skill, and run the workflows you actually want. See where the agent’s judgment is good and where it isn’t.
Go live self-hosted, with scoped permissions and real limits. Docker, signing key local, limits at the account level rather than in the prompt.

A good first question, once it’s connected: “What’s in my account right now, what’s my worst position under a 10% move against me, and what would it cost to put a floor under it?” If the answer is specific, numerate and account-aware, the setup is working. If it’s a general explanation of hedging, the tools aren’t wired up properly.

Docs are at docs.aevo.xyz, the MCP page is at docs.aevo.xyz/aevo-products/aevo-mcp, the API reference is at api-docs.aevo.xyz, and the exchange is at app.aevo.xyz.

WHERE TO GO NEXT

For the launch announcement, see the Aevo Trading Bot and exchange MCP post. Trading leveraged contracts with no expiry? Aevo runs a perps dex with on-chain settlement and 20x on BTC and ETH. If you want the option itself, Aevo is an options dex. If you’re coming from a centralized venue, what is a DEX explains settlement and risk.

Quick answers

How does the Aevo MCP compare to the Binance, Bybit or Bitget MCP servers?

Is the Aevo MCP open source?

What is the Aevo MCP?

Which AI clients work with the Aevo MCP?

How do I connect to the Aevo MCP?

What credentials does the Aevo MCP need?

Is it safe to give an AI agent trading permissions?

How can I tell whether the agent actually looked something up?

How should I review a trade plan the agent produced?

Can the Aevo MCP price options strategies?

What is the Aevo Trading Skill?

What can the Aevo MCP not do?

Why does an AI agent get Aevo's market rules wrong?

How do I keep an MCP session from being expensive?

Can I test the Aevo MCP without real money?

Try agentic trading

The same tools in a Telegram chat.

Open Trading Bot ↗

KEEP GOING

Product

Portfolio margin

Learn

Trading strategies

Blog

Aevo Trading Bot and exchange MCP

TOOLS

45+ IN 5 GROUPS

LICENSE

MIT, OPEN SOURCE

ENDPOINT

MCP.AEVO.XYZ/MCP

TESTNET

MCP-TESTNET.AEVO.XYZ/MCP

PRODUCT / MCP / AI AGENTS

This page is for information only and isn’t financial advice. Options and perpetual futures are high-risk products and you can lose your full position.

PRODUCT

Portfolio margin

↗

The MCP: give your AI agent a trading desk

What is MCP, and why does it matter for a perps dex?

What can the Aevo MCP actually do?

What are Prompts and Resources, and why should I care?

How do I actually connect it?

1. Hosted endpoint, no local server

2. Self-hosted with Docker, recommended

3. Local install, no Docker

What credentials does it need?

Key hygiene, concretely

How do I know it's working?

When it doesn't work

What does a chain of tool calls actually look like?

One question, six tool calls

The three-specification problem

The options facts an agent will get wrong

The three clocks an agent will mix up

How to tell a looked-up answer from a plausible one

Reviewing a plan before you approve it

The briefing block worth pasting into every session

What does a useful session actually look like?

Five prompts worth stealing

What a session costs, and how to keep it cheap

How does the Aevo MCP compare to exchange MCP servers?

What makes the options tooling different?

What is the Aevo Trading Skill?

Which clients does it work with?

Can I test without real money?

What can't it do?

What about building directly against the API?

What can go wrong?

Keeping a record of what it did

Where to start

Quick answers

Related reading