From a directory to a build layer
SatoHub started as a directory of onchain agents, frameworks, skills, and tooling — a map of what exists. A map is useful, but it stops at the door. It tells you a project exists; it doesn't tell you how to stand it up, what it needs, or whether the install path still works.
So we built the next layer: deploy specs. Every tool in the directory can now carry a structured manifest — the exact runtime, install command, entry point, required keys or wallets, supported chains, and license an agent needs to actually deploy it. And we serve those manifests to any agent over the Model Context Protocol.
What shipped
A new MCP tool, onchain_agent_get_deploy_spec, on the SatoHub server at /api/mcp. Ask it for a slug — say solana-agent-kit or x402 — and it returns a machine-readable manifest:
- ▸
runtimeandinstall— the language and the exact command(s) - ▸
entry— the minimal snippet or config to instantiate it - ▸
requires— the honest blockers: API keys, a wallet, an RPC endpoint - ▸
chains,license, and whether the tool is itself an MCP server - ▸
deploy_status—verifiedorself_reported
That last field is the point. An agent can read the spec, see what it needs, and build from it — without a person first reading a README and translating it by hand.
42 tools, 33 verified by actually running them
Coverage today spans the working parts of the stack: agent frameworks (Coinbase AgentKit, Solana Agent Kit, ElizaOS, GOAT, Fetch.ai uAgents, Olas), MCP servers (Bankless, BlockRun, BNB Chain, DefiLlama), agent skills (OKX OnchainOS, Bitget Wallet, OpenSea, ChainGPT), wallet and signing infrastructure (Privy, Turnkey, Trust Wallet, 0xGasless), payments (x402, AP2), and DeFi and data tools (Enso, Orderly, Zerion, Neynar, Alchemy).
Of those 42, 33 are verified — and verified means something specific here. We don't take the README's word for it. For each one, a harness reproduces the documented path inside an isolated container: it runs the install command, then loads the documented entry point. Both have to pass. The other 9 are marked self_reported — real, credible tools that are hosted, clone-only, or plugin-based, where there's no local artifact to reproduce. We say which is which.
To be exact about what verified is not: it is not a safety, security, or returns claim. It means the install resolved and the entry loaded. Keys, permissions, and funds are out of scope. The honest line matters more than a green badge.
The bar, and what it keeps out
Running an install path in a clean container is a good lie detector. It caught real problems while we built this:
- ▸Solana Agent Kit had moved from v1 to v2 — the documented
createSolanaToolsexport was gone, and the constructor now takes a wallet adapter. Our spec was stale against the live package; the harness failed it, and we fixed it. - ▸BNB Chain MCP shipped a package name in its own README that returns a 404 on npm. We corrected it in the spec.
- ▸0xGasless AgentKit publishes without declaring a dependency it needs to import. We made the install honest about it.
We also hold a quality bar: a tool earns a deploy spec only if it's a real runnable artifact, clearly licensed, maintained, and carries a strong signal — verified, a credible maintainer, or real adoption. We removed a handful that didn't clear it: a broken build, an unlicensed and long-stale repo, a paid proprietary endpoint we couldn't reproduce. The directory still lists them; the build layer stays high-signal.
It stays honest over time
Packages change. A spec that worked last month can break tomorrow. So a routine re-runs the full harness every week. If a tool that was verified stops reproducing, it's automatically demoted to self_reported and flagged for a fix — a green badge can't outlive the reality it's supposed to describe.
Use it
If you're building an agent, point your MCP client at https://satohub.ai/api/mcp and call onchain_agent_get_deploy_spec. If you're a person, the same data backs the directory at https://satohub.ai. Either way, you get the install path, the requirements, and an honest read on whether it's been reproduced.
This is the start of the build layer, not the end of it. The library grows as the ecosystem does, and every entry is one that a person — or an agent — can actually deploy.