Skip to main content
Glama

Sato Hub: Onchain Agents

by ai.satohub
OverviewDiscussionsAdmin

Has this tool been answering?

onchain_agent_get_listing_history
Read-onlyIdempotent

ANSWERS ONE QUESTION: has this listing been answering Sato Hub's daily checks, and has its tool inventory moved? Returns a bounded 30-day shape from the listing's observed record — days observed, share of OUR checks that succeeded, current state and streak — plus the MCP tool-inventory changes in the window (date, count after the change, added, removed) and the current Sato Score.

RULE ENFORCED: success_rate_pct is the share of Sato Hub's own checks that succeeded, never "uptime" — a failure can be on our side. At most 30 entries; the daily rows are not returned (rule 24: shape, not rows). Absence of a record is unknown, not down.

Pass score_days to add score_series: the daily Sato Score readings we captured for this listing, up to 365 days. A day nobody measured is ABSENT from the array rather than carried forward — a gap is a gap — and every move is labelled project or methodology, the latter meaning Sato Hub revised the scoring rubric that day and the movement is ours.

Returns (json): { slug, days, observed: { days_observed, window_days, success_rate_pct, current_state, current_streak_days, last_check }, tool_history: [{ date, count, added, removed }], tools_now, tools_peak, trust_score, trust_tier, score_series, rules, sato_url }. Read-only.

Example: { slug: "jupiter-mcp", days: 30, score_days: 90 }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoLook-back window in days (1-30, default 30) for the observed record and the tool inventory.
slugYesThe resource slug, e.g. 'coinbase-agentkit'.
score_daysNoInclude the daily Sato Score series over this many days (2-365). A day nobody measured is absent from the series, never carried forward. Omit for no series.
response_formatNoOutput format: 'markdown' (default) or 'json'.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / days / description
      Previous value: -"Look-back window in days (1-30, default 30)."New value: +"Look-back window in days (1-30, default 30) for the observed record and the tool inventory."
    • addedInput schema / properties / score_days
      Added value: +{
+  "description": "Include the daily Sato Score series over this many days (2-365). A day nobody measured is absent from the series, never carried forward. Omit for no series.",
+  "maximum": 365,
+  "minimum": 2,
+  "type": "integer"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare the tool is read-only, idempotent, and open-world, and the description reinforces this with 'Read-only' and 'Absence of a record is unknown, not down.' It adds substantial non-obvious behavior: success_rate_pct is the share of Sato Hub's own checks (not uptime), daily rows are not returned, a maximum of 30 entries, and score_series gaps are left absent rather than filled. This goes well beyond annotation basics and clarifies edge semantics.

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 long but every section earns its place: the core question is front-loaded, the rule and edge cases are separated, and the example at the end anchors the parameter usage. Despite the length, it is well organized and does not repeat schema text verbatim, making it appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates well by listing all return fields, bounding the window, and explaining the most error-prone semantics (success_rate_pct, absence, score_series gaps). The only notable gap is a minor inconsistency: the description says 'Returns (json)' while the schema's response_format defaults to 'markdown' and allows both formats; an agent could be unsure whether the default output is JSON or Markdown without reading the schema.

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 the baseline is 3, but the description enriches several parameters: it clarifies that days produces a bounded 30-day shape, and it explains score_days in detail—up to 365 days, absent days omitted, and movements labeled project or methodology. It does not add much for slug or response_format, but the added semantics justify a notch above baseline.

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 sharply framed question—'has this listing been answering Sato Hub's daily checks, and has its tool inventory moved?'—and then enumerates the exact data returned: observed record, tool-history changes, and Sato Score. This is a specific verb+resource that is semantically distinct from sibling tools like get_resource or get_metrics, which fetch general resource or metric data rather than this focused listing-history shape.

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 makes the tool's purpose and main optional behavior ('Pass score_days to add score_series') unmistakable, so an agent can infer when this tool is relevant. However, it never explicitly names alternatives or states when not to use this tool versus siblings such as get_changes or get_metrics, so the guidance stops short of giving exclusions.

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