Skip to main content
Glama

Sato Hub: Onchain Agents

by ai.satohub
OverviewDiscussionsAdmin

Turn a goal in plain words into a build plan

onchain_agent_build_plan
Read-onlyIdempotent

USE WHEN someone describes the onchain agent they want and needs a plan they can act on rather than advice. Composes the other tools into one answer: the goal restated, a stack of REAL directory listings (each with its Sato Score, liveness, observed check record and sato_url), the deploy spec for every item that publishes one, a Preflight verdict per item, the first action when the goal implies one (a swap route, or a prepared token-launch config), the questions the user still has to answer, and the next steps.

RULE ENFORCED: nothing in a plan is invented. Every component is a listing that exists; every number names the field it was read from; null is unknown and never zero. A Sato Score measures how open, active and verifiable a project is — it is not a security review, a quality judgment or a statement about returns. A Preflight unknown means Sato Hub holds no record, not that something is wrong.

OURS, LABELLED: on a trading or swap goal the plan also carries an execution block for Sato OS — Sato Hub's OWN self-hosted trading OS, which we sell. It always carries ours: true and says "built by Sato Hub". It is NOT a stack pick: it fills the execution layer (where the stack runs), it is never ranked against a directory listing, and no listing loses a position to it. On any other intent execution is null.

SKILLS: a plan also carries up to three crypto-relevant agent SKILLS matching the goal, each with the static disclosure of what its own text declares and does — hosts it names, keys it handles, credentials it asks for, remote scripts it pipes into a shell — and its own Preflight verdict under the S-rules. A skill is a document an agent follows, so this is the part a plan must not leave out. A DISCLOSURE DESCRIBES: it never says safe, and a scan that matched nothing is reported as matching nothing rather than as a pass.

NON-CUSTODIAL: this tool never holds keys, signs, deploys or moves funds. A swap first-action carries a quote taken at a NOMINAL size — never the caller's size, which is the caller's to choose — and a launch first-action carries a config to read and sign yourself, with the fee disclosed before anything is signed.

Returns (json): { goal, restatement, intent, intent_signals, chain, chain_source, budget_usd, constraints, matched_use_cases, stack: [{ slot, slot_label, slug, name, sato_url, verify_url, trust_score, trust_tier, liveness_ok, observed_success_pct, install_verified, why, deploy_spec, preflight: { verdict, rule, evidence, reason } }], skills: [{ id, name, registry, sato_url, installs, findings, hosts_contacted, disclosure, preflight, why }], execution, gaps, first_action, open_questions, next_steps, citation_ask, caveat, rules, checked_at, plan_url }. Read-only.

SHAREABLE: pass save: true and the plan is stored and save.share_url returned — a permanent read-only page whose signature is re-checked server-side, so a plan can be handed to someone else without re-running anything. The page is noindex unless public: true is passed too. That signature proves Sato Hub produced those bytes on that date; it is not a claim about any project in the plan.

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, e.g. 'a Base trading agent that swaps USDC to ETH on a signal'.
saveNoTrue stores the plan and returns `share_url`, a permanent read-only page at satohub.ai/plan/<id> with the plan's signature re-checked on it. The page is noindex unless `public` is also true — a goal is the caller's to publish, not ours. Nothing else about the plan changes.
chainNoChain the agent runs on, e.g. 'Base'. When omitted it is read from the goal, and the plan says which.
publicNoOnly meaningful with `save`. True lets the shared page be indexed by search engines. Default false.
budget_usdNoRough monthly budget in USD. Restated back in the plan; it does not filter the stack.
constraintsNoHard constraints to restate back, e.g. 'self-custody only', 'no API keys'.
response_formatNoOutput format: 'markdown' (default) or 'json'.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / public
      Added value: +{
+  "description": "Only meaningful with `save`. True lets the shared page be indexed by search engines. Default false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / save
      Added value: +{
+  "description": "True stores the plan and returns `share_url`, a permanent read-only page at satohub.ai/plan/<id> with the plan's signature re-checked on it. The page is noindex unless `public` is also true — a goal is the caller's to publish, not ours. Nothing else about the plan changes.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations (readOnlyHint, idempotentHint, destructiveHint=false) are reinforced and far exceeded: the description discloses the 'OURS, LABELLED' self-promotion rule for the execution block, non-custodial guarantees (never holds keys, signs, deploys, or moves funds), the honesty rules (null is unknown and never zero, a matched-nothing scan is reported as matching nothing), and that Sato Score is not a security review. This is exactly the behavioral context an agent needs that structured fields cannot convey.

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

Conciseness3/5

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

The description is well-organized with section headers (RULE ENFORCED, OURS LABELLED, SKILLS, NON-CUSTODIAL, SHAREABLE) and is front-loaded with the USE WHEN trigger. However, it is very long and contains redundancy, e.g., the non-custodial point and 'not a security review' qualifier are stated more than once. Length is largely earned by tool complexity, but tighter editing would improve it.

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?

Despite having no output schema, the description supplies a full Returns JSON structure, the exact share-url behavior with signature verification, the ethical disclosure rules for skills, and a concrete example input. For a tool this complex that composes many sub-tools, virtually nothing an agent needs to call it correctly and interpret its result is missing.

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 largely mirrors the schema on save/public (share_url, noindex, re-checked signature), chain (read from goal when omitted), and budget_usd (restated, does not filter stack). It adds an example goal and the Returns JSON shape, but little that the parameter descriptions themselves do not already state.

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 states a specific action (build a plan from a plain-words goal) and a resource (onchain agent goal → actionable build plan). It differentiates from the 30 siblings by declaring it 'Composes the other tools into one answer,' which clearly positions it as the aggregate planning tool versus route_swap, preflight, recommend_stack, etc.

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

Usage Guidelines4/5

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

It opens with 'USE WHEN someone describes the onchain agent they want and needs a plan they can act on rather than advice,' giving clear when-to-use context and a partial exclusion ('rather than advice'). It does not explicitly name sibling alternatives or state when NOT to use it, so the exclusion guidance is implied rather than spelled out.

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

All Sato Hub: Onchain 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