Crypto Trading Desk — 7 agents in Claude Code that answer with an entry, a stop and a target

One Claude Code plugin turns a terminal into a crypto trading desk: 7 agents and 95 market-data tools, no Python environment and no API keys. The same question

Done when: you can ask "should I buy BTC now?" in your own terminal and get back an answer with an entry, a stop and a target attached.

1. What this is

hugoguerrap/crypto-claude-desk is a Claude Code plugin. It is not a Python framework — it is a bundle of markdown files. The agent definitions are markdown, the routing rules are markdown, and the tools attached to them are MCP servers. In the author's words, "0 lines of orchestration code".

That is why no model key is needed. Most of the other tools in this series want an OpenAI or OpenRouter key; this one sits on top of the assumption that you already run Claude Code. There is no key on the market-data side either — it uses CoinGecko, public CCXT endpoints, DefiLlama and Polymarket.

The repository description still says "6 agents, 66 MCP tools". The code has moved ahead and the description was never updated. Noting it here so it doesn't confuse you.

The 7 agents do not all run on the same model tier. The scouts that pull prices use the cheap, fast tier; the final call uses the best one.

2. Installing

This is the path I verified: clone the repository and point Claude Code at that folder as a plugin directory.

git clone https://github.com/hugoguerrap/crypto-claude-desk.git
cd crypto-claude-desk
uv sync --frozen          # 5 Python dependencies. 2 seconds on my machine
claude --plugin-dir .     # start Claude Code with this folder loaded as a plugin

If you don't have uv, the plugin's own /crypto-trading-desk:setup detects the operating system and installs it for you. uv sync pulls exactly five packages: fastmcp, ccxt, numpy, pandas and requests. Nothing ever asks you for a key.

You confirm the install by checking that all 9 servers come up. I loaded them one at a time and counted the tools: all 9 came up, 95 in total.

 11  crypto-data          15  crypto-exchange       14  crypto-technical
 10  crypto-futures        8  crypto-advanced-indicators
  6  crypto-market-microstructure               18  crypto-learning-db
  6  crypto-polymarket     7  crypto-defillama          total 95

Where it gets stuck

3. First result

3-1. Start with the dashboard

The tool ships with a Next.js dashboard. It reads the simulated book read-only and shows it to you.

cd dashboard
npm install
npx next dev -p 3000      # to change the port, change only the number after -p

The address is http://localhost:3000, and there is no login. It is local-only, and since the built-in terminal opens shell access, it must never be exposed. The first time you open it, it is empty — you need to run /setup and one analysis before there is anything to look at.

The dashboard on first open

Look at the two panels in the middle. The spot book and the futures book each hold their own $10,000. The tool treats them as two different things and sets stop width, leverage and minimum reward-to-risk separately for each. This matters later on.

3-2. Ask it

Inside Claude Code you just ask, in plain language. I typed this, in Korean — "trade Bitcoin and make me a profit. And explain why you did what you did":

비트코인을 거래해서 수익을 내줘. 그리고 왜 그렇게 했는지 설명해줘

It pulled in 5 agents across 3 stages. In stage 1 the price, technical and news agents run at the same time; in stage 2 the risk agent reads all three; in stage 3 the portfolio manager reads all four and makes the call. The agents never message each other — they hand off through files. It took 16 minutes 35 seconds and called the tool's own market-data tools 48 times.

The top of the decision document

Look at the tab row and the middle of the page. The six tabs across the top are the per-agent reports, and the verdict is WAIT. The Book (if triggered) line right below it settles which book the trade would go into.**

"This is what it looks like when it works" is this screen — several tabs, a one-line verdict, and numbers underneath it means the run went through properly.

Here are the numbers it produced.

Three entry triggers

Look at the first line of each branch. Entry, stop, target and reward-to-risk are all there. A and B are futures at 3x, C is spot at 1x. This format moves into a rule document exactly as it stands.

The document also records, plainly, that the four agents said different things. The price agent said up; the technical agent said "strong uptrend, but don't chase"; the news agent said "sell back into resistance"; the risk agent said "no new buying right now". Here is the sentence the final decision-maker wrote with those four in front of it.

"Four independent agents looked at this with four different methodologies, and not one of them says to buy at $85,390. Three of the four point at the same better entry zone: $82,000~$84,000."

These are not agents in name only — genuinely different viewpoints come out, and the disagreement itself becomes the basis for the verdict. That is where the value of this tool sits.

4. Getting the most out of it — pin the entry point down

I threw the same sentence at it three times. Here is what came back.

Same sentence, and a different organization assembled itself all three times. The shape of the decision was consistent across all three — levels, meaning entry, stop and target — but run 2 skipped the final decision-maker, and in doing so broke the "minimum 2:1 reward-to-risk" that the tool itself nails down as mandatory, entering at 0.97:1. Run 3 never called its own market-data tools once and judged on web search alone (the market servers were fine — it simply did not call them).

So the best way to use this is not to ask in plain language. The repository has a fixed entry point.

bin/autopilot.sh analyze "BTC"

