Sato Hub: Build Onchain & Crypto Agents

Measure the onchain agent economy

onchain_agent_get_agent_economy

Read-onlyIdempotent

USE WHEN asked how big the onchain agent economy actually is (how many agents are really registered, launched, paying or trading) and you want measured chain reads instead of a figure from a deck or an announcement. Covers the agent venues Sato Hub tracks: registries, launchpads, payment rails and account infrastructure, measured weekly from public chain reads. NOT FOR a series over time (use onchain_agent_get_trend instead), one headline ERC-8004 count (use onchain_agent_get_metrics), or agents registered with Sato Hub (use onchain_agent_search_agents).

RETURNS (json): { week, as_of, rules, evidence_tiers, venues: [{ id, name, unit, entry_cost, measurable, overlaps_with, headline_safe, contracts:[...], chains:[{ chain, stages:[{ stage, value, unit, method, evidence_tier, sample_size, denominator, covered_days, publishable, caveat }] }], platforms:[...] }] }. With no venue, chain or include_platforms (and no detail: "full") it is a compact summary instead, labelled rule "defaulted": { summary: true, week, as_of, rules, venues: [{ id, name, venue_unit, headline_safe, overlaps_with?, stage, unit, caveat, as_of, readings: [{ chain, value, sample_size, publishable, evidence_tier, unit?, caveat? }], more_chains, paired_stage? (the second stage of a venue quotable only as a two-stage figure, same shape), other_stages, full_detail: { tool, args } }], full_detail }. The week is the payload's, one for every venue; each stage's unit and caveat are its own rows', not the venue's.

HOW TO USE THESE NUMBERS. Never add them together: an ERC-8004 registration, an Olas staked service, a Virtuals launch and a Mech task are four different objects, and each venue's unit says which. Every number names its stage — "19,180 launched, 1,233 graduated" is true, "58,400 agents" is not. A null value means UNKNOWN, never zero. A rate whose sample_size is below 20 is returned with publishable: false and should not be quoted. Solana identity registries are covered as UPPER BOUNDS (program-account counts, the unit says so); Solana payment settlement is not covered by any row, and by transaction count x402 mostly settles there.

Read-only. Cite https://satohub.ai/agent-economy.

Examples:

"how many agents are actually registered onchain" -> {} (summary) · every row -> { detail: "full" }
"what is happening on Base" -> { chain: "Base" }
"who is producing ERC-8004 registrations" -> { venue: "erc8004", include_platforms: true }

Input Schema

Name	Required	Description	Default
`chain`	No	Restrict to one chain, e.g. Base, BNB Chain, Gnosis. Venue-level rows have no chain.
`venue`	No	Restrict to one venue: erc8004, olas, virtuals, x402, erc4337_accounts, key_management, singularitynet, morpheus.
`detail`	No	'full' returns every venue, chain and stage row even with no filter. Omitted with no venue/chain/include_platforms, the answer is the compact per-venue summary, each line with the call for its full detail.
`response_format`	No	Text format; structuredContent is JSON either way.	markdown
`include_platforms`	No	Include the per-platform breakdown of who produced the registrations (agentURI attribution). Default false — it roughly doubles the response.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / detail

Added value: +{
+  "description": "'full' returns every venue, chain and stage row even with no filter. Omitted with no venue/chain/include_platforms, the answer is the compact per-venue summary, each line with the call for its full detail.",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedSep 30, 2026

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."

AddedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description adds substantial non-obvious behavior: numbers are never additive, null means unknown not zero, rates with sample_size < 20 are flagged publishable:false, Solana identity rows are upper bounds, and Solana payment settlement is uncovered. These are exactly the caveats an agent would otherwise get wrong.

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 before the payload detail, and each block is signposted. The RETURNS paragraph is a dense wall enumerating both response shapes, but with no output schema that burden is real rather than padding; a little tightening would help.

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?

For a high-complexity tool with five parameters, no output schema and no required arguments, the description covers the full shape of both return variants (summary vs full), the null/unit/publishable semantics, and worked examples for the three common call patterns. Nothing an agent needs to call it correctly is missing.

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 the cross-parameter defaulting rule that the schema only states piecemeal: omitting venue/chain/include_platforms (and detail) yields a compact summary labelled rule 'defaulted', and detail:'full' overrides that. It also documents include_platforms' response-size cost, which the schema does not quantify.

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 opening states a specific verb and resource ('measure the onchain agent economy' via measured chain reads) and immediately scopes it to registration/launch/payment/trading counts. It names the sibling tools it is not (get_trend, get_metrics, search_agents), so an agent can route 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 'USE WHEN' condition plus a 'NOT FOR' block that names three alternatives and the exact condition that selects each ('a series over time', 'one headline ERC-8004 count', 'agents registered with Sato Hub'). This is as close to a routing table as a description gets.

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 tools Inspect

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.

Measure the onchain agent economy

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources