Drive Keel's Hyperliquid backtest engine from your agent.
Keel MCP is the Hyperliquid backtest engine surfaced as an MCP server. A typed tool surface, 182 components, real Hyperliquid fees and funding, and a compiled-artifact handoff to live execution. One pipx install, one claude mcp add, stdio transport — runs locally next to your agent.
One pipx command. One host registration.
Same Python entrypoint — keel mcp serve — across every host. Pick your client, run the snippet, and the agent has 22 typed tools and the full Hyperliquid backtest engine.
Install and register
The fastest path. Two shell commands, then ask Claude to connect.
Add to .cursor/mcp.json
Same Python entrypoint, declared in the host config file.
Any stdio MCP client
One stdio entrypoint works for every MCP-compatible host.
Three reasons most trading MCPs don't help an agent ship a strategy.
The MCP ecosystem is full of API wrappers. Keel MCP wraps a research-to-live engine instead — typed composition, deterministic backtest, compiled artifact, bit-for-bit live parity.
They expose get_funding_rate and place_order. The agent calls them, gets data, and you still don't have a strategy — just a faster way to send orders the agent has not actually validated.
Keel MCP exposes composition, validation, backtest, and a compiled artifact. The agent builds a strategy with typed components, proves it on real history, and only then can it deploy.
TradeStation, IBKR, and Alpaca MCPs assume traditional brokers and equity instruments. None of them model perp funding accrual or Hyperliquid-native execution paths.
Keel MCP is Hyperliquid-only on purpose. Funding accrues into the equity curve hourly, fees use the live HL schedule, and orders sign via native HL delegation — non-custodial.
Wrapping a REST API gives an agent the same surface a human has. It can submit a bad strategy at machine speed. The thing that catches a bad idea is the engine, not the wire.
Keel MCP wraps the research-to-live engine: typed-component DSL, edit-time validation, deterministic compile, bit-for-bit parity. The same artifact backtests and trades live.
Under the hood
Structured strategy engine
Strategies are composable pipelines of typed components. The system validates every connection at edit time — errors caught before you backtest, not after you deploy.
AI built on the same system
AI doesn’t generate code — it composes from the same components you use. It understands valid connections, constraints, and trade-offs. Every strategy it builds is structurally valid.
Detailed backtest reports
Sharpe, Sortino, max drawdown, win rate, trade-by-trade logs. Compare runs side by side. Real fee and slippage modeling.
Version control for strategies
Every edit creates a new version. Compare any two versions side by side. Tag releases, restore previous versions, fork strategies. Your full history, always recoverable.
Auditable execution logs
Every live run is logged — what the strategy calculated, what orders executed, what filled. Full transparency.
Non-custodial by design
Your keys never touch our servers. Keel uses Hyperliquid’s native delegation. Sign once, revoke anytime.
A typed tool surface and two read-only resources.
Every tool the Keel CLI exposes is also an MCP tool, addressable by name. The two resources give the agent full DSL grounding without round-tripping through tool calls.
MCP tools by domain
Every tool the CLI exposes is also an MCP tool — the agent calls them by name.
keel_statuskeel_auth_login
keel_strategy_composekeel_strategy_forkkeel_strategy_diffkeel_strategy_getkeel_strategy_deletekeel_strategy_searchkeel_strategy_memory_readkeel_strategy_memory_write
keel_backtest_runkeel_backtest_summarizekeel_audit_list_lastkeel_audit_replay
keel_components_searchkeel_components_compose_helpkeel_accounts_listkeel_share_createkeel_helpkeel_doctor
2 MCP resources
Read-only context the agent can subscribe to for full DSL grounding — no round-trip through tool calls.
keel://components/catalogThe full 182-component registry with types, slots, and parameter schemas — the agent reads this to compose valid pipelines.
keel://dsl/reference/{topic}Topical DSL grounding: phases, types, slots, composition, normalization, best_practices. One MCP resource per topic.
A real backtest, run end-to-end from an agent.
One backtest the Keel MCP can drive end-to-end: a funding-carry strategy composed by Claude, run against real Hyperliquid funding and price, and returned as a shareable tearsheet.
Funding-carry on Hyperliquid perps
One backtest the Keel MCP can drive end-to-end — a funding-carry strategy composed by an agent over MCP, run against real Hyperliquid funding and price, returned as a shareable tearsheet. Period: 2024-08-15 → 2026-04-30 (20 mo).
Verified Keel backtest. Past performance is not indicative of future returns.
Common questions
What is the Keel MCP, exactly?
The keel mcp serve subcommand of the keel-trade Python package on PyPI. It launches a local MCP server over stdio and exposes 22 typed tools plus two read-only resources to any MCP-compatible host — Claude Code, Cursor, Windsurf, Codex CLI, ChatGPT desktop Connectors, or any other stdio client. The server runs on your machine, alongside the agent.
How do I install it?
pipx install keel-trade puts the keel CLI on your PATH. claude mcp add keel -- keel mcp serve registers it with Claude Code. Then open Claude Code and say "Connect to Keel" — the agent calls keel_auth_login, your browser opens for the OAuth flow, and tokens persist to ~/.keel/config.yaml. After that, every session is logged in until the refresh token expires.
Which hosts does it work with?
Anything that speaks the MCP stdio protocol: Claude Code, Cursor, Windsurf, Codex, and generic stdio clients. The per-host config matrix lives at /docs/sdk/agent-setup — Claude Code uses claude mcp add, Cursor reads .cursor/mcp.json, Windsurf and Codex use their own JSON config files. The Python entrypoint (keel mcp serve) is identical across all of them.
Is there a hosted endpoint?
Keel MCP runs locally over stdio. That keeps your strategy code and credentials on your machine, makes auth a one-time browser flow, and removes a network hop between the agent and the engine. A hosted endpoint may come later if usage patterns call for it; the local stdio install is the supported path.
Does it support live trading?
Yes, but gated. The default toolset is read-only plus backtest and share. Live-mutation tools — live_deploy, live_pause, live_resume, live_stop — only appear in the tools/list response when two conditions are both true: your OAuth session has the live scope (request via keel auth login --scope live) AND your local machine is armed (keel arm live set). Defense in depth: scope is the cloud check, arming is the host check.
What does the backtest engine model?
Real Hyperliquid fees on every fill, hourly funding accrual decomposed from price P&L, per-asset slippage in basis points that you set explicitly, and a buffered rebalancer that respects exposure caps and volatility targeting at the portfolio level. The output is deterministic — same inputs, same numbers, every time — and the same compiled artifact is what runs live.
What's the auth story?
OAuth 2.1 + PKCE. keel auth login opens a browser, the redirect lands on a local loopback, tokens persist to ~/.keel/config.yaml, and refresh is automatic. A --key flag accepts a long-lived API key for headless environments. Hyperliquid execution uses native delegated signing — your wallet signs a delegation once on the HL frontend, and Keel never holds funds or private keys.
Keep exploring
MCP servers for Hyperliquid trading
Category overview: where Keel MCP fits in the broader landscape of Hyperliquid MCP servers.
Trade Hyperliquid from Claude
Use-case walkthrough: composing, backtesting, and deploying a strategy entirely from Claude Code.
Agent setup — full host matrix
Per-host MCP config for Claude Code, Cursor, Windsurf, Codex, and generic stdio clients.