Skip to main content
Glama

Measure the onchain agent economy

onchain_agent_get_agent_economy
Read-onlyIdempotent

What is actually happening on-chain across the agent venues Sato Hub tracks — registries, launchpads, payment rails and account infrastructure — measured weekly from public chain reads.

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:[...] }] }.

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. Every method here is EVM-shaped; Solana is not covered, and by transaction count x402 mostly settles there.

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

Examples:

  • "how many agents are actually registered onchain" -> {}

  • "what is happening on Base" -> { chain: "Base" }

  • "who is producing ERC-8004 registrations" -> { venue: "erc8004", include_platforms: true }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoRestrict to one chain, e.g. Base, BNB Chain, Gnosis. Venue-level rows have no chain.
venueNoRestrict to one venue: erc8004, olas, virtuals, x402, erc4337_accounts, key_management, singularitynet, morpheus.
response_formatNoOutput format: 'markdown' (human-readable, default) or 'json' (machine-readable).markdown
include_platformsNoInclude the per-platform breakdown of who produced the registrations (agentURI attribution). Default false — it roughly doubles the response.

TDQS

A4.7/5.0
Behavior5/5

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

With annotations already marking the tool read-only/idempotent/non-destructive, the description still adds substantial behavior: weekly measurement from public chain reads, detailed JSON return shape, null-means-UNKNOWN, publishable-false for small samples, and EVM-only coverage. These caveats tell the agent how to interpret and trust the output beyond what the schema conveys.

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 front-loaded with the core purpose, then uses clear labels (Returns, HOW TO USE THESE NUMBERS, Examples) to organize dense caveats without burying the lead. Every section earns its place, and even the safety note 'Read-only' is a single token.

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 must stand in for it, and it does: full JSON structure with nested venues/chains/stages is provided, plus interpretation rules and example invocations. The combination of return shape, caveats, and examples leaves an agent with enough context to call and interpret the tool correctly.

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?

The schema covers all four parameters at 100%, so the baseline is 3, but the description's examples add practical semantics: no params for general counts, chain:'Base' to scope by chain, and venue:'erc8004' with include_platforms:true to get producer attribution. This is modest but genuine value beyond the schema's field descriptions.

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 opens with a concrete scope: measuring what is actually happening on-chain across Sato Hub's tracked agent venues (registries, launchpads, payment rails, account infrastructure), with a weekly cadence. This clearly identifies the resource and differentiates it from sibling tools about individual agents, changes, news, and wiki content even without naming them.

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?

The 'HOW TO USE THESE NUMBERS' section gives explicit interpretive rules and the examples map natural-language requests to parameter combinations. It also states exclusions (Solana is not covered) but does not explicitly point to sibling alternatives, so it stops just short of full when-to-use-versus-alternative guidance.

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.

TDQS

A4.1/5.0
Disambiguation4/5

Each tool targets a distinct resource type or action: agents, resources, wiki pages, news, metrics, changes, and stack recommendations. The only mild overlap is between get_changes and recent_changes, but their descriptions clearly separate directory sync from an auditable event feed.

Naming Consistency4/5

All tools share the onchain_agent_ prefix and mostly follow a clear verb_noun pattern: get_, list_, search_, recommend_. The one notable deviation is onchain_agent_recent_changes, which lacks the get_ prefix used by its sibling change-tracking tool.

Tool Count5/5

Fourteen tools is well within the ideal range for a directory-style server. Each tool serves a distinct purpose—search, detail retrieval, list facets, news, metrics, change sync, and recommendations—and none feels redundant or filler.

Completeness5/5

The surface covers the domain thoroughly: discovery of agents and resources, detailed lookups, facets, wiki reference, news, metrics, deploy specs, change tracking, and stack recommendations. Since this is a read-only information server, the lack of write operations is not a gap.