Wire Claude into Hashlock Markets in 10 minutes: a hands-on MCP tutorial
--
A practical walkthrough for connecting any MCP-capable AI agent to Hashlock Markets so it can place sealed-bid RFQs and settle cross-chain trades atomically with HTLCs.
Hashlock Markets is an intent-based crypto trading platform built around two ideas that DeFi has talked about for years but rarely shipped together: sealed-bid RFQ so quotes are private, and HTLC atomic settlement so cross-chain trades complete or revert as a unit, with no escrow in the middle. Sitting in front of both is a Model Context Protocol (MCP) server, which means any MCP-capable AI agent — Claude, GPT, a custom runtime — can drive the entire trading lifecycle without a human at the console.
This post is the short, practical version: how to set that up, what each piece does, and the specific tool calls an agent will make in a normal trade.
If you want the protocol home page, it lives at https://hashlock.markets. The canonical repository is at https://github.com/Hashlock-Tech/hashlock-mcp.
Step 1: pick a transport
There are two ways to connect an agent to the Hashlock MCP server.
stdio (local). Your agent spawns the server as a child process. Configure it like any other MCP server in your client of choice, with npx -y @hashlock-tech/mcp as the command. This is the fastest option for development. The package auto-installs from npm and you don't have to worry about hosting anything.
Streamable HTTP (hosted). Point your agent at https://hashlock.markets/mcp. This is the right choice for any agent runtime that can speak Streamable HTTP MCP — including Claude in Chrome, custom orchestrators, hosted platforms, and anything that doesn’t have a friendly relationship with spawning local processes. One URL, no install.
Both transports expose the same six tools described below, with the same semantics. Pick whichever fits your deployment.
Step 2: sign in with Ethereum
Authentication is SIWE — Sign-In with Ethereum. No passwords, no API keys to leak in a .env file, no long-lived bearer tokens.
The flow is the standard SIWE handshake. The agent requests a nonce from the server. The server returns a SIWE message containing the nonce, the domain, and an issued-at timestamp. The agent signs the message with the wallet you’ve delegated to it. The agent submits the signature; the server verifies it on-chain and opens a session.
A few practical implications worth being explicit about. The agent never holds a long-lived secret; it holds a key, and you can revoke access by rotating the key. You can scope the wallet — most operators give the agent a dedicated trading wallet rather than handing it the keys to their main treasury. Funded with a per-day budget, an agent with a scoped wallet has a hard ceiling on what it can do, and you can audit every action by following the on-chain footprint. Sessions are per-wallet, not per-agent-runtime, so if you swap from Claude to a different MCP client tomorrow, the same SIWE auth works as long as the same wallet signs.
If you’re building this into a product, the SIWE flow takes about a screen of code per agent runtime. The MCP server handles the protocol details on the server side.
Step 3: understand the six tools
Once you’re connected and authenticated, the agent has six tools available. They map cleanly onto the trading lifecycle.
On the RFQ side, create_rfq declares an intent: "I want to swap X for Y, this size, on these chains." respond_rfq is used by market makers to submit sealed bids against that intent.
create_rfq is the trader's entry point. Calling it broadcasts the intent privately to the network of market makers connected to Hashlock. Each market maker sees the request, prices it, and submits a quote with respond_rfq. No market maker sees a competitor's price. That's the sealed-bid part: the auction window stays private until the trader picks a winner.
This matters for two reasons. First, market makers can quote tighter, because they aren’t worried about being copied or undercut by a faster competitor reading the same public order book. Second, the trader’s intent doesn’t leak into the public mempool, so there’s no front-running and no MEV tax on the fill.
On the settlement side, four tools cover the HTLC lifecycle. create_htlc locks the trader's side of the trade on-chain against a hash. get_htlc reads HTLC state — pending, claimed, refunded — across chains. withdraw_htlc claims the counterparty's locked funds by revealing the preimage. refund_htlc reclaims your own funds if the counterparty doesn't complete in time.
The atomic settlement guarantee falls out of the HTLC math. Both sides lock funds against the same hash. The first party to reveal the preimage to claim their counterparty’s funds also publishes that preimage on-chain, which the other party can then use to claim their own counterparty’s funds. Either both legs of the swap complete, or both legs refund after the timeout. There is no state where one side has been paid and the other hasn’t.
For an agent that’s running unattended, the practical version of this is: failed steps are safe. A network error during withdraw_htlc doesn't leave the trader exposed — they can retry, and if they don't, the timeout triggers refund_htlc. An agent built on this primitive can be aggressive about retries without putting capital at risk.
Step 4: a normal trade, end to end
Here’s the call sequence an agent makes to swap, say, ETH on Ethereum for SUI on Sui.
It calls create_rfq with the asset pair, size, source chain, and destination chain. The server returns an RFQ ID and starts the auction window. Market makers submit sealed bids via respond_rfq. The agent collects them, picks the best price (or applies whatever selection logic you've taught it), and accepts.
It calls create_htlc on the source chain to lock the ETH against the hash that the winning market maker will need to claim. The market maker locks SUI on the destination chain against the same hash. The agent calls get_htlc to verify both legs are funded.
It calls withdraw_htlc on the destination chain, revealing the preimage. The market maker watches the preimage hit the chain, then uses it to claim the ETH. A final get_htlc confirms both legs are claimed. Trade is done.
If anything stalls — market maker disappears between funding and claim, or a chain congests past the timeout — the agent calls refund_htlc and recovers its locked funds. No loss, no support ticket.
The whole sequence is six tool calls in the happy path, and idempotent end-to-end. An agent that crashes mid-flow and restarts will not double-spend; it’ll observe the existing state via get_htlc and pick up where it left off.
Step 5: an example agent prompt
A minimal prompt that gives an agent enough context to operate Hashlock as a tool reads roughly like this:
You have access to the Hashlock Markets MCP server. Your job is to swap from-asset for to-asset in the size the user requested. Use create_rfq to start the auction, wait for at least three quotes via respond_rfq events, and accept the best price. Then use create_htlc to lock funds, get_htlc to verify both legs, withdraw_htlc to claim, and refund_htlc if the counterparty doesn’t complete within the timeout. Surface every step’s output to the user.
For Claude specifically, that prompt plus the MCP config from Step 1 is enough to start. The model already knows how to call MCP tools; you don’t need a custom orchestration layer.
What you get
When the pieces are wired together, the agent’s trading surface has properties that are hard to assemble out of public-orderbook DEXs. Private quoting, with no information leakage in the auction window. Atomic settlement, where both legs complete or both refund and nothing in between. No front-running and no MEV tax, because the intent never hits the public mempool until it’s already been priced. Cross-chain by default, with Ethereum, Bitcoin, and Sui live today and Solana and Arbitrum next on the integration roadmap. Safe to retry, because idempotency on the RFQ flow plus HTLC refunds means a crash-restart loop doesn’t leave money on the table.
That set of guarantees is what makes the protocol usable by software, not just humans. An AI agent doesn’t need to be careful in the way a human trader has to be careful, because the failure modes are bounded by the protocol itself.
Where to go next
Two pages will cover most of what you need. The protocol home and live UI is at https://hashlock.markets. The canonical repo, with docs and examples, is at https://github.com/Hashlock-Tech/hashlock-mcp.
The next decade of DeFi is going to be operated by software, not by humans clicking in browser tabs. The infrastructure for that has to be private, atomic, and cross-chain — and exposed to agents in a way they can actually use. That’s the bet behind Hashlock Markets, and the MCP server is the part of it you can plug into your agent today.
