A name in a directory is not a build plan
Every library listing on Sato Hub tells you a tool exists: what it does, what chain it's on, who built it. None of that tells an agent — or a person — how to actually stand it up. What's the runtime? What's the exact install command? What does the entry point look like once it's running? What credentials does it expect before it does anything useful?
That's the gap deploy specs close. Every library listing can carry one: a structured manifest with the runtime, the install command(s), a minimal entry snippet, and the requirements — env vars, an API key, a wallet, an RPC endpoint — an agent needs before it can use the tool. It's served over MCP through the get_deploy_spec tool, so an agent building with the stack doesn't have to scrape a README and guess.
The field that matters most: `deploy_status`
A manifest is only as good as the claim behind it, and this is where Sato's whole trust posture shows up in one field. Every deploy spec carries a deploy_status, and it is not a single flavor of "yes":
- ▸`verified` — Sato Hub reproduced the documented install path in an isolated container: the install command ran, the entry point loaded. Both had to pass.
- ▸`self_reported` — parsed straight from the project's own docs, never independently attempted. Often accurate. Not the same claim.
- ▸`failed` — Sato Hub ran the exact documented install and it did not complete. That's a measurement of the documented path, usually a stale README, not a verdict on the project.
- ▸`unknown` — nothing conclusive attempted, because the documented install isn't reproducible in a bare container (a client registration, a host package manager, a credential placeholder). Absent is treated the same as unknown, on purpose — there's no default that quietly means "probably fine."
Say it plainly, because it's the whole point: `verified` means the install and entry point worked in a container on a given date. It is not a safety, security, or correctness guarantee. Keys, permissions, and funds are always out of scope. A tool can have a perfectly reproducible install and still be a bad idea to hand a wallet to — those are different questions, and the deploy spec only answers one of them.
Why a manifest beats a README, for an agent
A README is written for a person skimming top to bottom. An agent building a plan needs a specific shape it can act on without inference: which lane to run, what to pass in, what it still needs from the operator. The sato.deploy format is published as an actual JSON Schema — additionalProperties: false, every field described — so it isn't just an internal convention. Anything that wants to validate against it, or generate against it, can.
Some tools support more than one install lane — Node vs. Python, say. Those live under install_variants, each with its own deploy_status: a container run on the Node lane never blesses the Python lane it never touched. The top-level fields always mirror the primary lane, so a consumer that ignores variants still reads a correct spec.
What this fits into
The library is the supply layer of the builder — what an agent is built *with*. The Sato Score is the trust context on top of it: how open, active, and verifiable a listing is over time. The deploy spec is the part that turns "this exists and looks credible" into "here's the exact command." None of the three substitutes for the others. A high Sato Score doesn't mean the install works today; a verified deploy spec doesn't mean the project is safe to hand funds to. Read them as what they each actually measure, not as one combined stamp of approval.
What to watch
Installs rot. A package that resolved cleanly last month can break on a version bump, a renamed export, a dependency the maintainer forgot to declare — the kind of thing a static README never catches. A verified mark is a snapshot, not a lifetime warranty, which is exactly why it's worth re-checking rather than trusting on faith. If you're building an agent that needs to install something from the stack, ask for the deploy spec before you ask for the README.
Build any crypto agent, starting from a manifest instead of a guess: [satohub.ai](https://satohub.ai).