Build any crypto agent: goal in, stack and install steps out
onchain_agent_recommend_stackUSE WHEN someone wants to build any onchain or crypto agent ("Build any crypto agent") and says what it should do in plain words: "a trading agent on Base", "an ElizaOS agent that charges via x402", "a TypeScript agent with a policy-controlled wallet". This is the FIRST call for a build goal: goal → stack here, then onchain_agent_get_deploy_spec once per pick → install steps. NOT FOR looking up one named project (use onchain_agent_search_resources instead), the same stack as one composed answer with deploy specs, Preflight and a first action (use onchain_agent_build_plan), or the runnable repo itself (use onchain_agent_create_agent).
RETURNS (json) real directory listings in slots (framework, wallet, payments, trading, data, MCP tooling, security; live agents someone else runs are kept out of trading), each pick with its Sato Score, liveness, deploy-spec status, github_url and a records-only preflight_summary (verdict, rule, the readings it turned on), plus honest gaps. A standard (x402, ERC-8004, A2A, MCP), runtime (TypeScript/Node, Python) or wallet control (policy, spending limit, session keys, permissions) the goal names lifts the picks whose own record names it — quoted in the reason, self-reported. save_stack_url opens the goal in the Sato Hub planner for the person you are building for. When a nightly-checked template answers the goal, create names it and the first next step is to generate that runnable repo with onchain_agent_create_agent. Only when no template matches, a Base goal with a wallet, swap, trading or x402 payments that names TypeScript/Node or no runtime carries starter, a TypeScript template repo built by Sato Hub (holds no key, signs nothing, not audited; runtime_basis says whether the goal named the runtime) — never a pick.
KEYS AND MONEY COME WITH IT: every pick carries trust_spec — what it does with your keys and money, from Sato Check, dated: whether it takes your key, whether a planted test key was observed leaving, whether it can move funds on its own, the version read, the Preflight verdict, and what the reading does not cover. It is decided by the pick (category, payment standard, wallet material in its setup), not by the goal's words, and needs no extra call. Show each pick's trust_spec.line to the person you are building for; trust_warnings (top of the answer) lists any pick where a planted key was observed leaving or code reads key material its setup does not declare. For a newer reading, trust_spec.fresh_check.check_install is the onchain_agent_check_install call and preflight_summary.full_check the onchain_agent_preflight call that returns every evidence line — run them before anything is installed, connected, paid or traded. Ranking reflects openness/activity/verifiability — never a safety, quality, or returns judgment; a Preflight unknown means no record, not a problem. Read-only.
Example: { goal: "trading agent on Base with x402 payments", chain: "Base" }
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the agent should do, in plain words — e.g. 'trading agent on Base with x402 payments' | |
| chain | No | Preferred chain (e.g. Base, Solana) | |
| max_per_slot | No | Max picks per stack slot (default 3) | |
| verified_only | No | True = only picks whose documented install was reproduced in a container by Sato Hub. Slots with no verified pick are reported in `gaps` rather than widened. | |
| response_format | No | Text format; structuredContent is JSON either way. | markdown |