Wire Claude into Hashlock Markets in 10 minutes: a hands-on MCP tutorial

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 hashlock.markets. The canonical repository is 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:

{
  "mcpServers": {
    "hashlock": {
      "command": "npx",
      "args": ["-y", "@hashlock-tech/mcp"]
    }
  }
}

This is the fastest option for development. The package auto-installs from npm, the scoped name is @hashlock-tech/mcp, 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:

1. The agent requests a nonce from the server.
2. The server returns a SIWE message containing the nonce, the domain, and an issued-at timestamp.
3. The agent signs the message with the wallet you've delegated to it.
4. 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. 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. 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.

RFQ (Request for Quote)

Tool	What it does
create_rfq	Declare an intent: "I want to swap X token for Y token, this size, on these chains."
respond_rfq	Used by market makers to submit a sealed bid against an RFQ.

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.

HTLC (Hash Time-Locked Contract) settlement

Tool	What it does
create_htlc	Lock the trader's side of the trade in an on-chain HTLC against a hash.
get_htlc	Read HTLC state — pending, claimed, refunded — across chains.
withdraw_htlc	Claim the counterparty's locked funds by revealing the preimage.
refund_htlc	Reclaim 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 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:

1. create_rfq with {from: "ETH", to: "SUI", amount, fromChain: "ethereum", toChain: "sui"}. The server returns an RFQ ID and starts the auction window.
2. Wait for respond_rfq quotes. Market makers submit sealed bids. The agent collects them, picks the best price (or applies whatever selection logic you've taught it), and accepts.
3. create_htlc on the source chain. The agent locks the ETH against the hash that the winning market maker will need to claim.
4. The market maker locks SUI on the destination chain against the same hash.
5. get_htlc to verify both legs are funded.
6. 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.
7. get_htlc again to confirm both legs are claimed. Trade is done.

If anything stalls — market maker disappears between steps 4 and 6, 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: example agent prompt

Here's a minimal prompt that gives an agent enough context to operate Hashlock as a tool:

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. No information leakage in the auction window.
• Atomic settlement. Both legs complete, or both refund. Nothing in between.
• No front-running, no MEV tax. The intent never hits the public mempool until it's already been priced.
• Cross-chain by default. Ethereum, Bitcoin, and Sui are live today. Solana and Arbitrum are next on the integration roadmap.
• Safe to retry. 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:

• Protocol home and live UI: hashlock.markets
• Canonical repo, with docs and examples: github.com/Hashlock-Tech/hashlock-mcp

If you want the npm package directly: it's on npmjs at @hashlock-tech/mcp (scoped). Don't pin a version unless you have a reason; the latest tag tracks the active release.

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.