An MCP server, and what makes one worth connecting
The hard part of an MCP server is not the protocol, which is well specified and quick to implement, but the design of the tools themselves: what they are named, what they return, and above all what they say when they fail, because a model that receives an unhelpful error will retry and then invent.
An MCP server exposes tools to a model over a standard protocol, so any client that speaks it can use what you expose without a bespoke integration for each one.
The protocol is the easy half
Describe your tools, accept calls, return results. The specification is clear and a working server is an afternoon. Almost nothing that makes an integration good or bad lives at this layer, which is why comparing servers on protocol compliance tells you very little.
A tool is a piece of writing before it is a piece of code
The model chooses a tool from its name and description alone. A vague name gets called for the wrong thing; an overlapping pair gets called at random. Naming and describing tools is the highest-leverage work in an MCP server and it is closer to writing documentation than to writing an API.
Failure messages are where servers separate
A tool returning a bare error gives the model nothing to reason with, so it retries, retries again, and eventually produces a plausible answer from nothing. A tool that says which argument was wrong, whether retrying could help, and how stale its data is lets the model recover. Most failures that look like the model being stupid are a tool that failed uninformatively.
Read and write should not be the same grant
Reading a price is cheap to allow and hard to misuse. Placing an order is neither. Bundling them into one connection means every client that wants a quote also holds the ability to spend, and the model cannot tell the difference. Ours splits them: twenty three public read endpoints need no key at all, and anything that moves money needs a key and a human decision.
How to tell whether yours is any good
Give it to a model with no other context and watch which tool it reaches for first. If it picks wrong, the description is wrong. If it calls the same tool three times with slightly different arguments, your error messages are not telling it what went wrong. Both are writing problems and both are fixable in an afternoon.
Live, right now, on this page
| Market | Price | Funding | 24h volume |
|---|---|---|---|
| BTC | $77,117.50 | 0.0013% | $497,325,267 |
| ETH | $2,379.75 | 0.0013% | $292,234,084 |
| SOL | $98.51 | 0.0013% | $78,988,184 |
| HYPE | $81.34 | 0.0013% | $12,537,647 |
Read from a live market as this page rendered, through a public endpoint that needs no key. Read at 2026-09-02 17:12 UTC; accurate as of that time and not afterwards.
Describe something and watch it get built.
Open the builder, or start from a working app and change it.