Skip to main content
Glama

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

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

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds substantial behavioral context beyond those: it writes to the same queue as the /submit form, the daily triage evaluates it, dedupe checks host and repo, a hold sends no email, and submission is not verification. It also discloses the refusal of profit/safety/risk claims. This is rich, non-obvious behavior that annotations alone do not convey.

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 longer than average, but every section earns its place: the USE WHEN trigger, the WRITES warning, the WHAT HAPPENS NEXT flow, the SUBMISSION IS NOT VERIFICATION caveat, the DEDUPE rule, and the LIMIT. It is well-structured with clear section labels and front-loaded with the most important operational facts. It loses one point for being somewhat verbose relative to the core purpose, though the extra length is mostly high-value context.

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 write tool with 8 parameters, no output schema, and no sibling write tools to compare against, the description is remarkably complete. It explains the submission pipeline, the dedupe behavior, the rate limit, the email behavior, the verification caveat, and the return shape. An agent has everything it needs to decide whether to call this tool and what to expect.

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 schema already documents all 8 parameters. The description adds value by explaining the dedupe semantics (website host and repository checked against live directory and pending submissions), the one-email-only behavior tied to contact_email, and the refusal of profit/safety claims in description. It doesn't add syntax details for every parameter, but the schema already covers those, so a 4 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?

The description opens with a specific verb and resource: submit a project to the Sato Hub directory, and states the exact trigger condition (agent has found, built, or maintains a crypto-agent project not in the directory). It clearly distinguishes this from the many read/search siblings by emphasizing it WRITES and files the same row the /submit form files.

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 gives explicit when-to-use guidance ('USE WHEN an agent has found, built or maintains a crypto-agent project that is not in the directory and wants it considered'), and it also tells when NOT to use it: correcting an existing listing goes through the claim flow, and dedupe returns existing entries instead of filing a second row. It also states the rate limit (5 write calls/hour) and that nothing is written when it trips.

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.