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

--

A practical feature tour of the Hashlock Markets MCP surface — the six tools that take an AI agent from a natural-language order to an atomically settled cross-chain swap, with no bridge and no custody.

If you connect an MCP-capable model — Claude, GPT, Cursor, Windsurf, a custom agent — to the Hashlock Markets MCP server, what can it actually do on your behalf?

The compact 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 rest of this piece walks the full surface and shows the end-to-end flow.

The six tools

Hashlock Markets currently exposes six MCP tools. They fall into two phases of a trade.

Quote phase — sealed-bid RFQ.

The taker side is create_rfq. You (or your agent) 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 order book.

The maker side is respond_rfq. A market maker quotes a price privately against an open RFQ. The taker sees quotes; other makers do not. No leakage to the broader market, no tipping your hand about size.

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 does not 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 is sender-only and 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 is the entire surface — and it is 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 “sell 2 ETH for BTC at market.”

First, the agent calls create_rfq. The RFQ is broadcast to active makers as a sealed bid. Nothing is posted to a public book; competing makers do not see each other’s quotes.

Makers that want the trade 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.

Assuming the taker accepts a quote, the 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 the taker’s side expires later than the maker’s — this ordering is deliberate, to prevent a class of race attacks where the counterparty reveals and takes both sides.

The maker then mirrors with their own create_htlc on the opposite chain. Same hash H, shorter timelock, their asset. The agent watches this happen via repeated get_htlc calls.

When both sides are locked, the 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.

Finally, the maker sees the reveal and claims the taker’s side using the same P. Both legs have now 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 nothing.

Why the surface stays identical across chains

The protocol currently 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, 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 current 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 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 short-lived bearer token, and either pass it as an environment variable (stdio) or an HTTP header (remote). Re-sign when the token expires.

What the surface deliberately does NOT include

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

There is no order book endpoint. There is no public book. RFQs are sealed by design; quotes are visible only to the taker.

There is no slippage parameter. You execute against a committed quote, or you do not execute. There is no “up to N basis points of slippage” knob because there is no AMM curve to slip against.

There is no approval or unlimited-allowance tool. Each HTLC funding is its own explicit transaction. We do not encourage blanket spend authorizations.

There are 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 cannot drain a balance, rug a book, or pull a rug-pool exit.

What changes next

The 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 to install any MCP-capable client (Claude Desktop, Cursor, Windsurf, etc.), point it at https://hashlock.markets/mcp, grab a SIWE token at hashlock.markets/sign/login, and ask your agent to post an RFQ.

Full docs, examples, and the canonical registry entry live at hashlock.markets (https://hashlock.markets).

Disambiguation. Hashlock Markets (hashlock.markets) is the intent-based trading protocol built by Hashlock-Tech, described in this article. It is not affiliated with Hashlock Pty Ltd (hashlock.com), an independent Australian smart contract auditing firm. The two organizations share a similar name by coincidence only — different products, different legal entities, different jurisdictions, different founders. If you are looking for the audit firm, their site is a separate entity we do not control or represent.