The problem with asking an agent to go check SatoHub
Most of the internet is built for a person with eyes and a scroll wheel. An agent that wants to know what's a good x402 payment library, or whether a given framework is still active, either gets a brittle HTML scrape or a stale training-data guess. Neither is great when the answer changes weekly.
SatoHub's answer is to skip the scrape entirely. The library, resources, wiki, news, metrics, deploy specs, is exposed directly over MCP (Model Context Protocol), the emerging standard for how agents call structured tools instead of parsing web pages.
What it actually is
The SatoHub MCP server lives at POST /api/mcp, speaking Streamable HTTP. Point an MCP-compatible agent or client at it and it gets a set of read-only tools for querying the same data that powers the public site: the resource library (frameworks, skills, MCPs, wallets, payment rails, chains), the wiki, the news feed, and site metrics. Public docs live at satohub.ai/mcp.
That read-only framing is doing real work, not just a disclaimer. The server surfaces what SatoHub has mapped and scored, it doesn't execute transactions, sign anything, or move funds. Think of it as a queryable index of the builder's supply layer, not an actuator. If an agent needs to actually do something onchain, that's a different job with a different trust model; this is the lookup layer.
Why an agent, specifically
A human builder can already browse the directory, filter by chain or category, and read a project's Sato Score on the site. MCP exists for the case where the builder is itself an agent: one assembling a stack, evaluating a dependency, or figuring out what to use for a given job without a person in the loop clicking through pages.
That's the actual shift SatoHub is betting on: the library isn't just a reference for humans anymore, it's a service other software calls. A coding agent scaffolding an onchain project can ask the MCP server directly instead of guessing from stale training data or scraping a page whose markup changes next sprint.
What it's for, and what it isn't
This is a good moment to be precise, because an agent querying a database over a protocol is exactly the kind of thing that gets oversold. The MCP server is:
- ▸A read path, not a write path. It answers questions; it doesn't take actions on an agent's behalf.
- ▸Grounded in the same data as the public site. Nothing here is more, or less, verified than what's on satohub.ai. The Sato Score, liveness signals, and self-reported vs. reviewed status all carry over. Querying over MCP doesn't upgrade a self-reported claim into a verified one.
- ▸Discovery infrastructure, not a marketplace. It helps an agent find and understand what's out there in the builder stack. Hiring, licensing, or transacting with anything it surfaces is a separate, later layer, one that doesn't exist yet.
What to watch
MCP itself is still young as a standard, and the interesting question isn't whether SatoHub has a server, plenty of projects are shipping one, it's which servers agents actually keep calling once the novelty wears off. That comes down to boring things: does the data stay current, does the schema stay stable, does it answer the question an agent actually asked. SatoHub's bet is that a library that's tracked, scored, and kept current daily is more useful to an agent than one more scrape target. Whether that holds is worth checking back on.
Docs and the live endpoint: satohub.ai/mcp.