Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

by ai.satohub
OverviewDiscussionsAdmin

Build a plan and point to the repo generator

onchain_agent_scaffold_plan
Read-onlyIdempotent

USE WHEN a plan has been agreed and the next question is which repository to start from. Builds the plan (same brain as onchain_agent_build_plan) and returns it with a create pointer to onchain_agent_create_agent, which generates the runnable repo from a nightly-checked template. NOT FOR the full plan with deploy specs and Preflight on every pick (use onchain_agent_build_plan instead) or the repo itself: this tool no longer writes repository files, so use onchain_agent_create_agent to generate it. Every door (this server, POST /api/create, the CLI and the Agent Architect) downloads the same repo from the same engine.

RETURNS (what comes back): the plan summary (goal, intent, chain, plan_url, checked_at, stack slugs), the environment names the stack's own deploy specs ask for, any documented install that pipes a remote script into a shell (quarantined_installs, to read before running it), and create: the tool name, the CLI command and the template the goal maps to, or null when no template answers it.

KEPT FOR COMPATIBILITY: files is an empty list and bytes is 0; include_zip is accepted and ignored. mode is "plan_only".

RULE ENFORCED: nothing is generated. Every value is a field of the plan. An install line we were not told is never invented.

NON-CUSTODIAL: nothing here holds keys, signs, deploys or moves anything.

RETURNS (json): { mode: "plan_only", name, files: [], env_names, quarantined_installs, bytes: 0, plan: { goal, intent, chain, plan_url, checked_at, stack_slugs }, caveat, create: { tool, command, template, note } }.

Example: { goal: "a Base trading agent that swaps USDC to ETH on a signal", chain: "Base" }

Input Schema

NameRequiredDescriptionDefault
goalYesWhat the user wants to build, in plain words. The plan is built and the matching create_agent template is named.
chainNoChain the agent runs on, e.g. 'Base'. When omitted it is read from the goal.
budget_usdNoRough monthly budget in USD. Restated in the plan; it does not filter the stack.
constraintsNoHard constraints to restate back, e.g. 'self-custody only'. One string is read as a one-item list.
include_zipNoAccepted for compatibility and ignored: this tool is plan-only. The repo comes from onchain_agent_create_agent.
response_formatNoText format; structuredContent is JSON either way.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / constraints / description
      Previous value: -"Hard constraints to restate back, e.g. 'self-custody only'."New value: +"Hard constraints to restate back, e.g. 'self-custody only'. One string is read as a one-item list."
  2. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: 'markdown' (default) or 'json'."New value: +"Text format; structuredContent is JSON either way."
  4. Changed2 schema fields changed
    • changedInput schema / properties / goal / description
      Previous value: -"What the user wants to build, in plain words. The plan is built first, then written into files."New value: +"What the user wants to build, in plain words. The plan is built and the matching create_agent template is named."
    • changedInput schema / properties / include_zip / description
      Previous value: -"True (default) returns the archive base64-encoded alongside the manifest. False returns each file's contents inline instead."New value: +"Accepted for compatibility and ignored: this tool is plan-only. The repo comes from onchain_agent_create_agent."
  5. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, the description discloses that nothing is generated, that the tool is non-custodial (no keys, signing, deploying), and that untrusted install lines are surfaced via quarantined_installs rather than invented. It also documents compatibility shims (files empty, bytes 0, include_zip ignored, mode plan_only) that annotations alone would not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the USE WHEN/NOT FOR routing that an agent needs first, and most sentences carry distinct information. However, the return payload is documented twice (a prose RETURNS section and a JSON RETURNS block) and the 'every door downloads the same repo' line is filler, so it falls short of 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and six parameters on a fairly complex tool, the description fully enumerates the return shape (plan fields, env_names, quarantined_installs, create pointer or null), the non-custodial guarantee, and the compatibility fields. An agent has everything needed to call it and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining that include_zip is accepted purely for backward compatibility and ignored, and that mode is fixed at plan_only. It doesn't add syntax guidance for goal/chain/budget beyond what the schema already says, keeping it to a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (builds the plan) and resource (a plan plus a create pointer to the repo generator), and explicitly positions it against onchain_agent_build_plan and onchain_agent_create_agent. An agent can tell it apart from the full-plan sibling and the repo-generation sibling without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a concrete USE WHEN condition ('a plan has been agreed and the next question is which repository to start from'), explicit NOT FOR cases with named alternatives for each, and clarifies that the repo itself must come from onchain_agent_create_agent. Nothing about routing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Sato Hub: Build Onchain & Crypto Agents toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources