Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

by ai.satohub
OverviewDiscussionsAdmin

Look up one registered agent

onchain_agent_get_agent_passport
Read-onlyIdempotent

USE WHEN you are about to work with, pay or depend on a REGISTERED agent and want its published identity before committing. Find slugs with onchain_agent_search_agents. NOT FOR a project in the directory such as a framework or MCP server (use onchain_agent_get_resource instead; aixbt, almanak and coinbase-agentkit have no passport).

RETURNS 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. It also carries registration (the passport's lookup URL and any Sato Hub attestations recorded onchain on Base and Solana) and erc8004 (the ERC-8004 ids its proven wallets own, with links). An attestation is a registration record: it shows the registrant proved control of the wallets, and says nothing about what the agent does.

Payment metadata is self-configured by the creator, published for interoperability, not as an endorsement. An unknown slug, or an agent that is not listed, is a miss (not an error) carrying the nearest slugs as suggestions, or a pointer to onchain_agent_search_agents; a directory project's slug answers that it has no passport and points to onchain_agent_get_resource. Read-only.

There is deliberately no example slug: the registry is small and its slugs are not guessable. ('my-trading-agent' was this tool's own placeholder and four separate clients sent it as if it were real.)

Example: call onchain_agent_search_agents first, then { slug: }

Input Schema

NameRequiredDescriptionDefault
slugYesThe registered agent's slug — <slug from onchain_agent_search_agents>. Call onchain_agent_search_agents first; the registry is small and slugs are not guessable.
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' (human-readable, default) or 'json' (machine-readable)."New value: +"Text format; structuredContent is JSON either way."
  3. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"The registered agent's slug, e.g. 'my-trading-agent'. Use onchain_agent_search_agents to find slugs."New value: +"The registered agent's slug — <slug from onchain_agent_search_agents>. Call onchain_agent_search_agents first; the registry is small and slugs are not guessable."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, so the safety bar is met; the description adds substantial behavioral context beyond that — miss-vs-error semantics with fallback behavior, what attestations do and don't prove, the self-configured nature of payment metadata, and the explicit 'no example slug' rationale. This is well past what annotations carry.

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 / RETURNS, which is excellent structure. It is on the long side and the parenthetical about 'my-trading-agent' is an anecdote, but every section still serves routing or expectation-setting. Minor redundancy keeps it below 5.

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?

With no output schema, the description carries the full burden of describing return shape, and it does so thoroughly (identity, types, chains, stack, links, payment/x402 metadata, registration, erc8004). Edge cases (unknown slug, listed-but-no-passport, directory project) are all covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are fully documented in the schema, so the description does no heavy lifting here. It reinforces that slugs are not guessable and must come from search_agents, but that duplicates the schema's own note. Baseline 3 is appropriate.

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?

States a specific verb+resource (look up the full Sato Agent Passport manifest — sato.agent.manifest/v1 — for one registered agent by slug) and enumerates the contents. It explicitly distinguishes itself from siblings onchain_agent_get_resource and onchain_agent_search_agents, so an agent can route without opening schemas.

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?

Leads with 'USE WHEN you are about to work with, pay or depend on a REGISTERED agent', gives an explicit 'NOT FOR' case (directory projects/frameworks) with the exact alternative tool, and instructs calling onchain_agent_search_agents first. Both the positive and negative conditions are stated, plus named alternatives.

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