Blockworks has put a hosted Model Context Protocol server in front of the datasets behind its research and its Intel app. Per The Defiant, ChatGPT, Claude and Cursor get read access, it ships with every API plan at no extra cost, and it runs on the same key and the same permissions. Blockworks' own launch post dates it to October 1, 2026.
The take: a data vendor shipping an MCP is no longer news. A data vendor shipping one *as a feature of the plan you already pay for*, with no new key and no new permission model, is the pattern worth noting. The MCP is becoming the default way a dataset says "agents welcome."
What Blockworks says is in it
The launch post lists a wide catalog. Claimed coverage includes:
- ▸Prices and exchange data, onchain metrics, REV and protocol financials
- ▸Stablecoins, tokenized stocks, tokenized commodities and ETFs
- ▸Treasury companies, funding rounds, investors and M&A
- ▸Token release schedules, mindshare and sentiment
- ▸Issuer disclosures, governance proposals and diligence reports
- ▸Research, news, conference transcripts and podcasts
Blockworks says the agent picks the right dataset from the catalog on its own, pulls what it needs, and returns answers with sources attached. It also says the data matches what the Blockworks API and Intel products return. That is the vendor's description. We have not tested the server, and neither the article nor the launch post describes an independent evaluation.
How you connect
Per the launch post, you paste a URL into an MCP-compatible client and sign in once with a Blockworks API key. ChatGPT connects as a plugin; Claude, Cursor and other MCP clients connect directly. Access rides on an existing Blockworks API subscription, and the post says new customers book a demo first.
That last detail matters for builders. This is not a public endpoint you point an agent at tonight. It is a gated data product with an MCP front door.
Why the shape matters
Three design choices stand out, all as described by Blockworks:
1. Same key, same permissions. The MCP does not mint a second access model. Whatever your API plan allows is what your agent can read. For anyone who has had to explain a second credential to a security reviewer, that is a real simplification. 2. Read access only. The Defiant describes it as read access to datasets. An agent can research and cite; the announcement describes no write path. For an agent that touches funds, a read-only data source is the easy half of the stack. 3. Sources travel with the answer. Blockworks says outputs carry their sources. If that holds up in practice, it makes an agent's claims checkable instead of merely confident.
The sass, kept short
"The only MCP that returns all of this in one place" is a sentence only a launch post can write. One catalog is not a standard. A breadth claim is a claim, and the interesting test is whether the sourcing holds when two datasets disagree.
What a builder does with this
An onchain agent has roughly three jobs: know things, decide, act. Data MCPs cover the first job. The decide and act layers still need their own parts: a wallet with spend controls, a payment rail, a runtime, and some way to check each of those before you wire them in.
That is the stack question the Sato builder starts from. You describe the agent, Sato maps the skills, MCPs, wallets and payment rails that build it, and the library tracks what is open, active and checkable. A research MCP like this one is a candidate for the "know things" slot. Whether it fits depends on your agent's job, your budget and your tolerance for a gated signup. A listing is not an endorsement, and the Sato Score is a transparency and liveness signal, not a quality grade.
What to watch
- ▸Independent tests. Does the catalog routing pick the right dataset, and do the attached sources hold up?
- ▸Access terms. The Defiant says every API plan includes it. Watch whether the demo-first onboarding loosens.
- ▸Copycats. If research and analytics vendors follow, "MCP included" becomes table stakes and the differentiation moves to data quality and sourcing.
- ▸Agent-to-agent use. Today the reader is a human's assistant. The next step is an autonomous agent holding the API key. That raises the key-handling questions every agent builder already has to answer.
Build the agent first. Then check the stack under it: satohub.ai/build.