One URL for any agent runtime: the hosted Hashlock MCP endpoint

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 with OAuth for the hosted endpoint, and the current MCP tool sets. Current reference: https://docs.hashlock.markets

When the Model Context Protocol spec landed, the canonical transport was stdio: an agent spawns the MCP server as a child process and talks to it over standard input and output. That choice was reasonable. Stdio is fast, has no network surface, and on a developer's laptop it's the path of least resistance.

It is also a poor fit for almost every production deployment of an agent.

Hashlock Markets ships its MCP server over both transports. The npm package, @hashlock-tech/mcp, is the stdio path. The other path is a hosted endpoint at https://hashlock.markets/mcp, served as Streamable HTTP MCP. This post is about the second one: what it is, why it matters, and when to reach for it instead of stdio.

The protocol home page is at https://hashlock.markets and the canonical repository is at https://github.com/Hashlock-Tech/hashlock-mcp.

Why a hosted endpoint matters

The short version: most agent runtimes that run anywhere other than a developer laptop have a hard time spawning local subprocesses, and a really hard time keeping one alive across requests.

Browser extensions can't spawn subprocesses at all. Claude in Chrome, for example, talks to MCP servers over HTTP, not stdio. Serverless platforms (Vercel functions, Cloudflare Workers, Lambda) either can't spawn subprocesses at all or spin up a fresh container per invocation, which means a stdio server would have to be cold-booted on every tool call. That's not workable for a tool surface that needs auth state, in-flight RFQs, and live swap status.

Hosted orchestration platforms, the kind of system a team builds to run agents at scale, usually centralize MCP routing through an HTTP layer for the same reasons they centralize everything else: load balancing, observability, secret management, and not having one fork-bomb of an agent take down the host.

For all of those, "spawn npx -y @hashlock-tech/mcp and pipe its stdout" is the wrong question. The right question is "what URL do I point my MCP client at?" The answer is:

https://hashlock.markets/mcp

What the endpoint is, technically

It's a Streamable HTTP MCP server. The transport is the standard one defined in the MCP specification: long-lived HTTP requests carrying JSON-RPC messages, with server-sent events for streaming responses back. Any MCP client that implements Streamable HTTP (which is most of them at this point) can connect.

The hosted server exposes 24 tools covering the full trading loop:

• Discovery: whoami, list_assets, list_open_rfqs, get_rfq
• Taker side: create_rfq, cancel_rfq, list_my_rfqs, request_listing
• Maker side: quote_rfq, list_rfq_threads, get_thread
• Negotiation: propose_price, accept_proposal, accept_terms
• Settlement: set_swap_address, build_fund, build_claim, build_refund, broadcast_tx, swap_status, list_swaps
• Wallet proofs: wallet_proof_message, prove_wallet, remove_wallet_proof

One design decision shapes everything here: the hosted server is multi-tenant and strictly non-custodial. It never holds a private key and never stores a secret. build_fund, build_claim and build_refund return unsigned transactions; your agent signs them with its own wallet and relays them through broadcast_tx. The initiator generates the 32-byte secret locally, sends only its sha256 hashlock, and keeps the preimage until it is time to claim. Amounts are base-unit integer strings, exactly as in the REST API.

Authentication is OAuth 2.1. You add the URL and nothing else. The client discovers that it needs authorization, sends you to Hashlock to approve with a signature from your wallet, and receives its own API key through the standard PKCE flow. The key expires after 90 days and is revocable under Developers. Clients that do not speak OAuth send a key you minted yourself, as Authorization: Bearer hk_live_.... An agent with no browser and no email can mint one with a wallet signature alone: GET /v1/keys/nonce, then POST /v1/keys.

When to pick which transport

The decision is mostly about where the agent runs, and about who you want holding keys.

Reach for stdio (npx -y @hashlock-tech/mcp configured as a local MCP server) when:

• You're developing or prototyping on a workstation. The local-process boot is fast and you don't pay any network round-trip.
• Your agent runtime is a desktop application that already manages MCP server processes (Claude Desktop is the canonical example).
• You want zero network surface between the agent and the MCP server.
• You want the agent to settle autonomously. The local server holds chain keys in environment variables and can fund, claim and refund on chain by itself.

Reach for https://hashlock.markets/mcp (Streamable HTTP) when:

• You're deploying to a hosted runtime, a serverless platform, or a browser extension. Anything that doesn't have a friendly relationship with subprocess spawning.
• Your agent is going to be called with high concurrency and you don't want to hold N stdio servers open per tenant.
• You want a single environment-independent URL, the same one across local, staging and production.
• You want the signing step to stay with a wallet you control, outside the server.

A non-trivial number of teams use both. Local development against stdio for fast iteration; production against the hosted URL because the runtime can't spawn subprocesses.

What it doesn't change, and what it does

The trading guarantees are the same. Sealed RFQ means quotes stay private until the trader picks one. HTLC settlement means both legs of a cross-chain trade complete or both refund after their timelocks (24 hours on Bitcoin, 4 hours on the other chains, with the initiator funding the long leg). The chain coverage is the same: Bitcoin, Ethereum, TRON, Solana, Base and Robinhood Chain, all live on mainnet. The account is the same, so an RFQ posted from one transport is visible from the other.

The tool surface is not identical, and it is worth being honest about that. The local server has 17 tools with its own names (respond_to_rfq, negotiate, my_deals, deal_status, fund_leg, claim_leg, refund_leg, among others), takes human decimal amounts like "0.5", and signs for you. The hosted server has 24 tools, takes base-unit integers, and hands back unsigned transactions. Both run the same loop (post or quote, negotiate, agree, set addresses, fund, claim). If your agent reads the tool list at startup, as most MCP clients do, moving between transports is a config change; if it hardcodes tool names, it is a small prompt change too.

A small but important practical note

The hosted endpoint is a real production server, not a developer-mode demo. A trading agent pointed at it can rely on it the way it would rely on any production API.

That said, if you're operating a high-volume agent and you want local signing and settlement against the same protocol, stdio remains a perfectly good answer. Both transports are first-class.

Where to start

If you're building an MCP-capable agent and Hashlock Markets is somewhere on the integration list, here is the practical decision tree.

For a local development setup, configure your MCP client with the npm package as a local server. HASHLOCK_API_URL is required; the chain keys are all optional, and the first one configured (EVM, then TRON, BTC, Solana) opens the session:

{
  "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)>"
      }
    }
  }
}

Call whoami to confirm the session, then list_open_rfqs to test the connection.

For a production or hosted deployment, point your MCP client at https://hashlock.markets/mcp, approve with your wallet when the OAuth prompt appears, and call whoami.

The home page is https://hashlock.markets, the docs are at https://docs.hashlock.markets, and the canonical repository, including the README, tool reference, and example configs, is at https://github.com/Hashlock-Tech/hashlock-mcp.

The point of the dual-transport design is that you should not have to rebuild your agent when you move it from a workstation to production. One URL when you need it, one local process when you don't, the same protocol and the same settlement guarantees underneath.