Skip to main content
Glama

Sato Hub: Onchain 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.

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

TableJSON 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_formatNoOutput format: 'markdown' (human-readable, default) or 'json' (machine-readable).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. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond annotations: it discloses the two-step challenge flow, the 15-minute challenge validity, the 5-write-calls-per-hour rate limit, the PENDING state for unsigned registrations, the Self-Reported verification_status that no input can change, the single live probe and on-chain lookup, and the fact that declared standards are claims not approvals. This is rich behavioral context that annotations (readOnlyHint=false, destructiveHint=false) do not provide.

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?

The description is long but every section earns its place: USE WHEN, TWO STEPS, WITHOUT A SIGNATURE, WHAT THE SIGNATURE PROVES, LIMIT, Returns, Example. It is front-loaded with the most important usage guidance and uses clear section headers. It could be slightly tighter, but the density of critical behavioral information justifies the length.

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-step registration tool with no output schema, the description is remarkably complete. It covers the call sequence, the challenge format (EIP-191 personal_sign), the rate limit, the pending path, the verification semantics, and the return shape. An agent has everything it needs to call this tool correctly without opening 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the two-step flow: name and wallet_address are used in the first call to get the challenge, and wallet_signature plus signed_at are used in the second call to issue. It also clarifies that contact_email is required on the unsigned path and that agent_type, description, and chains_supported are required to register. This adds orchestration-level semantics the schema alone doesn't convey.

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 and resource: register an Agent Passport (self-issue with a wallet signature), and clearly distinguishes it from siblings like onchain_agent_get_agent_passport (read) and onchain_agent_submit_project (different submission flow). It also explains the two-step challenge/signature flow, which makes the tool's purpose unmistakable.

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?

The description explicitly says USE WHEN an agent wants a public, machine-readable identity, and explains the two-step call pattern: first call without signature to get the challenge, second call with signature to issue. It also states when the unsigned path applies (PENDING for human review, contact_email required) and notes the EVM-only signature limitation. This is strong when-to-use guidance with clear alternatives implied.

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