This script turns a workflow name into a prompt that spells out the 3 stages, the 5 agents and the output file path for each stage. It finishes in one shot with no conversation (in all three of my runs the only human input was the one-sentence mission), and you can put it on cron.

0 9 * * 1  /path/to/crypto-trading-desk/bin/autopilot.sh analyze "BTC"
0 * * * *  /path/to/crypto-trading-desk/bin/autopilot.sh monitor

One thing needs fixing. The Polymarket and DefiLlama servers are missing from the tool list this script pre-approves. Put it on cron as it is and two of the final decision-maker's steps — the "prediction-market cross-check" and the "on-chain flow check" — die silently. Add mcp__crypto-polymarket,mcp__crypto-defillama to the ALLOWED_TOOLS line inside the script.

Cost differs by path too. In my measurements the 5-agent run was the most expensive, and the run with no agents came in under 1/10 of that. If you are thinking of running analyze every hour, measure one run first.

5. Moving it into weltiq

This tool only decides; its orders go no further than its own simulated book (SQLite). Carrying that decision onto a paper account that runs 24 hours a day is weltiq's side of the job. Because the decision comes out as three prices, carrying it over is easy.

3 lines of setup — sign up for weltiq ({{CTA_URL}}) → My → issue a key under Connections.

I carried over run 2's decision. It was the only one of the three that actually placed a trade, it was spot, and its entry was at market, so the fill shows up immediately. These are the numbers exactly as the tool wrote them into its own book.

BTC/USDT · long · spot
entry 85,530 / stop 83,000 / target 88,000 / size $2,500 / leverage 1.0

1. Turn these numbers into a rule document — entry is "if there is no position, buy on the next closed candle" (how a market entry is written as a rule), and the exit is two fields: stop 83,000 and target 88,000.
2. Convert the amount into a quantity — 2,500 ÷ 85,530 = 0.029 BTC. The rule has no amount field, only a quantity field.
3. Attach one paragraph of plain-language reasoning (what you looked at before going in).
4. Create a strategy container and set stop conditions (max loss, max duration). Without stop conditions it will not be created at all.
5. It fills on the next candle.

The fill on screen

Look at the FILLS panel in the middle. 0.029 BTC filled at 85,435.88, with a fee of 2.4776 USDT attached. That is 0.11% below the 85,530 entry the tool called for. In the ORDERS panel above it, the stop order (stop_market) went on at the same moment as the fill — write the stop price into the rule and it gets placed without anyone watching.

Once I had checked it, I stopped and deleted it. Stop to delete takes about 100 seconds (the holding is liquidated first, and then it is removed).

The fields that did not carry over are worth writing down too. A strategy label like momentum_breakout, a confidence of 0.65, a deadline of "within 48 hours" — the rule document has nowhere to put those three. The reasoning attaches as a separate field, but the rule does not reproduce that reasoning. The rule is only "buy now, cut at 83,000, sell at 88,000".

6. After using it

What was good

1. 0 keys. This had the lowest install friction of anything in this series. No model key, no market-data key, no sign-up.
2. It does not hide disagreement. When four agents split, it shows them split, and the final decision-maker writes down why it discounts one of them. In run 1 it caught that the order-book numbers in the risk report contradicted each other and wrote that it was "therefore marking that item down".
3. The decision becomes a rule directly. Entry, stop, target, quantity and reward-to-risk already come out as numbers, so carrying them over takes almost no work.
4. The dashboard is substantial. You can read the per-agent reports as tabs, which stops you from glancing at the verdict and moving on.

What fell short

1. The same question gets a different organization. Exactly as measured in section 4. Without the fixed entry point there is no reproducibility.
2. The safety rule lives inside one agent only. "Minimum 2:1 reward-to-risk" is the final decision-maker's rule, so on any path that does not go through it, the rule vanishes.
3. Prediction-market search ignores the query. Ask it for "Bitcoin price" and American football games and election markets come back. It does not raise an error — it gives a plausible-looking wrong answer. The final decision-maker did notice and marked it "cannot verify", which is fortunate, but that step is effectively not running.
4. It cannot learn from the trades it declined. Prediction records are tied to trade rows, so the predictions from a decision that ended in WAIT are never stored. A decision that was right to hold off leaves nothing behind to learn from.

Cost

7. What to do next

Start by measuring one run with bin/autopilot.sh analyze "BTC". The result can differ from what you get by asking in plain language, and that difference is what decides whether you keep using this tool. Then fix the two --allowedTools lines and put it on cron.

The next part looks at a tool in the same "Claude plugin" family that sends orders out to a real broker. This one stops at the decision and leaves execution to someone else; that one says it will handle execution itself — so it gets stuck in exactly the opposite places.

weltiq setup — 3 lines 1. Sign up: {{CTA_URL}} 2. My → Connections → issue an API key 3. claude mcp add weltiq --header "Authorization: Bearer <key>" https://weltiq.ai/mcp

You can carry this article's decision over into a rule as it stands and run it on a paper account 24 hours a day.

Every command, output and number in this article came from runs actually performed on 2026-09-22. No real money moved in any order; all of it is simulated. None of it is a trading opinion. The trial and error, raw logs and defect list not written up here are in the run log.