In the last few weeks the Model Context Protocol surface for crypto trading has filled out in a hurry. Bybit shipped MCP coverage. Gemini added an agentic trading platform that speaks MCP. Alpaca's MCP server has been stable for months and is currently the most prominent result for "AI agent trading MCP" on Google. Kraken has a CLI that wraps into MCP. Hummingbot's open-source bot framework now exposes an MCP server. TraderEvolution shipped one for institutional desks. Tradingview has community MCP wrappers. The category is real, growing, and increasingly crowded.

This is good news. MCP is becoming the lingua franca for "give an AI agent a venue and let it trade", which is exactly what it should become. But almost every server in that wave shares the same shape: it's a wrapper around one venue's REST and WebSocket APIs. The agent gets a tool surface that looks like place_order, cancel_order, get_balance, get_ticker. Underneath, there's a single exchange and a single account.

That shape is great for a lot of workloads. It's also where the lines start to break for three workloads that show up the moment you push agentic trading past hobby scope. This post walks through those three, what Hashlock Markets does differently, and when each design wins.

The shape of a single-venue CEX-MCP

A typical CEX-MCP exposes the venue's API as MCP tools:

• place_order / cancel_order / get_open_orders
• get_balance / get_position / get_account
• get_ticker / get_orderbook / subscribe_trades

The agent authenticates once with API keys, the MCP holds them, and every call goes to that one exchange. This is the path of least resistance and it's the right answer for many situations: a single-venue strategy on Alpaca, a market-making loop on Bybit, a basis trade on Gemini. The MCP is doing what it's supposed to do: exposing the venue cleanly to an agent that already knows what it wants to do there.

Hashlock Markets is a different shape. Its current MCP surface is six tools centered on intents and atomic settlement:

• create_rfq and respond_rfq for sealed-bid quote flow
• create_htlc, withdraw_htlc, refund_htlc, get_htlc for hash time-locked atomic settlement

There is no place_limit_order because there is no public order book on Hashlock. There is no bridge_assets because cross-chain settlement happens inside the HTLC, not over a bridge. The agent's tool surface looks intent-shaped, not venue-shaped. That is a deliberate choice, and the rest of this post is the case for when that choice matters.

Workload 1: cross-venue price discovery without leaking the order

The cleanest use case for an agentic trader is also the one a single-venue MCP cannot answer by definition: I want the best price across multiple venues, and I do not want to broadcast my interest to public books while I look.

With a stack of single-venue MCPs, the agent can poll each venue's order book and sweep. That works for small sizes. It also leaks information: any taker reading the same books sees the same liquidity, and once the agent starts walking depth, the market sees it walking depth. For programmatic flow that is the price you pay. For larger sizes or for repeat trades, it accumulates into measurable execution shortfall.

Sealed-bid RFQ inverts that. The agent declares an intent ("I want X of asset A in exchange for asset B, settled by time T") and that intent is broadcast only to authorized market makers. Each maker quotes privately. The agent picks the best quote. The order never appears in any public book before it is committed.

In Hashlock Markets the flow is two MCP calls: create_rfq to post the intent, respond_rfq to accept the chosen quote. The agent does not have to manage venues or accounts. Makers compete privately on price, the winner settles, the rest see only that they lost.

When this matters: medium-and-up size, repeat trades, or any situation where information leakage is a measurable cost. When it doesn't: small spot orders where displayed liquidity already swallows the size.

Workload 2: cross-chain settlement without bridges

The second wall a single-venue MCP hits is anything that crosses chains. Most CEX-MCPs do not handle this at all - the venue holds custody on both sides and "cross-chain" is just a withdrawal. For DEX-MCPs, the answer historically has been a bridge: lock asset on chain A, mint or release a representation on chain B, swap there.

Bridges have a long and well-documented track record of being the most attacked surface in the entire ecosystem. They are also operationally awkward for an agent because the leg-by-leg flow has many failure modes and partial-state recoveries.

