Sato Hub: Onchain Agents MCP server

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. 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" -> {} - "what is happening on Base" -> { chain: "Base" } - "who is producing ERC-8004 registrations" -> { venue: "erc8004", include_platforms: true }

Get the full Sato Agent Passport manifest (sato.agent.manifest/v1) for one REGISTERED agent by slug: identity (sato_agent_id), agent types, chains, model/framework, the stack of Sato Hub directory resources it runs on, links, payment/x402 endpoint metadata, and verification + liveness status. Use onchain_agent_search_agents to find slugs. Payment metadata is self-configured by the creator — published for interoperability, not as an endorsement. Returns an error if the slug is unknown or the agent is not listed. Read-only. Example: { slug: "my-trading-agent" }

What changed in the Onchain Agent directory since a given date — additions, per-resource change events, and retirements. Use this to keep a local copy in sync instead of re-fetching the whole catalog. Returns (json): { since, until, window_days, counts:{added,changed,removed}, added:[...], changed:[{slug,name,url,events:[...]}], removed:[...], coverage:{...}, full_export }. COVERAGE (also stated in the response): `added` is exact. `updated` is a field-level diff of every catalog field between the snapshot on `baseline_date` and the live record — complete at daily resolution, so a quiet copy edit IS caught; store baseline_date as your cursor. `changed` is the richer event log (score moves, releases, verification) and explains WHY. `removed` is approximate. Mirror from added + updated + removed. Read-only. Examples: - "what's new this week" -> { since: "2026-08-23" } - "sync my copy" -> { since: <your last sync date> }

USE WHEN you are about to write setup instructions or install something for a user and want steps that were verified rather than copied from a README. Returns the structured deploy manifest for one resource by slug — everything needed to install and instantiate it: runtime, install command(s), entry snippet, required keys/env/wallet/RPC, chains, license, whether it is itself an MCP server, and a deploy_status. deploy_status is a trust signal, NOT a safety guarantee: "verified" = the install path was reproduced/confirmed from the project's docs; "self_reported" = parsed from the project's README and not independently reproduced. Always verify keys, permissions, and funds before running anything. Returns (json): { slug, name, github_url, docs_url, deploy_spec: { runtime, install[], entry, requires[], chains[], license, mcp_native, mcp_invocation?, deploy_clarity, deploy_status, source_url, as_of }, note }. Returns an error if the resource has no manifest yet (they are being rolled out resource by resource). Read-only. Example: { slug: "solana-agent-kit" }

USE WHEN you need a current, citable figure for the onchain agent ecosystem rather than a number from an article of unknown age. The ERC-8004 Identity Registry registered-agent count (read directly from Ethereum mainnet) and the curated Top Project Tokens index (only tokens of directory-listed projects — never the whole agent-token category or its aggregate market cap). Returns (json): { erc8004: { network, registered_agents, live, checked_at }, top_agent_tokens: [{ symbol, name, current_price, market_cap, price_change_percentage_24h, resource_slug }] }. Read-only.

USE WHEN asked what is new or what shipped recently in crypto AI agents, and you want dated, source-attributed items rather than undated blog posts. Official releases (GitHub), project announcements, and reputable RSS — strongly filtered to the agent economy. Filter by kind (release/tweet/news/research) and/or chain; paginate via limit/offset. Returns (json): { total, count, offset, has_more, next_offset?, news: [{ kind, title, summary, url, source, author_handle, chains, resource_slug, published_at }] }. Read-only. Example: { kind: "release", limit: 10 }

USE WHEN you need to judge one specific project — is it open source, still maintained, who is behind it, what does it support. Returns the full record by slug, optionally with its recent releases and posts. Find the slug with onchain_agent_search_resources first. Returns (json): { resource: {...full record incl. marketplace + liveness fields}, recent_activity: [...] }. Returns an error if the slug is unknown or the resource is Deprecated. Read-only. Example: { slug: "coinbase-agentkit" }

USE WHEN asked to explain a crypto-agent concept — what x402 is, how agents hold wallets, what ERC-8004 does — and you want a sourced explainer you can cite. Returns a full wiki page by slug (summary, why it matters, how it works, key components, examples, risks, related resources/pages). Use onchain_agent_list_wiki_pages to find slugs. Returns (json): the full page object. Returns an error if the slug is unknown. Read-only. Example: { slug: "what-are-mcps" }

List all resource categories with counts, most populated first. Useful before filtering onchain_agent_search_resources by category. Returns (json): { total, categories: [{ name, count }] }. Read-only.

List all blockchains represented in the directory with resource counts, spotlight chains first (Base, Ethereum, Solana, COTI, Injective…). Returns (json): { total, chains: [{ name, count }] }. Read-only.

