Format
The sato.deploy manifest
A deploy spec is the shortest honest answer to “how do I actually run this?” — the runtime, the install command, the entry command, and what you have to supply yourself. Sato Hub publishes one for every listing it can read one from, and serves them over the API and the MCP so an agent can install a tool without scraping a README first.
- 307
- listings with a manifest (82% of 374)
- 72
- with an install reproduced in a container
- 197
- MCP servers with an invocation you can one-click
Counted from the live directory when this page was built.
The schema
Draft 2020-12, served at /schemas/deploy-spec.json. Put it at the top of your own manifest and your editor will check it as you type:
{
"$schema": "https://satohub.ai/schemas/deploy-spec.json",
"runtime": "Node.js",
"install": ["npm install @example/agent-kit"],
"entry": "npx @example/agent-kit --help",
"requires": ["OPENAI_API_KEY", "RPC_URL"],
"mcp_native": true,
"mcp_invocation": "npx -y @example/agent-kit-mcp",
"deploy_status": "self_reported",
"source_url": "https://github.com/example/agent-kit#readme",
"as_of": "2026-09-10"
}Nothing is required. A manifest with a runtime and an install line is more useful than no manifest, and a field you leave out reads as unknown rather than as false.
The fields
| Field | Type | What it carries |
|---|---|---|
| runtime | string | Language or runtime needed — "Node.js", "Python 3.10+", "Bun". |
| install | string[] | The install command(s), exactly as they should be run. |
| entry | string | The shortest command or snippet that starts it or proves it loaded. |
| requires | string[] | What the operator must supply: env vars, API keys, a wallet, an RPC endpoint. |
| chains | string[] | Chains or networks it operates on. May be finer-grained than the listing's chains. |
| license | string | SPDX id where known — MIT, Apache-2.0. |
| mcp_native | boolean | True if the resource is itself an MCP server. |
| mcp_invocation | string | How to invoke it: a stdio command, or a remote URL. This is what the install buttons read. |
| deploy_clarity | "high" | "medium" | "low" | How clearly the upstream docs spell deployment out. A judgement about the docs, not the code. |
| deploy_status | "verified" | "self_reported" | See below. Absent means unknown, and unknown is a value. |
| source_url | string | The README or docs page the spec was read from. We link to source; we never mirror it. |
| as_of | string | YYYY-MM-DD the manifest was last confirmed. |
| verification | object | What the container harness ran, when, and whether both checks passed. |
| install_variants | object[] | Alternative lanes — Node and Python, say. Verification is per lane. |
What deploy_status means
self_reported
Read off the project’s own README or docs and never run. It is a transcription, and a transcription can be stale, wrong, or describe a version that no longer exists. Most manifests are here.
verified
Sato Hub ran the install command and the entry command in an ephemeral container and both passed. The evidence sits in verification: the image, the timestamp, and each check with its result.
It says the documented install resolves and the entry point loads, on that date, in that image. It says nothing about whether the software is safe, correct, audited, maintained, or suitable for what you want to do with it. Those are different questions and we do not answer them with this field.
An absent deploy_status is unknown, not a failure. The Sato Score treats a reproduced install as evidence; it never treats a missing one as a mark against a project.
The install_variants invariant
Some projects ship two ways — a Node package and a Python package, say. Those lanes go in install_variants, and one rule holds them together:
When variants are present, the flat install and entry mirror the primary lane (install_variants[0]), and the top-level deploy_status and verification describe that primary lane.
So a consumer that has never heard of variants still reads a correct, complete spec. And because verification is per lane, a lane the harness never ran stays self_reported even when the primary lane is verified — a verified mark never blesses a lane we did not run.
How a project ships one
- 1. Make the README parseable. Most manifests here are seeded automatically from a fenced shell block that contains an install line and a runnable entry line. If your quickstart is prose, or a curl | sh pipe — which we refuse to stage — nothing gets seeded.
- 2. Or publish the manifest yourself, validated against the schema above, and point us at it. A manifest you wrote beats a manifest we inferred.
- 3. Claim your listing to correct the descriptive fields directly. A claim proves you control the project’s domain. It grants no verification status and moves no score — that boundary is deliberate.
- 4. The weekly verifier reproduces what it can in a container and stamps the result. Nothing a project tells us about itself can set verified.
Reading them
- onchain_agent_get_deploy_spec over the MCP server — one call, one manifest.
- /api/export/index.json — every listing carries its deploy_spec. CC-BY-4.0, and the CSV carries the first install line as an install column.
- /api/openapi.json — the same shape, in the machine contract.