The MCP Tool Set, Six Chains: A Tour of What AI Agents Can Actually Do on Hashlock Markets

Update, October 2026. This post was first published in April 2026. It has been revised to match the product as it is live today: six mainnet chains (Bitcoin, Ethereum, TRON, Solana, Base, Robinhood Chain), API key authentication, and the current MCP tool set. Current reference: https://docs.hashlock.markets

A practical feature highlight. If you wire an MCP-capable model (Claude, ChatGPT, 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 Request for Quote, accept a private 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 secret. No bridge. No custody. No slippage. No information leakage.

The longer answer is this post.

The tool set, at a glance

The hosted Hashlock Markets MCP server exposes 23 tools over the Model Context Protocol. They split cleanly into the phases of a trade.

Discovery:

• whoami, list_assets, list_open_rfqs, get_rfq: who you are, what trades, what is on the board.

Quote phase (sealed RFQ):

• create_rfq: the taker side. Post a Request for Quote for a specific size, asset pair and lifetime. Makers see the RFQ and answer; quoted prices never appear in a public orderbook. cancel_rfq and list_my_rfqs manage your own requests.
• quote_rfq: the maker side. A market maker quotes a price privately against an open RFQ, which opens a thread. The taker sees its quotes through list_rfq_threads and get_thread; other makers do not.
• propose_price, accept_proposal, accept_terms: counter, take the other side's counter, or accept the current terms. The initiator passes hashlock = sha256(secret) with their accept, and only the hash leaves their machine.

Settlement phase (HTLC atomic swap):

• set_swap_address: your payout and refund address for a leg.
• build_fund: an unsigned funding transaction that locks your leg against the hashlock, with a timelock that lets you refund if the swap does not complete.
• swap_status: live status of a swap: both legs, timelocks, addresses, tx hashes, and whether the secret has been revealed yet.
• build_claim: an unsigned claim that reveals the 32-byte secret. The reveal is public on chain, which is exactly what makes the swap atomic: the counterparty can now claim their side using the same secret.
• build_refund: funder-only, timelock-gated. If the counterparty never mirrors their side, the funds come back after the deadline. No trusted recovery operator required.
• broadcast_tx: relay anything you signed. list_swaps lists everything you have open or done.

Wallet proofs: wallet_proof_message, prove_wallet, remove_wallet_proof tie the addresses you receive on to your account.

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 something like "sell 2 ETH for BTC at market."

1. Agent calls create_rfq. The RFQ goes to active makers. Nothing is posted to a public book; competing makers do not see each other's quotes.

2. Makers call quote_rfq. Each quote opens a private thread with the taker. The agent reads them with list_rfq_threads, sees a short list of prices, and either negotiates with propose_price or accepts with accept_terms. If none is acceptable, the RFQ expires and no capital moves.

3. Agent funds the long leg. The initiator (the side holding the secret) funds first, with set_swap_address then build_fund and broadcast_tx. The hashlock H is sha256(P), where P is a 32-byte secret known only to the initiator. The initiator's leg always expires later than the counterparty's. This is deliberate: it prevents the race where the secret holder claims at the last moment and refunds their own leg too.

4. The counterparty mirrors on the other chain. Same hash H, shorter timelock, their asset. The agent can watch this happen via repeated swap_status calls; a leg only counts as funded once the watcher sees enough confirmations.

5. Agent calls build_claim on the leg it receives. The initiator reveals P to claim the counterparty's asset. The reveal is public on chain.

6. The counterparty claims the other leg using the same P. On every chain except Bitcoin, Hashlock's keeper does this for them. Both sides are settled. If either side fails to mirror, build_refund 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 is live on mainnet on six chains: Bitcoin (native P2WSH script), Ethereum, Base and Robinhood Chain (an EVM HTLCFactory contract), TRON (a shared TVM contract), and Solana (an HTLC program). Under the hood these are very different execution environments. At the MCP layer, they are the same tools.

Agents pass the chain as part of the asset, USDC@base or BTC@bitcoin. The server handles the hash function (sha256 everywhere, because Bitcoin Script has OP_SHA256 and no keccak), the correct script or contract, the chain's timelock (24 hours on Bitcoin, 4 hours on the others) and the confirmation threshold. 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 today's surface gets new venues for free when a chain is added.

Two transports, same tools

How you connect to the MCP server is independent from what tools you get. There are two ways to run it:

• Hosted (Streamable HTTP). Point your MCP client at https://hashlock.markets/mcp and you are done. The client discovers it needs authorization, sends you to Hashlock to approve with a wallet signature, and receives its own API key over OAuth 2.1. Clients that do not speak OAuth send a key you created yourself: Authorization: Bearer hk_live_.... Keys expire after 90 days and are revocable from the Developers page. No local install. Best for hosted agents and production deployments.

• Local (stdio via npx). Run npx -y @hashlock-tech/mcp; your client spawns it as a child process and speaks MCP over stdin/stdout. Your chain keys live in environment variables on your own machine, so this server can sign and settle without a human in the loop. It exposes 17 tools (create_rfq, respond_to_rfq, negotiate, fund_leg, claim_leg, refund_leg and friends). Best for autonomous agents and custom tooling.
  

{
  "mcpServers": {
    "hashlock": {
      "command": "npx",
      "args": ["-y", "@hashlock-tech/mcp"],
      "env": {
        "HASHLOCK_API_URL": "https://hashlock.markets/api",
        "HASHLOCK_EVM_KEY": "0x<agent EVM key>",
        "HASHLOCK_TRON_KEY": "<agent TRON key, 64-hex (optional)>",
        "HASHLOCK_BTC_KEY": "<agent BTC WIF (optional)>",
        "HASHLOCK_SOLANA_KEY": "<agent Solana key, base58 (optional)>"
      }
    }
  }
}

Things the surface deliberately does NOT include

Worth calling out, because a short 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 an agreed price, 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 hosted server returns unsigned transactions and stores no secrets. The HTLC escrow 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 refunds 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 and the listed assets are what expand, and the tool shapes do not change when they do: create_rfq simply accepts new SYMBOL@chain values. 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, Cursor, Windsurf, etc.).
2. Add https://hashlock.markets/mcp.
3. Approve the OAuth prompt with a signature from your wallet.
4. Ask your agent to post an RFQ.

Full docs and examples live at docs.hashlock.markets, and the server source at github.com/Hashlock-Tech/hashlock-mcp.