What is MCP?

Anthropic released the Model Context Protocol as an open spec in November 2024. The problem it solved: every agent host (Claude Desktop, Cursor, Windsurf, Codex) was inventing its own way to plug in tools, and every tool vendor was writing N integrations for N hosts. MCP standardizes the wire format. An MCP server exposes a list of typed tools, resources, and prompts; an MCP client (the host) discovers them and lets the model call them.

The transport layer has two modes. Stdio runs the server as a local subprocess of the host — the agent spawns the binary and talks to it over standard input/output. This is the dominant mode today; it requires the user to install a local CLI (e.g. pipx install keel-trade) and add it to the host’s config. HTTP/SSE runs the server remotely, with the host connecting over an authenticated network endpoint. The hosted mode is newer and adds OAuth flows for credentials.

In December 2025, Anthropic donated MCP to the Linux Foundation under the Agentic AI Foundation. That moved governance out of any single vendor and made MCP the de facto agent-tool standard alongside contributions from Google, Microsoft, and others.

An MCP server can expose three kinds of things to the agent.

Tools are functions. They have a name, a JSON-schema for arguments, and return structured output. The agent decides when to call a tool based on the user’s prompt and the tool’s description. Run a backtest, compose a strategy, search components — these are all tools on Keel’s server. Tools are the workhorse primitive; most production MCP servers consist mostly of tools.

Resources are read-only data the agent can fetch by URI. They are useful for grounding the model in context without consuming a tool slot — a component catalog, a reference document, a current portfolio snapshot. Keel exposes two resources: keel://components/catalog (the 182-component DSL library) and keel://dsl/reference/{topic} (in-depth reference docs).

Prompts are reusable instruction templates the user (or host) can invoke by name. They show up in some hosts as slash-commands. Adoption of prompts is lighter than tools; many MCP servers do not expose any.

MCP is a wire protocol. It is not:

• Not an agent loop. The agent’s decision-making (which tool to call, when to stop, how to interpret results) lives in the host — Claude Code, Cursor, etc. MCP just defines the call shape.
• Not autonomous execution. MCP does not run trades on your behalf. A server can expose a "place order" tool, but the agent calling that tool is still inside a host that the user controls. Whether the agent can call dangerous tools without confirmation is the host’s policy, not MCP’s.
• Not a way for Claude to "take over" anything. The user is always at the keyboard of the host. MCP servers see the requests the host sends them; they do not see the host’s system prompt or other tool calls. The agent is a collaborator, not an operator.
• Not a sandbox or trust layer. Installing an MCP server is granting the host (and through it, the model) the ability to call whatever the server exposes. Vet servers like you would any other piece of software with access to your systems.

Three reasons MCP is a particularly good fit for systematic trading workflows.

Compositional. A trading research workflow is naturally a tool chain. Find a signal. Compose a strategy. Backtest it. Iterate. Deploy. With MCP, an agent can call keel_components_search → keel_strategy_compose → keel_backtest_run → keel_backtest_summarize in a single prompt and present you with the results. The compositional shape matches the actual work.

Typed. Tools have JSON-schemas. The agent knows the exact argument shape, what comes back, what the error envelope looks like. This is much more reliable than scraping a web UI or asking the model to remember CLI flag syntax. Trading tools, in particular, do not tolerate slop — a typed surface makes calls verifiable.

Multi-host. The same MCP server works in Claude Code, Cursor, Windsurf, Codex, Claude Desktop, Cline, and any other compliant host. You write the integration once; the user picks their favorite agent. This is a real change from the previous world where every IDE plugin was a separate project.

A handful of MCP servers exist for Hyperliquid today. Most fall into one of two categories: price-data wrappers (read-only access to the public API, useful for analysis but no execution) and order-placement utilities (thin wrappers around the HL exchange endpoints, useful for executing trades the user has already decided on). What none of the existing third-party HL MCP servers ship is a real backtest engine underneath — they expose data or execution, not strategy validation.

For a side-by-side survey of the available Hyperliquid MCP servers and where each one fits, see the comparison post on the keel-site blog. Keel’s MCP server is in the third category: an agent-callable surface around a deterministic backtest engine plus typed component graph plus live execution that runs the same compiled artifact.

Concretely: a user installs Keel’s MCP server, opens Claude Code, and types: "Build me a funding-carry strategy on Hyperliquid using the carry signal and a funding-level regime. Backtest 2024-08 to 2026-04 and show me the decomposed P&L."

What the agent does, in order:

• Calls keel_status to confirm auth and visible tools.
• Calls keel_components_search with query "carry" and "funding regime" to find the matching components in the 182-component library.
• Calls keel_components_compose_help on the chosen components to see legal wiring patterns.
• Calls keel_strategy_compose with the DSL graph it authored — the typed strategy artifact gets validated server-side.
• Calls keel_backtest_run with the strategy ID and the requested date range. The engine runs the backtest deterministically against real Hyperliquid funding + price history.
• Calls keel_backtest_summarize to get the rolled-up metrics and decomposed P&L.

That workflow produced a verified backtest with Sharpe 2.17, +79.6% total return, −9.7% max drawdown, over 2024-08-15 to 2026-04-30. The full tearsheet lives at app.usekeel.io/share/gDXjURKqWPs8CZ4eXdqAI. The agent did not compute the Sharpe — it composed the strategy and called the engine. The engine computed the Sharpe deterministically from a serialized strategy artifact. That separation is what the protocol enables.

If you want to try Keel’s MCP server, the install is two commands:

pipx install keel-trade
claude mcp add keel -- keel mcp serve

The first command installs the keel-trade CLI from PyPI. The second registers the local stdio MCP with Claude Code (Cursor / Windsurf / Codex have equivalent one-line commands). On first call, keel auth login runs an OAuth 2.1 + PKCE loopback against app.usekeel.io and persists tokens locally; subsequent calls auto-refresh transparently.

For per-host configs (Cursor, Windsurf, Codex), the install path for both web app and CLI, and the full getting-started flow, see the getting-started docs.