Skip to main content
Glama

Sato Hub: Onchain Agents

by ai.satohub
OverviewDiscussionsAdmin

Is this going up or down?

onchain_agent_get_trend
Read-onlyIdempotent

ANSWERS ONE QUESTION: is this measurement going up or down? Returns a bounded series (at most 30 points, default 8) for ONE venue, ONE chain and ONE stage from Sato Hub's own weekly (or daily) chain reads — each point with its date, value, sample_size and method.

RULE ENFORCED: points are never summed across venues, chains or stages — the tool refuses to blend chains and tells you which chains exist when you omit one. A null point is UNKNOWN for that period, never zero. The weekly point is the citable one; daily points feed a trend and never a headline. Raw rows are not returned.

Returns (json): { venue, chain, stage, grain, unit, points: [{ date, value, sample_size, method, evidence_tier }], direction_first_to_last, known_points, rules, as_of, source }. Read-only.

Examples:

  • "are ERC-8004 registrations on Base growing" -> { venue: "erc8004", chain: "Base", stage: "registered" }

  • "x402 sellers week over week" -> { venue: "x402", chain: "Base", stage: "settled_to_catalogued_seller", points: 12 }

  • "do registered endpoints answer, day by day" -> { venue: "erc8004", chain: "Base", stage: "mcp_endpoint_answers", grain: "daily", points: 30 }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'stage' (default) is one venue/chain/stage series. 'movers' is the week's Sato Score movement across the directory — which listings rose, fell, crossed a tier, were scored for the first time, or answered our daily checks differently. In movers mode venue, chain and stage are ignored.stage
chainNoChain, e.g. Base, Ethereum, Gnosis. Required when the stage is measured on more than one chain — series are never blended across chains. Omit for venue-level rows.
grainNo'weekly' (the citable series, default) or 'daily' (the trend grain; never a headline).weekly
stageNoLifecycle stage, e.g. registered, launched, settled_to_catalogued_seller, mcp_endpoint_answers. Required in 'stage' mode.
venueNoVenue id, e.g. erc8004, olas, virtuals, x402, erc4337_accounts. See onchain_agent_get_agent_economy for the catalogue.
pointsNoHow many most-recent points (1-30, default 8).
response_formatNoOutput format: 'markdown' (default) or 'json'.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "stage",
+  "description": "'stage' (default) is one venue/chain/stage series. 'movers' is the week's Sato Score movement across the directory — which listings rose, fell, crossed a tier, were scored for the first time, or answered our daily checks differently. In movers mode venue, chain and stage are ignored.",
+  "enum": [
+    "stage",
+    "movers"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / stage / description
      Previous value: -"Lifecycle stage, e.g. registered, launched, settled_to_catalogued_seller, mcp_endpoint_answers."New value: +"Lifecycle stage, e.g. registered, launched, settled_to_catalogued_seller, mcp_endpoint_answers. Required in 'stage' mode."
    • removedInput schema / properties / stage / minLength
      Removed value: -1
    • removedInput schema / properties / venue / minLength
      Removed value: -1
    • removedInput schema / required
      Removed value: -[
-  "venue",
-  "stage"
-]
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

The annotations already declare read-only, idempotent, open-world, and non-destructive behavior, and the description complements them with rich normative behavior: points are never summed across venues/chains/stages, the tool actively refuses blended chains, null means UNKNOWN not zero, weekly points are the citable ones, daily points never become a headline, and raw rows are not returned. This is exactly the kind of beyond-schema transparency that helps an agent predict side effects and data semantics correctly.

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?

The text is long but purposeful: a one-sentence purpose statement comes first, then a clearly labeled RULE block, then a compact return-shape summary and three illustrative examples. Every major section earns its place because this is a seven-parameter tool with a non-trivial return shape. The all-caps 'ANSWERS ONE QUESTION' and 'RULE ENFORCED' are slightly aggressive, but they front-load the message without becoming filler.

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 there is no output schema, the description carefully documents the entire return envelope through a sample shape: venue, chain, stage, grain, unit, points with nested fields, direction_first_to_last, known_points, rules, as_of, and source. It also covers the edge semantics around chain omission and null/UNKNOWN. For a tool with this parameter complexity and no output schema, the description uniquely supplies the missing pieces an agent needs to call and interpret it 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?

Schema description coverage is 100%, so the baseline is already strong, but the description adds meaningful resolver examples that map user phrasing to concrete parameter sets, e.g., 'are ERC-8004 registrations on Base growing' -> { venue: 'erc8004', chain: 'Base', stage: 'registered' }. It also reinforces default and range semantics ('at most 30 points, default 8') and chain refusal when omitted, which goes beyond simply restating the schema. It does not revisit the 'response_format' option or the full 'movers' semantics, so it is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific question ('is this measurement going up or down?') and then names the resource and scope: Sato Hub's weekly/daily chain reads for ONE venue, ONE chain, ONE stage. It clearly distinguishes the tool from broader directory tools by emphasizing that venues, chains, and stages are never blended. A small deduction: it does not reference sibling tool names even though that would sharpen differentiation.

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 description gives concrete guidance: use 'stage' mode for a single series, 'movers' for directory movement, choose weekly when you need a citable number, and prefer daily only for trend context. It also explains when to omit or supply a chain, including that the tool will tell you which chains exist if you omit one. It stops short of explicitly contrasting with alternative sibling tools like get_metrics or get_listing_history, but the scoping rules prevent many confusions.

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