The MCP Ecosystem Is Starting to Compose: A Friday Field Note From Hashlock Markets
A community piece on how the Model Context Protocol ecosystem has matured in 2026, and where intent-based cross-chain swaps fit into a stack of agent tools.
It is Friday, so this is a less technical post than usual. No new features to ship, no tutorials to run — just a field note on what we are seeing in the broader MCP ecosystem, and where we think an intent-based settlement protocol like Hashlock Markets actually plugs in.
A year ago the MCP conversation was dominated by one question: will tool use standards matter? That question has quietly been answered. Today the conversation is about composition — how agents stitch together multiple domain-specialised MCP servers into a single workflow, and which primitives need to exist for that composition to actually deliver value.
The shape the ecosystem has settled into
Strip away the marketing and the MCP servers that have gained real traction in the last twelve months fall into a handful of recognisable categories. It is worth naming them, because the categories matter more than any individual server.
Data access servers. These are the quiet workhorses. Filesystem access, database connectors, knowledge bases, RAG-over-your-docs — servers whose job is to give an agent eyes on structured information it would otherwise have to be told about. Nothing an agent builds reliably happens without these. Early MCP adopters underestimated them. Nobody does anymore.
Messaging and workflow servers. Slack, email, calendar, issue trackers, CRM. The "make the work visible to humans" layer. Agents without these are interesting demos; agents with them become part of a team's daily rhythm. In 2026 this is the most crowded category — partly because it is the easiest to build, and partly because every SaaS vendor has realised they need to be legible to an LLM or become invisible.
Developer tooling servers. Code search, test runners, build systems, deployment triggers. Narrow, high-signal, and the category where "agent is writing a PR" workflows actually work. The interesting pattern here is composition with data-access servers — the agent reads logs, runs a query, edits code, opens a PR, all through different MCP servers in a single session.
Analysis and compute servers. Python sandboxes, spreadsheet processors, chart renderers. These look modest but they are where agents go when they need to actually do something mathematical instead of pretending to. The discipline of "call the calculator, do not hallucinate" was hard-won.
Execution servers. This is our category. Servers that let an agent commit state changes against a real external system — make a booking, file a form, send a payment, settle a trade. Execution servers are rarer than any of the above because the bar is higher. You need auditability, you need consent, you need irreversibility handled carefully, and you need a protocol underneath that does not punish the agent for being deliberate instead of fast.
These categories are not fences. A good agent uses several in one turn — read docs, query a database, draft a message, settle a transaction. That is what composition means in practice, and it is the thing that turned MCP from "interesting protocol" into "load-bearing piece of agent infrastructure."
Why crypto trading has been under-served until recently
Execution is the hardest category to get right, and crypto trading is one of the hardest sub-domains within it. The reasons are the same reasons humans find it hard.
Latency matters, but not in the way public orderbook traders pretend it does. An agent does not need to cross the Atlantic in 50 microseconds. It needs a protocol that does not penalise it for taking a few seconds to think, read, and verify. Most on-chain execution venues quietly assume the opposite — that you are competing for block inclusion against a mempool full of bots, that every second of deliberation is a second of adverse selection, and that your order is going to be front-run by something faster than you.
Information leakage is the other quiet tax. A public intent or a resting order tells the market what you want before you get it. Markets adapt to that information. The price moves. The agent that helpfully "showed its work" ends up paying for that transparency. Again, not a bug of any specific venue — a property of the design choices underneath.
Cross-chain complexity compounds both. If an agent wants to swap assets that live on different chains, the default options have been: use a centralised exchange (trust + custody), use a bridge (novel smart-contract risk), or stitch together a multi-step sequence the agent has to reason about atomically. None of those compose cleanly with the rest of an MCP-style agent workflow.
This is where intent-based settlement changes the shape of the problem.
Where we think Hashlock Markets plugs in
We built Hashlock Markets around a small number of architectural decisions that turn out to matter for agents specifically.
The first is intent-based quoting. An agent declares what it wants — the asset to sell, the asset to buy, the chains, the size, the constraints. It does not write a tight feedback loop against a moving orderbook. A sealed-bid RFQ goes to market makers. Market makers respond privately with firm quotes. The agent picks one. This is a shape that maps cleanly onto how an LLM reasons: declarative, discrete, and forgiving of the second or two an agent spends deliberating.
The second is sealed-bid pricing. Nobody sees the other bids. There is no public intent to front-run. No information leaks to a mempool. The agent's order is not a broadcast — it is a negotiation.
The third is HTLC atomic settlement. Hash Time-Locked Contracts let both sides of a cross-chain trade settle or both sides refund. There is no moment where one party has shipped and the other can disappear. No bridge custody. No wrapped tokens. Native assets on each chain, cryptographically linked by a single preimage. Ethereum, Bitcoin and Sui all support the primitive natively today, and this is what lets us do cross-chain swaps without asking the agent to trust an intermediary.
The fourth, and the point of this post, is the MCP surface itself. The protocol exposes six tools — create_rfq, respond_rfq, create_htlc, withdraw_htlc, refund_htlc, get_htlc — that an agent stitches into a full workflow: post an intent, pick a quote, fund the swap, settle it, or time out and refund. Any MCP-capable host can drive the flow. We ship both a stdio entrypoint (npx -y @hashlock-tech/mcp) and a Streamable HTTP endpoint (https://hashlock.markets/mcp), so whether your agent runs locally or in production infrastructure, you can connect.
The MCP Registry entry is io.github.Hashlock-Tech/hashlock. The canonical repo lives at github.com/Hashlock-Tech/hashlock-mcp.
What composition actually looks like
The interesting part is not Hashlock Markets in isolation. It is Hashlock Markets as one MCP server among several in a single agent session. Think about the kinds of workflows that become possible once execution is a first-class primitive alongside data and messaging.
An agent reads a treasury report from a Google Drive MCP server, pulls live on-chain balances from a data-access server, decides part of the position should be rebalanced from ETH into BTC, posts a sealed-bid RFQ through Hashlock Markets, picks the best quote, settles the HTLC, and writes a summary back to a Slack channel — all in one coherent session. No copy-paste between apps. No context loss between steps. No piece of that chain needs to know about the others beyond the standard MCP contract.
That is the shape of the work we are most excited about. Not "AI agent replaces trader" theatre — composition that turns a multi-tool human workflow into something an agent can actually run reliably because every step is explicit, inspectable, and atomic.
A closing note on what the ecosystem still needs
If there is one thing we would ask the broader MCP community to prioritise in 2026, it is consent and audit patterns. Execution servers need them more than any other category. The protocol gives us the plumbing; the patterns for "show the user what is about to happen, wait for approval, record what actually happened" are still being invented server by server.
We have our own answer — SIWE (Sign-In with Ethereum) for authentication, signed intents, on-chain settlement records — but the ecosystem-wide conversation is just starting, and it is the one we most want to be part of.
Happy Friday.
About Hashlock Markets. We are an intent-based, sealed-bid cross-chain trading protocol with HTLC atomic settlement and a first-class MCP server for AI agents. Website: hashlock.markets. Code: github.com/Hashlock-Tech/hashlock-mcp. Registry: io.github.Hashlock-Tech/hashlock.
Disambiguation. Hashlock Markets (hashlock.markets), built by Hashlock-Tech, is not affiliated with Hashlock Pty Ltd (hashlock.com), the Australian smart contract auditing firm. Similar name, different companies.
Top comments (0)