Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

by ai.satohub
OverviewDiscussionsAdmin

Find live registered agents

onchain_agent_search_agents
Read-onlyIdempotent

USE WHEN you need a RUNNING agent to work with, hire or pay (not a tool to build one with) and want to see who registered it, on which chain, and whether it accepts payment. NOT FOR tools to build an agent from (use onchain_agent_search_resources instead), one agent's full manifest (use onchain_agent_get_agent_passport with a slug from here), or a ranked pick for a task (use onchain_agent_route_agent).

RETURNS (json): { total, agents: [{ sato_agent_id, slug, name, description, agent_type, chains_supported, stack, payment/x402 metadata, verification_status, profile_url, manifest_url }] }. Searches the Sato Agent Registry: agents whose creators registered them for a Sato Agent Passport (distinct from the resource directory, which lists the things agents are built FROM). Filter by free-text query, chain, agent_type, or x402_only. Only human-review-listed agents are returned. Registry agents come first; when the registry has no match for a query, matching agent-type directory listings come back in listings[] with kind "listing" (not passports), and total counts both. A query that names a brand ("aixbt", "olas") also returns brands[]: the identities someone declared for it (ERC-8004 ids, wallets, builder codes), each saying who declared it (the brand, the platform that lists it, or the registrant); brands are not registry results and are not counted in total. Read-only.

This is the Sato Agent Registry only: agents whose builders registered them with Sato Hub, a small set. It does not search agents registered onchain under ERC-8004, so an empty answer here says nothing about them. For those, call onchain_agent_get_agent_economy with venue "erc8004" (measured counts by chain), or see https://satohub.ai/agent-economy/erc8004 and https://satohub.ai/erc8004/.

Trust rule: registration is self-reported by the creator; verification_status distinguishes Self-Reported from evidence-reviewed Verified/Audited. Nothing here implies safety or performance.

Example: { chain: "Base", x402_only: true }

Input Schema

NameRequiredDescriptionDefault
chainNoFilter to agents supporting this chain.
queryNoFree-text search across agent name, description, creator, stack, and type.
x402_onlyNoTrue = only agents exposing an x402 payment endpoint.
agent_typeNoFilter by agent utility type: trading, research, defi, payments, security, social, workflow, gaming, data, coding.
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 / chain / enum
      Previous value: -[
-  "Ethereum",
-  "Base",
-  "Solana",
-  "Arbitrum",
-  "Optimism",
-  "Polygon",
-  "Avalanche",
-  "BNB Chain",
-  "Cosmos",
-  "Bitcoin",
-  "Sui",
-  "Aptos",
-  "Near",
-  "COTI",
-  "Injective",
-  "XRP Ledger",
-  "Gnosis",
-  "Hyperliquid",
-  "Sei",
-  "Starknet",
-  "zkSync",
-  "Monad",
-  "MegaETH",
-  "Berachain",
-  "TON",
-  "Tron",
-  "Robinhood Chain",
-  "Multichain",
-  "Unknown"
-]New value: +[
+  "Ethereum",
+  "Base",
+  "Solana",
+  "Arbitrum",
+  "Optimism",
+  "Polygon",
+  "Avalanche",
+  "BNB Chain",
+  "Cosmos",
+  "Bitcoin",
+  "Sui",
+  "Aptos",
+  "Near",
+  "COTI",
+  "Injective",
+  "XRP Ledger",
+  "Gnosis",
+  "Hyperliquid",
+  "Sei",
+  "Starknet",
+  "zkSync",
+  "Monad",
+  "MegaETH",
+  "Berachain",
+  "TON",
+  "Tron",
+  "Robinhood Chain",
+  "Tempo",
+  "Multichain",
+  "Unknown"
+]
  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' (human-readable, default) or 'json' (machine-readable)."New value: +"Text format; structuredContent is JSON either way."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, yet the description adds substantial non-structured behavior: registry-first ordering with listings[] fallback, brands[] returned for brand-name queries but excluded from total, and the trust caveat that registration is self-reported with verification_status distinguishing Self-Reported from Verified/Audited. It also warns that an empty result says nothing about ERC-8004 agents — a critical failure-mode disclosure.

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?

Front-loaded with USE WHEN / NOT FOR / RETURNS blocks, which is an efficient structure for a complex tool. It runs long and includes some lines that restate structured data ('Read-only.' repeats readOnlyHint), but the density of genuinely new information justifies most of the length.

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?

No output schema exists, yet the description enumerates the return shape (total, agents[] fields) and the secondary envelopes (listings[], brands[]). Combined with the scope and trust-rule disclosures, an agent has everything needed to call this correctly and interpret an empty result.

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 is 3, but the description adds real meaning beyond it: 'query' is described as also triggering brands[] when it names a brand, and x402_only is exemplified in a concrete call ({ chain: "Base", x402_only: true }). It stops short of explaining response_format's structuredContent behavior, 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 ('search live registered agents you can hire or pay') and immediately disambiguates from what it is not — a build tool, a passport lookup, or a router. The agent can tell this apart from search_resources and get_agent_passport 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?

Explicit when-to-use ('need a RUNNING agent to work with, hire or pay'), explicit when-not with three named sibling alternatives and their conditions, plus a boundary note directing ERC-8004 lookups to onchain_agent_get_agent_economy. This is a complete routing map.

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