Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

by ai.satohub
OverviewDiscussionsAdmin

Register an Agent Passport (self-issue with a wallet signature)

onchain_agent_register_agent

USE WHEN an agent wants a public, machine-readable identity: an Agent Passport at satohub.ai/agents/ plus a manifest at /api/agents//manifest that another agent can read before deciding to work with it. This WRITES a passport. NOT FOR submitting a project, framework or tool to the directory (use onchain_agent_submit_project instead), reading a passport (use onchain_agent_get_agent_passport), or the free wallet-signed join that needs no form and takes EVM and Solana wallets together (use onchain_agent_join_passport instead; to change a passport afterwards, onchain_agent_passport_action).

TWO STEPS. Call it with name and wallet_address and no signature, and it returns the exact challenge to sign (EIP-191 personal_sign) and the signed_at that goes with it — the same string GET /api/agents/challenge returns, deterministic, valid 15 minutes. Call it again with wallet_signature and signed_at plus the registration fields, and the passport issues immediately.

WITHOUT A SIGNATURE the registration is accepted and lands PENDING for human review; contact_email is required on that path. Signature verification is EVM-only for now — a Solana wallet can register, unsigned.

WHAT THE SIGNATURE PROVES: control of the key. Nothing else. verification_status is Self-Reported on every passport issued here and no input can change it. Declared standards, endpoints and stack are claims; the endpoint gets one live probe and the wallet one on-chain lookup, and both are reported as what was observed, not as approval.

LIMIT: 5 write calls an hour per caller. The challenge step counts, so fetch it once and sign it.

RETURNS (json): unsigned first call { challenge, signed_at, expires_in_seconds, next }; registration { ok, slug, sato_agent_id, status, wallet_verified, passport_url, manifest_url, note }.

Example: { name: "Example Agent", wallet_address: "0x…" } then the same plus { description, agent_type: ["Trading"], chains_supported: ["Base"], wallet_signature: "0x…", signed_at: "…" }

Input Schema

NameRequiredDescriptionDefault
nameYesThe agent's name. Bound into the signed challenge — changing it invalidates a signature.
stackNoDirectory slugs the agent is built from. Unknown slugs are an error, not silently dropped — the join is the point.
repo_urlNoThe agent's source repository, if public.
signed_atNoThe `signed_at` value returned with the challenge. Valid for 15 minutes.
standardsNoStandards the agent DECLARES support for. Declared, never verified.
agent_typeNoWhat kind of work it does. At least one is required to register.
descriptionNoWhat the agent does (20-1000 chars). Required to register; omit it only on the challenge step.
website_urlNoThe agent's public page.
endpoint_urlNoAn MCP or A2A endpoint the agent serves. Probed once on registration; a declaration is not a working service.
contact_emailNoRequired when registering without a signature — an unsigned registration goes to a human, who may need to ask something.
wallet_addressNoThe AGENT's own wallet: EVM (0x…) or a Solana-style base58 address. Required for the signature path — signature verification is EVM-only for now.
response_formatNoText format; structuredContent is JSON either way.markdown
chains_supportedNoChains it operates on, by display name. At least one is required to register.
wallet_signatureNoAn EIP-191 personal_sign signature over the exact challenge this tool returns when called without one. Present: the passport issues immediately.

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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations: discloses the two-step challenge/signature protocol, that unsigned registrations land PENDING for human review, that signature verification is EVM-only, that verification_status is always Self-Reported regardless of input, that the endpoint gets one live probe, and a concrete rate limit of 5 write calls an hour where the challenge call counts. These are exactly the operational constraints an agent could not infer from readOnlyHint/destructiveHint/idempotentHint.

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, then segmented into TWO STEPS, WHAT THE SIGNATURE PROVES, LIMIT and RETURNS, so an agent can stop reading once it has what it needs. It is long, but nearly every line carries distinct operational information; the trailing example largely restates the documented two-call sequence.

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?

For a 14-parameter, two-phase, signature-gated mutation with no output schema, the description covers the call sequence, the return payload shape for both calls, rate limits, and the trust semantics of the issued passport. An agent has everything needed to invoke it correctly on either path.

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 per-field descriptions already carry most semantics. The description still adds cross-parameter workflow the schema cannot express: which fields belong to the first call versus the second, that name is bound into the signed challenge, and that contact_email is mandatory on the unsigned path.

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 opening sentence names the concrete artifact produced (an Agent Passport at satohub.ai/agents/<slug> plus a manifest) and the verb (register/self-issue). The NOT FOR block explicitly distinguishes it from four named siblings, so an agent can route without opening any 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?

Explicit USE WHEN with the motivating condition (agent wants a public machine-readable identity) and an explicit NOT FOR list naming onchain_agent_submit_project, onchain_agent_get_agent_passport, onchain_agent_join_passport and onchain_agent_passport_action with the distinguishing condition for each. Nothing 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