Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

by ai.satohub
OverviewDiscussionsAdmin

Watch a repo, package, endpoint or agent for a Preflight verdict change

onchain_agent_watch
Idempotent

USE WHEN an agent (or the person it works for) wants to be told if something in its stack stops checking out — rather than re-running a Preflight on a schedule of its own. This WRITES one subscription row. NOT FOR a one-off check now (use onchain_agent_preflight instead) or a record's change history (use onchain_agent_recent_changes). Goes through the SAME path the public form uses: same validation, same normalisation, same rate limit, one row per address and target.

WHAT HAPPENS: the target is re-checked once a day by the public Preflight path, and an email is sent ONLY when the verdict CHANGES. Never on a schedule, never a digest. A transition INTO unknown (a check that failed to run) is recorded and never mailed — a failed check is not news about the target. wallet: get told when Sato Scan sees address poisoning aimed at that wallet.

FREE WHILE IN PREVIEW. No price is set and no payment is taken.

WHAT IS STORED: the normalised target, the address (a notice has to be delivered), an HMAC of it for counting, and the baseline verdict. No IP address and no name. Asking twice is idempotent; action: "unsubscribe" stops the mail and answers the same way whether a row existed or not.

RULE ENFORCED: a verdict describes what was checked and when. It is not a safety, security or returns judgment, and a CHANGE is a change in what was observed — not a warning.

RETURNS (json): { ok, action, target_kind, target, watch_id, verdict, notice, caveat }.

Example: { target_kind: "package", target: "solana-agent-kit", notify_to: "me@example.com" }

Input Schema

NameRequiredDescriptionDefault
actionNosubscribe (default) arms the watch; unsubscribe stops the mail for this address and target.
targetYesThe thing itself, in the spelling that kind takes. It is normalised, so two spellings of one repository become one watch.
notify_toYesThe email address the change notice goes to. Stored once for delivery and counted by an HMAC; it never enters telemetry or logs.
target_kindYesWhat is being watched: repo (owner/name or a GitHub URL), package (npm name), endpoint (an https URL), agent (an ERC-8004 reference like 'base:42'), wallet (<Chain>:<address>, e.g. 'Base:0x...').
response_formatNoText format; structuredContent is JSON either way.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Changed1 schema field changed
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: 'markdown' (default) or 'json'."New value: +"Text format; structuredContent is JSON either way."
  3. Changed2 schema fields changed
    • changedInput schema / properties / target_kind / description
      Previous value: -"What is being watched: repo (owner/name or a GitHub URL), package (npm name), endpoint (an https URL), agent (an ERC-8004 reference like 'base:42')."New value: +"What is being watched: repo (owner/name or a GitHub URL), package (npm name), endpoint (an https URL), agent (an ERC-8004 reference like 'base:42'), wallet (<Chain>:<address>, e.g. 'Base:0x...')."
    • changedInput schema / properties / target_kind / enum
      Previous value: -[
-  "repo",
-  "package",
-  "endpoint",
-  "agent"
-]New value: +[
+  "repo",
+  "package",
+  "endpoint",
+  "agent",
+  "wallet"
+]
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, idempotentHint=true, etc.), but the description adds substantial behavior: it writes one subscription row, goes through the same validation/normalisation/rate-limit path as the public form, re-checks daily, mails ONLY on verdict change, never mails transitions into unknown, is idempotent on re-subscribe, and unsubscribing answers identically regardless of prior state. It also discloses retention (normalised target, address, HMAC, baseline verdict; no IP or name). This is well beyond what the annotations cover.

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 and organized into labeled blocks that each carry distinct information. It is dense and slightly long, but nearly every sentence adds an operational fact rather than restating structured data.

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?

Despite having no output schema, the description supplies a RETURNS field list and a concrete example call. Combined with full disclosure of lifecycle, idempotency, and storage, an agent has everything needed to invoke 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema, notably the wallet-specific behavior ('get told when Sato Scan sees address poisoning aimed at that wallet') and reinforces unsubscribe idempotency. It does not explain the response_format parameter, but that is trivial and schema-documented.

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 states a specific verb (watch/subscribe) and resource (repo, package, endpoint, agent, wallet) and explicitly distinguishes itself from onchain_agent_preflight and onchain_agent_recent_changes. An agent can identify this as the persistent-subscription tool versus the one-off check tool without opening either 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?

It has an explicit 'USE WHEN' block and a 'NOT FOR' block naming two alternatives with the condition that selects each. Nothing about when to route here versus a sibling is left to inference.

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