Skip to main content
Glama

Turn a build plan into a starter repo

onchain_agent_scaffold_plan
Read-onlyIdempotent

USE WHEN a plan has been agreed and the next step is a repository rather than more advice. Builds the plan (same brain as onchain_agent_build_plan) and writes it into a small starter repo, returned as a base64 zip plus a manifest naming every file.

WHAT IS IN THE ARCHIVE: README.md (the plan rendered, every source URL, and the disclosure that Sato OS is ours) · sato.plan.json (the plan, signed at its own checked_at when a signing key is configured) · .env.example (every environment variable the stack's own deploy specs ask for, values BLANK, each under a comment naming which listing wants it) · install.sh (the documented install lines in order, each under its Preflight verdict) · agent.config.json (chain, tokens and the venue Sato Route chose, with chosen_by) · .mcp.json (Sato Hub's MCP server plus any MCP-native stack item) · docker-compose.yml ONLY when every stack item documents a docker install.

RULE ENFORCED: nothing is generated. Every line is a template constant or a field of the plan, copied verbatim. An install line we were not told is never invented, and a value we do not hold is left blank with a comment rather than filled with a plausible default.

THE ONE SAFETY RULE: a documented install that pipes a remote script into a shell (curl … | sh) is written as a COMMENTED line with a warning above it, never as an executable one, and it is reported in quarantined_installs. Uncommenting it is the reader's decision to take deliberately.

DETERMINISTIC: the same plan produces a byte-identical archive — the timestamps come from the plan's checked_at, not the clock.

NON-CUSTODIAL: the archive holds no keys and no secrets, and nothing here signs, deploys or moves anything.

Returns (json): { name, files: [{ path, note, bytes }], env_names, quarantined_installs, zip_base64, bytes, plan: { goal, intent, chain, plan_url, checked_at, stack_slugs }, caveat }.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesWhat the user wants to build, in plain words. The plan is built first, then written into files.
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'.
include_zipNoTrue (default) returns the archive base64-encoded alongside the manifest. False returns each file's contents inline instead.
response_formatNoOutput format: 'markdown' (default) or 'json'.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool read-only, idempotent, and non-destructive, but the description adds substantial behavioral detail: deterministic byte-identical output, timestamps from `checked_at`, no secrets or keys, no signing/deploying/moving, and a quarantine rule for pipe-to-shell installs. This goes far beyond what annotations convey and gives the agent accurate expectations.

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

Conciseness5/5

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

The description is long but highly structured with labeled sections, bullets, and bold terms. Every section conveys necessary information for correct invocation: when to use, what is in the archive, enforced rules, safety behavior, determinism, non-custodial guarantees, and the return shape. The 'USE WHEN' is front-loaded and the detail is justified by the tool's complexity.

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?

There is no output schema, so the description correctly carries the full burden of explaining the return value, and it does so explicitly with a JSON shape, an example, and a list of archive contents. Safety, determinism, and non-custodial behavior are all covered, leaving no material gap for an agent deciding whether and how to call this tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description includes a concrete example for `goal` and `chain`, and explains archive contents at a high level, but it does not add meaningfully to the schema's per-parameter descriptions. It neither compensates nor harms.

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 uses a specific verb-plus-resource structure: it 'builds the plan ... and writes it into a small starter repo', and explicitly ties itself to the same brain as `onchain_agent_build_plan`. This clearly distinguishes the tool from its sibling while stating exactly what it produces.

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 opens with an explicit 'USE WHEN' condition: a plan has been agreed and the next step is a repository rather than more advice. It also names the sibling `onchain_agent_build_plan` as the same-brain alternative, giving the agent a clear decision rule for choosing between them.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.