Six MCP Tools, Three Chains: A Tour of What AI Agents Can Actually Do on Hashlock Markets

A practical feature highlight. If you wire an MCP-capable model — Claude, GPT, Cursor, Windsurf, a custom agent — into the Hashlock Markets MCP server, what can it actually do on your behalf, end-to-end?

The short answer: post a sealed-bid Request for Quote, accept a private counter-quote, fund a hash time-locked contract on chain A, wait for the counterparty to mirror on chain B, then atomically settle by revealing a single 32-byte preimage. No bridge. No custody. No slippage. No information leakage.

The longer answer is this post.

The six tools, at a glance

Hashlock Markets currently exposes a tight surface of six tools over the Model Context Protocol. They split cleanly into two phases of a trade.

Quote phase (sealed-bid RFQ):

• create_rfq — the taker side. Post a Request for Quote for a specific size, asset pair, and settlement window. Hashlock broadcasts it as a sealed bid to market makers; quoted prices never appear in a public orderbook.
• respond_rfq — the maker side. A market maker quotes a price privately against an open RFQ. The taker sees quotes; other makers do not. No information leakage to the broader market.

Settlement phase (HTLC atomic swap):

• create_htlc — locks funds on one chain against a SHA-256 hash commitment, with a timelock that auto-refunds if the swap doesn't complete.
• get_htlc — queries live status of a trade: both sides' lock transactions, contract addresses, amounts, timelock expiries, and whether either side has revealed the preimage yet.
• withdraw_htlc — claims the locked funds by revealing the 32-byte preimage. The reveal is public on chain, which is exactly what makes the swap atomic — the counterparty can now claim their side using the same preimage.
• refund_htlc — sender-only, timelock-gated. If the counterparty never mirrors their side, funds come back automatically after the deadline passes. No trusted recovery operator required.

Six tools. Two phases. That's the entire surface — and it's enough to support a full cross-chain swap across any pair the protocol supports.

The end-to-end flow, as an agent executes it

Here is the actual sequence an agent runs when a user says something like "sell 2 ETH for BTC at market."

1. Agent calls create_rfq. The RFQ is broadcast to active makers as a sealed bid. Nothing is posted to a public book; competing makers don't see each other's quotes.

2. Makers call respond_rfq. Each quote is private to the taker. The taker (or the agent on their behalf) sees a short list of prices and sizes. If none are acceptable, the RFQ expires and no capital moves.

3. Agent calls create_htlc on the taker's chain. Funds move into a hash time-locked contract. The hash H is derived from a 32-byte preimage P known only to the taker. The timelock is chosen so that the taker's side expires later than the maker's — this is deliberate, to prevent a class of race attacks where the counterparty reveals and takes both sides.

4. Maker mirrors with their own create_htlc on the other chain. Same hash H, shorter timelock, their asset. The agent can watch this happen via repeated get_htlc calls.

5. Agent calls withdraw_htlc on the maker's chain. The taker reveals P to claim the maker's asset. The reveal is public on chain.

6. The maker sees the reveal and claims the taker's side using the same P. Both sides atomically settled. If either side fails to mirror, refund_htlc returns the funds after the timelock.

The whole thing is atomic in the cryptographic sense: either the swap completes on both chains, or neither side moves. There is no intermediate state where one party has both assets and the other has none.

Why the surface stays identical across chains

Today the protocol supports three chains — Ethereum (EVM HTLC contract), Bitcoin (native Script / Tapscript HTLC), and SUI (Move-based HTLC object). Solana and Arbitrum are on the roadmap. Under the hood these are three very different execution environments. At the MCP layer, they are the same six tools.

Agents pass the chain as a parameter. The server handles the chain-specific hash function (SHA-256 is used across all three for compatibility), the correct script template, fee estimation per chain, and confirmation thresholds. From the agent's perspective, settling a BTC leg looks identical to settling an ETH leg, modulo different block times.

This is the whole point of the abstraction. An agent built against the v0.1.7 surface will continue to work when Solana and Arbitrum land; it gets new venues for free.

Two transports, same tools

How you connect to the MCP server is independent from what tools you get. The protocol supports two transports:

• Remote (streamable-http). Point your MCP client at https://hashlock.markets/mcp, include an Authorization: Bearer <token> header, and you are done. No local install. Best for hosted agents and production deployments.

• Local (stdio via npx). Run the npm package hashlock-tech/mcp locally — your client spawns it as a child process and speaks MCP over stdin/stdout. Best for local development, custom tooling, and anything where you want the server running on your own machine.

Authentication uses SIWE (Sign-In With Ethereum). Sign a message once at hashlock.markets/sign/login, receive a bearer token, and either pass it as an environment variable (stdio) or an HTTP header (remote). Tokens are short-lived; re-sign when they expire.

Things the surface deliberately does NOT include

Worth calling out, because a shorter surface is a design decision:

• No order book endpoint. There is no public book. RFQs are sealed by design. Quotes are visible only to the taker.
• No slippage parameter. You execute against a committed quote, or you don't execute. There is no "up to N basis points of slippage" knob because there is no AMM curve to slip against.
• No approval / unlimited-allowance tool. Each HTLC funding is its own explicit transaction. We don't encourage blanket spend authorizations.
• No custody endpoints. Hashlock Markets never holds taker or maker funds. The HTLC contract is the entire "escrow" — cryptographic, not custodial.

That last point is what actually makes the stack agent-safe. The worst an attacker who compromises an agent can do with the Hashlock surface is lock some of the user's own funds into an HTLC — which will refund automatically after the timelock if not claimed. They can't drain a balance, rug a book, or pull a rug-pool exit.

What changes next

The MCP tool surface is deliberately stable. The chains are what expand: Solana and Arbitrum are both in flight, and the tool shapes will not change when they land — create_htlc simply accepts new values for the chain parameter. Makers get new venues; takers get new routes; agents keep working.

If you want to try it, the fastest path is:

1. Install any MCP-capable client (Claude Desktop, Cursor, Windsurf, etc.).
2. Point it at https://hashlock.markets/mcp.
3. Get a SIWE token at hashlock.markets/sign/login.
4. Ask your agent to post an RFQ.

Full docs, examples, and the canonical registry entry live at hashlock.markets.