Hash Time-Locked Contracts solve the same problem with very different mechanics. Both legs of the swap are committed to the same secret hash. Either both legs reveal the secret and complete, or neither does and both refund after a timeout. There is no third party holding the assets. There is no bridge. The agent does not have to reason about partial states because there are no partial states; the swap is one logical operation that either completes or unwinds.

In Hashlock Markets this is the four *_htlc tools. For an agent, the loop is straightforward: create_htlc on chain A, create_htlc on chain B (or have the counterparty do it), withdraw_htlc to claim once both sides are funded, refund_htlc if the counterparty disappears. get_htlc exposes state for monitoring.

When this matters: any swap whose legs live on different chains. The current chain set is Ethereum, Bitcoin, and Sui, with Solana and Arbitrum on the near roadmap.

Workload 3: two AI agents trading directly

The third workload is the one most people aren't thinking about yet, and is the cleanest argument for why intent-shaped tooling matters going forward. As more trading is done by software agents, more counterparties are software agents. At some point two agents need to trade with each other - not through a venue's matching engine, but with each other directly.

That is hard to do well on a public order book because both sides are revealing intent into a market full of other agents looking for exactly that signal. It's also hard with a single-venue CEX-MCP because the venue is the counterparty model: an agent on Bybit and an agent on Gemini have no shared venue to trade in.

Sealed-bid intents handle agent-to-agent trading directly. Either agent can be a taker (create_rfq) or a maker (respond_rfq). The matching is on the protocol, not on a venue. Settlement is HTLC, so neither agent needs to trust the other's custody.

When this matters: as agentic flow grows, the share of trades that are agent-to-agent rather than agent-to-venue grows with it. Designing for that case now keeps the protocol from having to be retrofitted later.

When the single-venue shape is the right answer

This is not a "Hashlock vs everyone" pitch. The category sorts cleanly by workload:

If the agent's job is to operate a single venue well - a market-making loop, an algorithmic strategy on a specific exchange, a portfolio rebalance against custodied assets on one platform - a single-venue CEX-MCP is exactly the right tool. It is simpler, latency-optimized for that one venue, and the auth model is straightforward (API keys held by the MCP).

If the agent's job is to discover the best price across venues without leaking, settle across chains atomically, or trade with another agent directly, the venue-wrapper shape runs out of road. That is the surface Hashlock Markets is designed for.

In practice many agent stacks will end up with both: a single-venue MCP for the venue they execute in most often, and an intent-shaped MCP for the cross-venue, cross-chain, agent-to-agent workloads. The two compose cleanly because both speak the same MCP wire format.

Connecting an agent to Hashlock Markets

Two transports are supported, same six tools either way:

stdio (good for local development, IDE-embedded agents, anything that can spawn a child process):

npx -y @hashlock-tech/mcp

Streamable HTTP (good for hosted runtimes, containerized agents, anything where spawning local processes is awkward):

https://hashlock.markets/mcp

Auth is Sign-In with Ethereum (SIWE) - the agent signs a SIWE message with its wallet, gets back a JWT, and uses that on subsequent calls. The wallet that signs in is the wallet that settles HTLCs.

The package is @hashlock-tech/mcp on npm. Source and the canonical README are at https://github.com/Hashlock-Tech/hashlock-mcp.

The category direction

The "AI agent trading MCP" category is converging on two layers that will sit alongside each other for a while:

The venue layer - single-venue MCPs that wrap each major exchange or trading platform. This layer is filling out fast and is broadly a good thing.

The protocol layer - intent-shaped MCPs that handle the workloads no single venue can: cross-venue discovery without leakage, cross-chain atomic settlement, and agent-to-agent matching. This layer is much earlier and Hashlock Markets is one of the bets on it.

If you're picking what to wire your agent into, the question to ask is which layer your workload lives at. For single-venue work, pick a venue MCP. For the workloads that cross venues, chains, or agents, the intent layer is what you want.

More on the protocol design at https://hashlock.markets - the docs page walks through sealed-bid RFQ and HTLC settlement in more detail.