Sato Hub: Onchain Agents
Server Details
Search scored onchain agent frameworks, MCPs, wallets, tools, and live agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- satohubai/onchain-agents
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 12 of 12 tools scored. Lowest: 3.8/5.
Each tool targets a distinct entity or action: agent passport, deploy spec, resource details, metrics, news, categories, chains, wiki pages, changes, and two searches for agents vs resources. No overlap in purpose.
All tools follow the exact pattern 'onchain_agent_<verb>_<noun>' with snake_case throughout. Verbs are descriptive (get, list, search), and nouns clearly indicate the resource type.
12 tools is optimal for a directory service: covers search, retrieval, listing, and monitoring without being bloated or sparse. Each tool serves a clear, non-redundant purpose.
The tool surface fully covers the domain of an onchain agent directory: search agents and resources, get detailed manifests/specs, list taxonomy facets, view metrics, news, and change history. No obvious gaps for the intended read-only service.
Available Tools
12 toolsonchain_agent_get_agent_passportGet a Sato Agent PassportARead-onlyIdempotentInspect
Get 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. Use onchain_agent_search_agents to find slugs.
Payment metadata is self-configured by the creator — published for interoperability, not as an endorsement. Returns an error if the slug is unknown or the agent is not listed. Read-only.
Example: { slug: "my-trading-agent" }
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The registered agent's slug, e.g. 'my-trading-agent'. Use onchain_agent_search_agents to find slugs. | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by explaining error behavior (returns error if slug unknown) and providing caveat about payment metadata (self-configured, not endorsement). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs plus an example. Every sentence adds value: purpose, contents, caveat, error condition, and usage hint. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists the manifest contents comprehensively (identity, types, chains, model, resources, links, payment metadata, status). It also covers error behavior. The only minor gap is not explicitly stating the default output format (markdown via response_format), but the parameter handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully (100%), so baseline is 3. The description adds limited value: it provides an example for slug and directs to search_agents for finding slugs, but does not elaborate on response_format beyond what schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full Sato Agent Passport manifest for a registered agent by slug, listing specific contents (identity, types, chains, etc.). It distinguishes itself from sibling tools by mentioning onchain_agent_search_agents to find slugs, aligning with the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to get the passport for a registered agent, and use onchain_agent_search_agents to find slugs. It notes error conditions (unknown slug or unlisted agent) and marks it as read-only. It implies when not to use (when slug unknown) but does not explicitly exclude other scenarios or list alternatives beyond search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_get_deploy_specGet a resource's deploy manifestARead-onlyIdempotentInspect
Get the structured deploy manifest for one resource by slug — the essential, install-and-instantiate information an agent needs to BUILD from it: runtime, install command(s), entry snippet, required keys/env/wallet/RPC, chains, license, whether it is itself an MCP server, and a deploy_status.
deploy_status is a trust signal, NOT a safety guarantee: "verified" = the install path was reproduced/confirmed from the project's docs; "self_reported" = parsed from the project's README and not independently reproduced. Always verify keys, permissions, and funds before running anything.
Returns (json): { slug, name, github_url, docs_url, deploy_spec: { runtime, install[], entry, requires[], chains[], license, mcp_native, mcp_invocation?, deploy_clarity, deploy_status, source_url, as_of }, note }. Returns an error if the resource has no manifest yet (they are being rolled out resource by resource). Read-only.
Example: { slug: "solana-agent-kit" }
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The resource slug to get a deploy manifest for, e.g. 'solana-agent-kit'. | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable behavioral detail: it explains the deploy_status trust signal ('verified' vs 'self_reported'), warns about verification, specifies the output format (JSON with listed fields), and labels the operation as read-only. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and organized, with a clear opening and structured explanation. It includes an example and notes on error handling. However, some repetition (e.g., deploy_status explained twice) could be trimmed for greater conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully compensates by enumerating response fields (slug, name, deploy_spec including runtime, install, etc.), the deploy_status semantics, error scenario, and example. The tool's purpose and behavior are comprehensively covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description reinforces the slug usage with an example but does not add new semantics beyond the schema. A score of 3 is appropriate as the description offers no extra parameter insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the deploy manifest for a single resource by slug, listing specific included fields (runtime, install commands, etc.). The title 'Get a resource's deploy manifest' and sibling differentiation are evident, as sibling tools address other aspects like agent passport, metrics, or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (to obtain install-and-instantiate information for building) and includes an example usage. It also notes that an error is returned if no manifest exists. However, it does not explicitly contrast with alternative tools like onchain_agent_get_resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_get_metricsGet live onchain-agent metricsARead-onlyIdempotentInspect
Get live ecosystem metrics: the ERC-8004 Identity Registry registered-agent count (read from Ethereum mainnet) and the curated Top Project Tokens index (only tokens of directory-listed projects — never the whole agent-token category or its aggregate market cap).
Returns (json): { erc8004: { network, registered_agents, live, checked_at }, top_agent_tokens: [{ symbol, name, current_price, market_cap, price_change_percentage_24h, resource_slug }] }. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| token_limit | No | How many top project tokens to include (1-25, default 12). | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it reads from Ethereum mainnet, the top tokens are only from directory-listed projects, and it explicitly states 'Read-only'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a sample JSON return. It is front-loaded with the purpose and contains no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters with full schema coverage, clear annotations, and no output schema, the description is complete. It explains the two metrics, constraints on the token list, and the return structure via inline JSON. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds minimal extra meaning beyond the schema; it mentions token_limit and response_format indirectly via the sample JSON but doesn't elaborate on allowed values or defaults beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets live ecosystem metrics, specifically the ERC-8004 registered-agent count and curated Top Project Tokens index. The verb 'get' and resource specification distinguish it from sibling tools like get_agent_passport or get_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what it returns and includes a note that it 'never' returns the whole agent-token category, setting expectations. However, it does not explicitly state when to use this tool versus its siblings, though the distinct purpose makes it implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_get_newsGet Onchain Agent newsARead-onlyIdempotentInspect
Get the Onchain Agent news feed — official releases (GitHub), announcements (project X posts), and reputable RSS. Strongly filtered to the agent economy. Filter by kind (release/tweet/news/research) and/or chain; paginate via limit/offset.
Returns (json): { total, count, offset, has_more, next_offset?, news: [{ kind, title, summary, url, source, author_handle, chains, resource_slug, published_at }] }. Read-only.
Example: { kind: "release", limit: 10 }
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by item kind: release, tweet, news, or research. | |
| chain | No | Filter to items tagged with this chain. | |
| limit | No | Max results to return (1-50, default 20). | |
| offset | No | Results to skip, for pagination (default 0). | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. Description adds value by detailing the return structure, pagination fields (has_more, next_offset), and stating it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then filters, then return structure, then example. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and rich annotations, description fully covers usage: sources, filters, pagination, output format, and an example. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds an example and clarifies that kind/chain are optional filters, reinforcing the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the Onchain Agent news feed' with specific sources (GitHub releases, X posts, RSS). It distinguishes from sibling tools like get_metrics or search_agents by focusing solely on news items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit filtering options (kind, chain) and pagination (limit, offset). However, it does not specify when to avoid this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_get_resourceGet an Onchain Agent resourceARead-onlyIdempotentInspect
Get the full record for one directory resource by slug, optionally with its recent activity feed (releases/posts). Use onchain_agent_search_resources first to find a slug.
Returns (json): { resource: {...full record incl. marketplace + liveness fields}, recent_activity: [...] }. Returns an error if the slug is unknown or the resource is Deprecated. Read-only.
Example: { slug: "coinbase-agentkit" }
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The resource slug, e.g. 'coinbase-agentkit'. | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
| include_activity | No | Include the resource's recent activity feed (releases/posts). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. Description adds that the tool is read-only, describes the response JSON structure, and specifies error conditions for unknown/deprecated slugs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then usage, then return format, then error handling. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only resource fetch with thorough annotations and 100% schema coverage, the description provides all necessary context: return structure, error cases, and usage pattern. No gaps despite lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by providing an example slug, noting response_format defaults to markdown, and explaining include_activity defaults true. No parameter is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'gets the full record for one directory resource by slug'. It differentiates from the sibling 'search_resources' by advising to use that first to find a slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use onchain_agent_search_resources first to find the slug, and notes errors for unknown or deprecated slugs. Could mention when not to use (e.g., for searching multiple resources), but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_get_wiki_pageGet a wiki pageARead-onlyIdempotentInspect
Get a full Onchain Agent wiki page by slug — an editorial explainer (summary, why it matters, how it works, key components, examples, risks, related resources/pages). Use onchain_agent_list_wiki_pages to find slugs.
Returns (json): the full page object. Returns an error if the slug is unknown. Read-only.
Example: { slug: "what-are-mcps" }
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The wiki page slug, e.g. 'what-are-mcps'. | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints. The description adds notes on return value and error handling, but misstates the default response format (json vs markdown), which could mislead agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loads the purpose, and includes a helpful example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations and full schema coverage, the description adequately covers purpose, usage, return value, error behavior, and an example. No output schema is needed given the explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add significant meaning beyond the schema—only an example slug is provided. The response_format parameter is not elaborated on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a full wiki page by slug, specifying the content type (editorial explainer) and distinguishing it from related sibling tools like list_wiki_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use onchain_agent_list_wiki_pages to find slugs, and notes that an error is returned for unknown slugs. This effectively tells the agent when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_list_categoriesList directory categoriesARead-onlyIdempotentInspect
List all resource categories with counts, most populated first. Useful before filtering onchain_agent_search_resources by category. Returns (json): { total, categories: [{ name, count }] }. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the return format and confirms read-only nature, aligning with annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two sentences covering purpose, ordering, and sibling context, plus a brief output specification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description fully covers purpose, output structure, ordering, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which is fully described via enum and default. The description does not need to add further parameter details; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists resource categories with counts, ordered by popularity, and explicitly mentions its use as a precursor to filtering by category in a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context on when to use the tool ('useful before filtering onchain_agent_search_resources by category'), but does not include when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_list_chainsList supported chainsARead-onlyIdempotentInspect
List all blockchains represented in the directory with resource counts, spotlight chains first (Base, Ethereum, Solana, COTI, Injective…). Returns (json): { total, chains: [{ name, count }] }. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds the return structure and mentions 'spotlight chains first,' providing useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers purpose and ordering, second covers return format and safety. Every sentence is informative and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description provides complete context: purpose, return format, ordering, and safety. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (response_format) fully documented. Description does not add additional meaning for this parameter, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all blockchains' with specific details about resource counts and ordering (spotlight chains first). This distinguishes it from siblings like list_categories or list_wiki_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting an overview of supported chains, but does not explicitly state when to use this tool versus alternatives like search_agents. No exclusions or context for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_list_wiki_pagesList wiki pagesARead-onlyIdempotentInspect
List all Onchain Agent wiki pages (slug, title, keyword, summary, last_updated). Returns (json): { total, pages: [...] }. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating 'Read-only' and describing the return format (json: { total, pages: [...] }), including the fields. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus return format. It is front-loaded with the core action and adds no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately explains the return structure (total, pages, fields). It is complete enough for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (response_format) having a clear enum and description. The description does not add new information about parameters beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all Onchain Agent wiki pages') and specifies the returned fields (slug, title, keyword, summary, last_updated). It distinguishes from siblings like 'get_wiki_page' (singular) and 'list_categories' by focusing on wiki pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., 'get_wiki_page' for a single page, 'search_agents' for filtering). The description only states 'List all' without indicating if pagination or filtering is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_recent_changesRecent changes to listingsARead-onlyIdempotentInspect
Get recorded changes across the directory — the auditable Listing History. Omit slug for the SITE-WIDE feed (what changed across all listings); pass slug for ONE resource's history. Events: status flips, verification grants, Sato Score tier moves, liveness (a project going dormant or active again), new releases, and field enrichment. Derived from the daily snapshot time-series + the change-event log; high-signal only (passive score/liveness drift is suppressed).
Returns (json): { scope, total, changes: [{ date, kind, slug, name, title, detail?, tone }] }. tone is positive | negative | neutral. Read-only.
Example: { days: 7 } · { slug: "coinbase-agentkit" }
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (1-90, default 14). | |
| slug | No | Limit to one resource's recorded history by slug. Omit for the site-wide feed across all listings. | |
| limit | No | Max changes to return (1-50, default 20). | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, etc. The description adds behavioral details: derived from daily snapshots and change-event log, high-signal only (suppressing passive drift), and explicit output structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: purpose, slug distinction, event list, derivation notes, output format with example. No redundancy, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return structure (scope, total, changes array with fields). It covers read-only nature, filtering by slug, and time window. Sufficient for an AI agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds context for slug (site-wide vs resource) and provides an example for days. It explains the output format options, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'gets recorded changes across the directory' and distinguishes between site-wide feed (omit slug) and per-resource history (pass slug). It lists specific event types, making the tool's purpose precise and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to omit or include slug, and notes that only high-signal events are included. It does not directly compare to sibling tools or state when not to use, but the context is clear enough for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_search_agentsSearch the Agent RegistryARead-onlyIdempotentInspect
Search REGISTERED onchain agents in the Sato Agent Registry — running agents whose creators registered them for a Sato Agent Passport (distinct from the resource directory, which lists the things agents are built FROM). Filter by free-text query, chain, agent_type, or x402_only. Only human-review-listed agents are returned.
Trust rule: registration is self-reported by the creator; verification_status distinguishes Self-Reported from evidence-reviewed Verified/Audited. Nothing here implies safety or performance.
Returns (json): { total, agents: [{ sato_agent_id, slug, name, description, agent_type, chains_supported, stack, payment/x402 metadata, verification_status, profile_url, manifest_url }] }. Read-only.
Example: { chain: "Base", x402_only: true }
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Filter to agents supporting this chain. | |
| query | No | Free-text search across agent name, description, creator, stack, and type. | |
| x402_only | No | True = only agents exposing an x402 payment endpoint. | |
| agent_type | No | Filter by agent utility type: trading, research, defi, payments, security, social, workflow, gaming, data, coding. | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, non-destructive. Description adds that registration is self-reported and verification_status distinguishes, which is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and an example. Every sentence adds value, though slightly verbose; still highly efficient for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return structure explicitly (total and agents array with fields) and covers read-only nature, filters, and trust rules fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning for each parameter: chain, query, x402_only, agent_type, response_format includes defaults and purpose. Baseline 3 raised to 4 due to additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches registered onchain agents in the Sato Agent Registry, distinguishes from the resource directory, and lists key filters and return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (searching registered agents) and distinguishes from sibling tools like search_resources. Includes trust rule and example filter, but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
onchain_agent_search_resourcesSearch Onchain Agent directoryARead-onlyIdempotentInspect
Search the Onchain Agent directory of onchain agents, frameworks, skills, and tooling.
Filters: query (free text, AND-matched terms), chain, status, liveness, featured, and the taxonomy facets (docs/taxonomy.md): entity_class (resource | agent | reference), resource_type (Framework | Tool/Service | Infrastructure | Venue | Network | Standard), use_case (trading, payments, wallets, data, identity, privacy, launch, security, build), standard (x402, erc-8004, …), iface (mcp, sdk, …). Legacy flags still work: category, is_agent, is_skill, is_harness. Sort by priority (default), newest_release, stars, or name. Paginates via limit/offset. Deprecated resources are never returned.
Returns (json): { total, count, offset, has_more, next_offset?, resources: [...] } where each resource includes chains, status, liveness, github_stars, verification_status, and the marketplace fields (is_agent/is_hirable/is_licensable). Read-only.
Examples:
"Active hirable agents on Base" -> { chain: "Base", is_agent: true, liveness: "Active" }
"newest releases" -> { sort: "newest_release", limit: 10 }
"wallet tooling" -> { query: "wallet" }
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order: priority (default), newest_release, stars, or name. | priority |
| chain | No | Filter to resources supporting this chain. | |
| iface | No | Filter by how it is accessed/integrated: mcp, sdk, rest-api, plugin, cli, ui, contract. | |
| limit | No | Max results to return (1-50, default 20). | |
| query | No | Free-text search across name, description, tags, chains, and agent type. Space-separated terms are AND-matched. | |
| offset | No | Results to skip, for pagination (default 0). | |
| status | No | Filter by lifecycle status. | |
| category | No | Filter to a resource category. | |
| featured | No | True = only editorially featured resources. | |
| is_agent | No | True = only resources that are themselves onchain agents. | |
| is_skill | No | True = only agent-skill resources (skill repos/marketplaces). | |
| liveness | No | Filter by activity recency: Active (≤30d), Recent (≤90d), Quiet (≤1y), Dormant (>1y). | |
| standard | No | Filter to resources supporting a standard: x402, erc-8004, erc-8183, mcp, a2a. | |
| use_case | No | Filter by use case: trading, payments, wallets, data, identity, privacy, launch, security, build. | |
| is_harness | No | True = only agent frameworks/harnesses (OpenClaw, Codex, Claude Code…). | |
| entity_class | No | Filter by class: 'resource' = things you build/deploy WITH (frameworks, tools, infra, venues, standards); 'agent' = curated, live onchain agents; 'reference' = editorial. | |
| resource_type | No | Filter resources by role. Venue = DEX/launchpad/marketplace; Network = an L1/L2. | |
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, openWorldHint true, idempotentHint true, and destructiveHint false. The description supplements this by noting deprecated resources are never returned, pagination mechanics, and the JSON response structure, adding valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized: it opens with purpose, lists filters with explanations, covers pagination and return format, and ends with examples. Each sentence earns its place, though could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters, no required ones, 100% schema coverage, and annotations that already convey safety and idempotency, the description fully covers usage patterns, output structure, and edge cases (e.g., deprecated resources). It is complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds significant value by explaining AND-matched terms, legacy flags, sorting options, and return fields, giving agents richer semantic understanding than schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches an 'Onchain Agent directory of onchain agents, frameworks, skills, and tooling' with specific verb and resource. It distinguishes from sibling tools like onchain_agent_search_agents by its broader scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete examples of queries and filters, showing when to use different parameters. However, it does not explicitly contrast with sibling tools like onchain_agent_search_agents for agent-only searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!