Skip to main content
Glama

Sato Hub: Build Onchain & Crypto Agents

Submit a project to the Sato Hub directory

onchain_agent_submit_project
Idempotent

USE WHEN an agent has found, built or maintains a crypto-agent project that is not in the directory and wants it considered. NOT FOR correcting a listing that already exists (that goes through the claim flow on its page), checking whether a project is listed (use onchain_agent_search_resources first), or registering a running agent (use onchain_agent_register_agent).

This WRITES: it files the same row the /submit form files, into the same queue, and the daily triage run evaluates it through the same single apply path — probe the public evidence, validate against the listing schema, list it or hold it or decline it with a reason.

WHAT HAPPENS NEXT: the website, the repository and any declared endpoint are probed from public sources. A project that clears that evidence is listed; one that does not is held for a person, or declined with the reason. If contact_email is given you get exactly ONE email, and only if it is listed. A hold sends nothing — silence means a person is looking.

SUBMISSION IS NOT VERIFICATION. It is a request to be looked at. Being listed says what was observed about a project on a date, not that it is safe, audited, profitable or endorsed. Copy carrying profit, safety or risk claims is refused here rather than quietly cleaned up.

DEDUPE: the website host and the repository are checked against the live directory and against submissions already waiting. A match returns that existing entry instead of filing a second row — correcting a listing that already exists goes through the claim flow on its page, which proves control of the domain first.

LIMIT: 5 write calls an hour per caller. Nothing is written when it trips.

RETURNS (json): { ok, duplicate, submission_id | slug, next, caveat }.

Example: { name: "Example Agent Kit", website_url: "https://example.dev", repo_url: "https://github.com/example/kit", category: "Agent Framework", description: "A TypeScript toolkit for wiring agents to Base with viem and an MCP server.", chains: ["Base"] }

Input Schema

NameRequiredDescriptionDefault
nameYesThe project's name, as its own site writes it.
chainsNoChains it supports, by display name, e.g. ['Base','Solana'].
categoryYesThe directory category it belongs in. Pick the closest; triage corrects it if you are wrong.
repo_urlNoThe public source repository, when there is one: github.com/<owner>/<name>.
descriptionYesWhat it does, in plain words: what it is, who it is for, what it connects to. No profit, safety or performance claims — they are refused at the door.
website_urlYesThe project's own https site. Not a GitHub URL unless the repository IS the project's home.
contact_emailNoWhere the one approval reply goes. Optional — without it nothing is ever sent, and there is no other notification.
response_formatNoText format; structuredContent is JSON either way.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / category / enum
      Previous value: -[
      -  "Onchain Agent",
      -  "MCP",
      -  "Skill Repo",
      -  "Agent Framework",
      -  "Agent Launchpad",
      -  "Agent Marketplace",
      -  "Wallet Infrastructure",
      -  "DeFi Tool",
      -  "Trading Tool",
      -  "DAO Tool",
      -  "Research Tool",
      -  "Data Tool",
      -  "Security Tool",
      -  "Developer Tool",
      -  "API / SDK",
      -  "Research Paper",
      -  "Newsletter",
      -  "Community",
      -  "Other"
      -]New value: +[
      +  "Onchain Agent",
      +  "MCP",
      +  "Skill Repo",
      +  "Agent Framework",
      +  "Agent Launchpad",
      +  "Agent Marketplace",
      +  "Wallet Infrastructure",
      +  "Payment Rail",
      +  "DeFi Tool",
      +  "Trading Tool",
      +  "DAO Tool",
      +  "Research Tool",
      +  "Data Tool",
      +  "Security Tool",
      +  "Developer Tool",
      +  "API / SDK",
      +  "Research Paper",
      +  "Newsletter",
      +  "Community",
      +  "Other"
      +]
  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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds substantial context beyond them: the 5-writes/hour rate limit, the shared triage/apply path, the public-evidence probing and list/hold/decline outcomes, the single-email behavior, that a hold is silent, and that submission is not verification. This is exactly the kind of operational detail annotations cannot express.

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-loads the routing decision, then layers WRITES / WHAT HAPPENS NEXT / DEDUPE / LIMIT / RETURNS as scannable labeled blocks, so it is easy to parse. It is long, but for a mutation with this many side effects and constraints the length is largely earned; only marginal trimming would help.

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 8 parameters (4 required), no output schema, and a mutation on an open world, the description carries the load well: it documents the write path, dedupe behavior, rate limit, notification semantics, and even enumerates the JSON return shape and a sample call. An agent has everything needed to call it correctly and interpret the result.

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 goes further by explaining that the website host and repository act as dedupe keys checked against the live directory and pending submissions, and by clarifying the consequence of supplying contact_email (exactly one email, only on listing) — semantics not stated in the schema. It still omits field-level guidance that the schema covers.

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 names a specific verb and resource ('files the same row the /submit form files') and explicitly frames it as submitting a project to the directory. It distinguishes the tool from three siblings by name — onchain_agent_search_resources, onchain_agent_register_agent, and the claim flow — 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?

The 'USE WHEN' / 'NOT FOR' structure is explicit: it states the triggering condition (a project not in the directory that the agent wants considered) and three excluded cases, each with the correct alternative tool or flow. 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.