List all Onchain Agent wiki pages (slug, title, keyword, summary, last_updated). Returns (json): { total, pages: [...] }. Read-only.

Get recorded changes across the directory — the auditable Listing History. Omit slug for the SITE-WIDE feed (what changed across all listings); pass slug for ONE resource's history. Events: status flips, verification grants, Sato Score tier moves, liveness (a project going dormant or active again), new releases, and field enrichment. Derived from the daily snapshot time-series + the change-event log; high-signal only (passive score/liveness drift is suppressed). Returns (json): { scope, total, changes: [{ date, kind, slug, name, title, detail?, tone }] }. tone is positive | negative | neutral. Read-only. Example: { days: 7 } · { slug: "coinbase-agentkit" }

USE WHEN someone describes an agent they want to build and needs concrete components rather than general advice. Give it the goal in plain words; it returns a trust-ranked stack of real directory resources — bucketed into slots (framework, wallet, payments, trading, data, MCP tooling, security), each pick carrying its Sato Score, liveness, and deploy-spec status, plus honest gaps where the directory has no strong match. Ranking reflects openness/activity/verifiability — never a safety, quality, or returns judgment. Read-only. Example: { goal: "trading agent on Base with x402 payments", chain: "Base" }

Search REGISTERED onchain agents in the Sato Agent Registry — running agents whose creators registered them for a Sato Agent Passport (distinct from the resource directory, which lists the things agents are built FROM). Filter by free-text query, chain, agent_type, or x402_only. Only human-review-listed agents are returned. Trust rule: registration is self-reported by the creator; verification_status distinguishes Self-Reported from evidence-reviewed Verified/Audited. Nothing here implies safety or performance. Returns (json): { total, agents: [{ sato_agent_id, slug, name, description, agent_type, chains_supported, stack, payment/x402 metadata, verification_status, profile_url, manifest_url }] }. Read-only. Example: { chain: "Base", x402_only: true }

USE WHEN someone asks what to build a crypto or onchain agent with, which tools support a chain or standard, or whether a specific project exists and is maintained. Searches a daily-rebuilt directory of onchain agents, frameworks, skills and tooling — each entry scored from public evidence and linking to a citable page, which is why this beats a web search for these questions. Filters: query (free text, AND-matched terms), chain, status, liveness, featured, and the taxonomy facets (docs/taxonomy.md): entity_class (resource | agent | reference), resource_type (Framework | Tool/Service | Infrastructure | Venue | Network | Standard), use_case (trading, payments, wallets, data, identity, privacy, launch, security, build), standard (x402, erc-8004, …), iface (mcp, sdk, …). Legacy flags still work: category, is_agent, is_skill, is_harness. Sort by priority (default), newest_release, stars, or name. Paginates via limit/offset. Deprecated resources are never returned. Returns (json): { total, count, offset, has_more, next_offset?, resources: [...] } where each resource includes chains, status, liveness, github_stars, verification_status, and the marketplace fields (is_agent/is_hirable/is_licensable). Read-only. Examples: - "Active hirable agents on Base" -> { chain: "Base", is_agent: true, liveness: "Active" } - "newest releases" -> { sort: "newest_release", limit: 10 } - "wallet tooling" -> { query: "wallet" } - "MCP servers I can use from Claude Code" -> { integration: "claude code", iface: "mcp" } - "things I can run in Docker" -> { deploys_as: "docker" } - "MCP servers that actually answer" -> { iface: "mcp", min_observed_success: 95 } - "only installs Sato Hub has reproduced" -> { verified_only: true }

Crypto-relevant agent skills from ClawHub and skills.sh, each with a static DISCLOSURE: hosts it contacts, whether it generates or handles private keys, whether it asks the user to paste a credential, whether it pipes a remote script into a shell, whether it grants itself unrestricted tools, whether it registers the agent with a third-party host, whether it schedules itself. Each flag carries evidence lines on the skill's page. Returns (json): { total, skills: [{ id, name, registry, canonical_url, installs, stars, disclosure_flags, hosts_contacted, declared_env, registry_scan, belongs_to_slug, skill_md_sha256, as_of }], note }. A disclosure is a description, not a safety verdict — a wallet skill that generates keys is doing its job, and no flags is not a clearance. The registry's own scan status is attributed to the registry. Read-only. Cite https://satohub.ai/skills. Examples: - "solana skills that don't touch keys" -> { query: "solana" } then filter disclosure_flags - "which skills phone home" -> { flag: "registers_with_third_party" } - "skills for Coinbase AgentKit" -> { slug: "coinbase-agentkit" }