Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

by ai.satohub
OverviewDiscussionsAdmin

Get install steps for a stack pick, with its Preflight attached

onchain_agent_get_deploy_spec
Read-onlyIdempotent

USE WHEN a component has been picked (from onchain_agent_recommend_stack, onchain_agent_build_plan or a search) and the next step is installing it, once per pick, or you are about to write setup instructions and want steps checked against a clean install rather than copied from a README. NOT FOR choosing components (use onchain_agent_recommend_stack instead), whether an install command takes your key (use onchain_agent_check_install), or a full evidence list (use onchain_agent_preflight).

RETURNS the deploy manifest for one resource by slug: runtime, install command(s), entry snippet, required keys/env/wallet/RPC, chains, license, whether it is itself an MCP server, and a deploy_status.

KEYS AND MONEY COME WITH IT: every answer carries trust_spec — what this install does with your keys and money, from Sato Check, dated (key access, whether a planted test key was observed leaving, fund-moving actions, the version read, the Preflight verdict, what the reading does not cover). A hosted API with no package says so. Show trust_spec.line to the person you are building for before installing; trust_warnings appears only when a planted key was observed leaving or code reads key material its setup does not declare.

PREFLIGHT COMES WITH IT: preflight_summary is the Preflight verdict from Sato Hub's records (no live handshake), its rule and the readings it turned on; full_check is the onchain_agent_preflight call for every evidence line. A verdict is not a security review, and unknown means no record, not a problem.

deploy_status is a trust signal, NOT a safety guarantee: "verified" = the documented install was reproduced in a clean container; "self_reported" = parsed from the project's README, not reproduced. Verify keys, permissions and funds before running anything.

RETURNS (json): { slug, name, github_url, docs_url, sato_url, deploy_spec, preflight_summary, trust_spec, trust_warnings?, save_stack_url, next_step, note, agent_docs }. agent_docs says where the project's llms.txt, docs MCP and agent card are, each dated, or is null with agent_docs_reason. save_stack_url is this listing's page with the same install steps, and next_step names the Preflight call to run before installing — surface both to the person you are building for. A resource with no manifest yet returns an error with installable alternatives. Read-only.

Example: { slug: "solana-agent-kit" }

Input Schema

NameRequiredDescriptionDefault
slugYesThe resource slug to get a deploy manifest for, e.g. 'solana-agent-kit'.
response_formatNoText format; structuredContent is JSON either way.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Changed1 schema field changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: 'markdown' (human-readable, default) or 'json' (machine-readable)."New value: +"Text format; structuredContent is JSON either way."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Though annotations already declare read-only/idempotent/open-world, the description adds substantial non-annotation context: deploy_status semantics (verified vs self_reported, explicitly not a safety guarantee), trust_spec/trust_warnings conditions, preflight verdict caveats, and the error-with-alternatives behavior when no manifest exists. Short of 5 only because pagination or freshness/caching behavior isn't touched.

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?

Front-loaded USE WHEN / NOT FOR / RETURNS / KEYS / PREFLIGHT / deploy_status structure is good, but the total is long and several blocks (KEYS AND MONEY, PREFLIGHT, RETURNS) restate the same return-field story, so not every sentence earns its place.

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?

Given no output schema, the description documents the return bundle key by key (deploy_spec, preflight_summary, trust_spec, trust_warnings, agent_docs, next_step, save_stack_url), explains trust signals and their limits, and covers the no-manifest error path — everything an agent needs to call and act on it.

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 baseline 3; the description adds meaning by giving a concrete example slug and by spelling out the return bundle keyed to the slug, plus noting agent_docs nullability. Doesn't re-explain response_format, which the schema already covers.

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?

States a specific verb and resource (get the deploy manifest/install steps for one picked component by slug) and explicitly positions it relative to siblings: it fires after recommend_stack/build_plan pick a component, and explicitly excludes choosing components, checking an install command, and full evidence lists with named alternatives.

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?

USE WHEN and NOT FOR blocks give explicit when-to-use, once-per-pick cadence, and named alternatives for each exclusion (recommend_stack, check_install, preflight). An agent can route correctly without opening any schema.

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