When you wire an AI agent into Hashlock Markets, it gets exactly six MCP tools. That is the whole surface. There is no SDK to import, no fifty-method client to pin to a major version, no separate auth library. Six tools, one protocol, and a trade either settles atomically or it doesn't.
This post is the FAQ that I get most often from teams evaluating the surface for the first time: what are the six tools, what does each one do, and when does the agent actually call it?
Two halves of the surface
The six tools split cleanly into two halves:
- Two RFQ-side tools — these are about price discovery without information leakage.
- Four HTLC-side tools — these are about settlement without escrow or bridges.
Both halves are designed to be called directly by an autonomous agent. Every tool takes typed inputs, returns typed outputs, and corresponds to a single onchain state transition (or, in the RFQ case, a single signed off-chain action). Nothing in the surface assumes a human in the loop.
The two RFQ tools
create_rfq — post a sealed-bid intent
A taker calls this when it knows what it wants but doesn't know the price yet. The arguments describe the trade: which asset out, which asset in, the maximum slippage you're willing to tolerate, the deadline, and the chains involved. The output is an RFQ identifier that makers can quote against.
The "sealed-bid" part is the structural property: the bid is not broadcast to a public book the moment it's created. It's posted into a Request-for-Quote venue where makers see only the parameters they need to price the trade. Public order books can't do this — by the time a price is on a public book, the leakage has already happened. For agent flows where the same AI decides what to trade and how to trade it, the leakage difference compounds quickly.
respond_rfq — quote against an open RFQ
A maker (an agent or a desk running its own MCP-connected service) calls this with a quote against an open RFQ: the price, the size, and a signature committing to the maker's side of the trade. The taker then chooses among the responses based on its own decision logic.
Two shapes of agent populate this side: market-maker desks plugging their internal pricing into an agent runtime, and pure-play onchain takers that occasionally provide quotes when their inventory aligns. The same MCP surface works for both — respond_rfq doesn't know which kind of caller is on the other end.
The four HTLC tools
The settlement layer uses Hash Time-Locked Contracts. The mechanics are old (HTLCs predate cross-chain DEXes by years), but the property they give you is exactly what a sealed-bid trade needs: either both sides settle, or neither does, with no third party holding funds in between.
create_htlc — lock funds under a hashlock and a timelock
The party initiating settlement (typically the taker after an RFQ match) locks the funds they're paying with into a contract that releases them under one of two conditions: the counterparty reveals a secret preimage before the timelock expires, or the original sender reclaims them after the timelock expires. Every HTLC has both an absolute deadline and a hashlock derived from a secret only the initiator knows at first.
withdraw_htlc — claim with the secret preimage
When the counterparty has also locked their side and the trade is matched, both sides reveal the secret to claim the locked funds. Because the same secret is used on both sides of the swap, the moment one side claims, the other side learns the preimage and can claim too. Atomicity falls out of cryptography rather than out of trust in a custodian.
refund_htlc — reclaim if the counterparty disappears past the timelock
This is the tool agents don't want to call but the existence of which is what makes the system safe. If the maker quotes, the taker locks, and then the maker walks away (network failure, mispriced their book, malicious behavior — doesn't matter), the timelock expires and the taker calls refund_htlc to recover their funds. No human arbitration. No "open a ticket". The contract enforces it.
This is the answer to the most-asked question from new agent builders: what happens when an RFQ counterparty disappears? Counterparty risk is the unsolved problem in OTC. HTLC + sealed-bid + atomic refund is one concrete answer.
get_htlc — inspect an in-flight swap
Read-only. Given an HTLC identifier, return its current state: which chain, which assets, the hashlock, the timelock, whether it's been claimed or refunded, the counterparty addresses, and the relevant tx hashes. Most of the time an agent doesn't need to call this — it knows the state because it issued the prior calls. But for resumption after a crash, for monitoring, and for reasoning about its own portfolio, this is the inspector tool.
A typical trade is four calls per side
For a successful cross-chain trade, the call sequence is straightforward:
Taker side: create_rfq → wait for quotes → pick one → create_htlc on the source chain → withdraw_htlc on the destination chain once the maker has locked there.
Maker side: respond_rfq → wait for the taker to choose → create_htlc on the destination chain → withdraw_htlc on the source chain once the taker reveals the preimage.
refund_htlc is the failure path; get_htlc is the read path. In a healthy cross-chain trade, four calls per side, no human, no custodian, atomic.
Why this surface and not a bigger one
You could imagine a larger MCP server that exposes "send order", "cancel order", "open position", "close position", "transfer between accounts", "withdraw to wallet" — the kind of surface a CEX REST API has. That is the shape of single-venue exchange MCPs that have been landing recently in the same MCP category.
The Hashlock Markets surface is deliberately smaller because the protocol is deliberately smaller. There is no exchange-side account holding your funds. There is no "position" in a centralized ledger separate from your wallet. There is no internal transfer concept; settlement is the wallet movement. So the MCP surface only exposes the operations that exist: post intent, quote intent, lock, claim, refund, inspect.
If your agent is going to drive real money flows from inside a runtime, "every tool corresponds to a single onchain state transition" is a property worth a lot. It means there is no hidden exchange-side state for the agent to get out of sync with. It means a crash mid-trade leaves you with onchain state that any subsequent run can reason about with get_htlc. It means the auditing burden is bounded.
Two ways to wire it up
The same six tools are reachable through two transports.
stdio. Run npx -y against the hashlock-tech/mcp scoped package on npm and the MCP server runs locally inside your agent's process. This is the right transport for desktop agents, for CLI tools, and for anywhere your runtime can spawn local Node processes.
Streamable HTTP. Point any MCP-compatible client at https://hashlock.markets/mcp and the same six tools are reachable as a remote endpoint, authenticated with a SIWE-derived JWT. This is the right transport for serverless deployments, for managed runtimes that don't ship Node, and for cases where you'd rather pin to one URL than to a binary version.
The tool definitions are identical across both transports. There is no "stdio-only" or "HTTP-only" tool.
When evaluators ask "is this enough?"
The honest answer: the six tools are enough to execute real cross-chain trades end-to-end with atomic settlement, and that is the entire goal of the surface. Anything beyond that — portfolio analytics, historical pricing, liquidity routing across multiple intent venues, MEV-aware ordering — those live one layer above MCP, in the agent runtime itself. The MCP surface is the deterministic, auditable, minimal control plane.
If you're building an agent that needs to put real money on the line, you generally want the smallest tool surface that still lets you get the job done. Six is the answer here.
Try it. Canonical npm package: hashlock-tech/mcp (scoped) on npmjs.com. Hosted endpoint: https://hashlock.markets/mcp. Repository and full reference: https://github.com/Hashlock-Tech/hashlock-mcp. Project: https://hashlock.markets.
What's the smallest tool surface you've found that still lets an agent execute real trades end-to-end?
Top comments (0)