Sato Hub: Onchain Agents

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

Beyond the readOnly/idempotent/openWorld annotations, it explains interpretation rules: never sum across venues, null means UNKNOWN not zero, publishable=false below sample_size 20, and Solana identity counts are upper bounds. It also states 'Read-only' and the citation requirement, so the agent understands exactly what these numbers do and do not mean.

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 every section earns its place: it front-loads the purpose, provides the full return shape (no output schema exists), gives non-obvious numerical caveats, and ends with useful examples. The labeled 'HOW TO USE THESE NUMBERS' block makes the dense content scannable.

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 complex measurement tool with no output schema, the description fully compensates: it documents the JSON shape, lists venues and chains, states measurement caveats, supplies examples, and gives attribution. An agent has everything needed to invoke it correctly and interpret results.

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 the baseline is 3. The description adds value by demonstrating realistic parameter combinations in the Examples and explaining the consequence of include_platforms ('roughly doubles the response'), which goes beyond the schema's one-line descriptions.

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?

Opens with a specific verb-resource pair ('Measure the onchain agent economy') and then sharpens it: 'registries, launchpads, payment rails and account infrastructure — measured weekly from public chain reads.' This distinguishes it from sibling read/search/wiki tools by naming the exact measurement scope and cadence.

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 Examples section gives concrete triggering questions and maps them to parameter payloads (e.g. 'what is happening on Base' -> { chain: 'Base' }), which tells an agent when to call the tool. It does not explicitly contrast with sibling tools or state when not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that an error is returned if the slug is unknown or the agent is not listed, and by adding a meaningful caveat that payment metadata is self-configured and published for interoperability rather than as an endorsement. It also explicitly confirms the read-only nature, aligning with 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 well-structured: a front-loaded main clause, a usage pointer, a caveat, an error-behavior note, and an example. The first sentence is somewhat long because it enumerates many manifest fields, but this is justified given there is no output schema and those details help an agent anticipate the return content.

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 lookup with two well-documented parameters and no output schema, the description is complete: it names the return contents, identifies how to discover valid slugs, notes failure behavior, clarifies a potential trust concern, and confirms non-destructiveness. No critical context an agent would need to call this tool successfully is missing.

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 the schema already fully documents both 'slug' and 'response_format'. The description reinforces the slug semantics and provides an example, but it does not add meaning beyond the schema, such as clarifying response_format behavior or edge cases. A baseline 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 opens with a specific verb and resource: 'Get the full Sato Agent Passport manifest (sato.agent.manifest/v1) for one REGISTERED agent by slug.' It clearly differentiates this from sibling get_* tools by naming the unique resource type and outcome, and the title 'Look up one registered agent' reinforces this.

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 gives clear context for when to use this tool — when you need the full passport manifest for one registered agent — and explicitly names onchain_agent_search_agents as the way to find slugs, which is a useful pointer to an alternative tool. It stops short of explicitly stating when not to use this tool or contrasting it with other get_* siblings, but the guidance is sufficient for an agent to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint), the description adds substantial behavioral detail: `added` is exact, `updated` is a field-level diff that catches quiet edits, `changed` is the richer event log, `removed` is approximate, and the suggested mirror strategy. It also explicitly says 'Read-only.' No contradiction with 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 well-structured and front-loaded with the core purpose, followed by a concise return schema, a clarity-enhancing coverage section, and practical examples. Every sentence earns its place by providing non-obvious details such as approximation caveats and cursor advice.

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?

There is no output schema, but the description compensates by fully explaining the returned JSON shape and the meaning of each coverage category. It also addresses sync semantics, read-only behavior, and gives usage examples. The only minor gap is not explicitly contrasting with recent_changes, but the description is otherwise complete for correct 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?

The single parameter `since` is fully documented in the schema (100% coverage), including format, default, and clamping. The description adds practical use-case examples showing how to set `since` for different intents, which enriches the semantic meaning beyond the raw schema. This is above the baseline for high schema coverage.

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 states a specific verb and resource: it returns what changed in the Onchain Agent directory since a given date, including additions, change events, and retirements. This clearly communicates the tool's function, though it does not explicitly distinguish itself from the similarly named sibling onchain_agent_recent_changes.

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 gives clear usage context: 'Use this to keep a local copy in sync instead of re-fetching the whole catalog.' It also provides two concrete examples ('what's new this week' and 'sync my copy'). It does not explicitly state when not to use it or name alternative sibling tools, so it stops short of full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Adds substantial behavior beyond the readOnly/idempotent annotations: explains deploy_status as a trust signal rather than a safety guarantee, notes that missing manifests return an error, and includes a safety warning about verifying keys and permissions. Also explicitly states '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?

Front-loaded with the use trigger and organized into clear sections: use case, return shape, trust semantics, error behavior, and example. Slightly verbose but each sentence adds useful context 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?

With no output schema, the description provides a detailed return shape, explains deploy_status semantics, warns about safety, and documents error conditions. This is enough for an agent to know what to expect and how to interpret results.

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?

Input schema has 100% description coverage for both params, so the schema already carries the parameter documentation. The description adds an example for slug but does not meaningfully elaborate on response_format or go beyond what the schema provides. 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?

Description uses a specific verb+resource: returns the structured deploy manifest for one resource by slug, including install commands and runtime. It clearly differentiates itself from sibling tools by focusing on verified install/deploy information rather than general resource info, metrics, news, or 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?

Starts with 'USE WHEN you are about to write setup instructions or install something' which gives a clear trigger and context. It does not explicitly name alternatives or exclusion conditions, but the intended use case is strongly implied and distinguishable from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description reinforces this with 'Read-only.' Beyond annotations, it discloses the data source (Ethereum mainnet ERC-8004 registry), the inclusion rule for the token index (only directory-listed projects, never the whole category or aggregate market cap), and the exact return shape. This is substantial behavioral detail that helps an agent trust and interpret the result.

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 well-structured with a front-loaded usage trigger, a compact explanation of what is included and excluded, and an inline return schema. It is slightly long but justified because there is no separate output schema in the definition and the exact semantics of the curated index need clarification.

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 has no output schema, the description compensates by embedding the JSON return structure. It also explains what each number represents, how the agent count is sourced, and what the token index intentionally excludes. Combined with the annotation set, nothing critical is missing for an agent to decide whether and how to invoke this tool.

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 both parameters (token_limit, response_format) have clear inline descriptions, defaults, bounds, and enums. The description does not need to add parameter syntax, and it does not; it focuses output semantics instead, which is appropriate. Baseline 3 is the right level because the schema already carries the parameter meaning.

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 identifies the tool's purpose: retrieving live ecosystem metrics, specifically the ERC-8004 registered-agent count and the curated Top Project Tokens index. It describes the resource and scope in enough detail to distinguish it from sibling tools like news, changes, or resource lookups, even though it does not name an alternative explicitly.

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 an explicit 'USE WHEN' condition: a current, citable figure is needed, and it draws a contrast with 'a number from an article of unknown age.' This gives clear context and a when-not-to-use signal, though it does not name an alternative sibling tool as the preferred replacement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description reinforces 'Read-only' while adding meaningful behavioral detail: results are source-attributed, filtered to the agent economy, and paginated. It also discloses the exact JSON return shape including pagination fields such as total, count, offset, has_more, and next_offset.

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 front-loaded with the trigger condition, followed by source scope, filtering options, pagination, return shape, and a compact example. Every sentence earns its place, and there is no redundant or filler content.

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?

There is no output schema, but the description compensates by providing a full return-shape sketch and pagination semantics, so an agent can predict what the tool returns. Combined with fully documented parameters and safety annotations, nothing essential for selecting or invoking this read-only tool is missing.

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?

The input schema covers 100% of parameters with descriptions, enums, defaults, and bounds, so the description does not need to add much. The example and the mention of filtering/pagination are convenient, but they add no semantic content beyond what the schema already 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 opens with a specific trigger ('asked what is new or what shipped recently in crypto AI agents') and names the resource: dated, source-attributed news/releases in the agent economy. It differentiates from siblings like get_changes/recent_changes by emphasizing GitHub releases, project announcements, and RSS rather than edit/change logs.

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 explicitly states when to use the tool and gives selection criteria ('dated, source-attributed items rather than undated blog posts'). It also explains filtering by kind/chain and pagination, but it does not name sibling alternatives directly, so the when-not guidance is clear but not tool-to-tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark the tool read-only and idempotent; the description adds error behavior for unknown or Deprecated slugs and outlines the return payload (resource + recent_activity). The bare 'Returns (json)' is slightly ambiguous next to response_format's markdown default, but it does not contradict 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 front-loaded with the when-to-use trigger, followed by return shape, error behavior, and an example. It is compact, though 'Read-only' duplicates the annotation and 'Returns (json)' could be phrased more carefully.

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 single-record lookup with no output schema, it covers purpose, prerequisite search step, return payload shape, error conditions, and safety behavior. An agent has enough information to select and invoke the tool correctly.

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 slug, response_format, and include_activity are already documented with defaults and enums. The description adds only a concrete slug example and restates that activity includes releases/posts, which is marginal beyond the 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 first sentence states a specific use case: judging a single project (open source, maintenance, authors, supported features). 'Returns the full record by slug' names the resource and key, and it explicitly points to onchain_agent_search_resources for slug discovery, distinguishing it from the search sibling.

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?

'USE WHEN you need to judge one specific project' gives a clear trigger, and 'Find the slug with onchain_agent_search_resources first' provides the prerequisite and named alternative. It does not enumerate when-not cases for the other get_* siblings, but the single-project scope makes those exclusions reasonably inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover read-only/idempotent behavior, and the description adds useful behavioral details: it returns a full page object, returns an error for unknown slugs, and documents the content structure. There is minor ambiguity around the response_format default (markdown) versus the description's 'Returns (json)' phrasing, but no direct contradiction with 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 front-loaded with the usage trigger and stays reasonably compact while covering purpose, return structure, slug discovery, error behavior, and an example. Minor redundancy exists ('Read-only' repeats the annotation, and the 'Returns (json)' line could be clearer), but overall every section earns its place.

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 wiki lookup with two parameters and no output schema, the description is largely complete: it explains what the page contains, how to find slugs, what errors to expect, and the response format option. The small ambiguity about markdown versus JSON output prevents a perfect score.

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 the schema already documents both parameters and the default. The description adds an example slug and notes error behavior for unknown slugs, which adds some semantics, but it does not substantially expand on what the schema already 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 the tool's purpose with a specific verb ('explain') and resource ('crypto-agent concept'), lists concrete examples like x402 and ERC-8004, and enumerates the returned wiki page sections. It also distinguishes itself from sibling tools by directing users to onchain_agent_list_wiki_pages for finding slugs.

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 includes explicit 'USE WHEN' triggers and tells users to use onchain_agent_list_wiki_pages to find slugs. It could be stronger in naming sibling alternatives like get_resource or search_agents, but it provides enough context for an agent to select this tool over the list/search siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: the 'most populated first' ordering and the exact return shape ({ total, categories: [{ name, count }] }), which is especially helpful because there is no output schema.

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?

Three short sentences with no filler: behavior, use case, return shape, and read-only note. The core purpose is front-loaded.

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?

Complete for a simple, read-only listing tool. It covers what the tool does, when it should be used, what it returns, and the fact that it is safe to call. The absence of an output schema is compensated for by the explicit return shape.

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% for the single optional response_format parameter, so the description does not need to add parameter-level detail. The 'Returns (json)' line could be more precise given the default is markdown, but the input schema resolves that ambiguity.

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?

States a specific verb and resource: 'List all resource categories with counts, most populated first.' This clearly distinguishes it from siblings such as search_resources or list_chains.

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 says it is useful before filtering onchain_agent_search_resources by category, giving an agent a concrete when-to-use signal and the name of the related sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The description adds value beyond the annotations by disclosing the exact return shape ({ total, chains: [{ name, count }] }) and the spotlight-first ordering. It also reaffirms the read-only nature, consistent with the annotations. Minor ambiguity: it says 'Returns (json)' while the response_format parameter defaults to markdown.

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 two tight sentences with no filler. The main function is front-loaded, followed by the exact output shape and a short safety note.

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 tool with one optional parameter and no output schema, this description is complete. It specifies the resource scope, output format, ordering, and read-only nature, giving an agent everything needed to invoke it correctly.

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 the single optional response_format parameter is already fully documented. The description adds no additional parameter meaning, which is acceptable given the schema's completeness.

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 opens with a specific verb and resource: 'List all blockchains represented in the directory with resource counts'. It also clarifies the unique subject ('chains') against sibling list tools like onchain_agent_list_categories and onchain_agent_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 title 'See which chains are covered' and the description's explicit mention of 'resource counts' and 'spotlight chains first' give clear context for when this is useful. It does not name alternatives or exclusion criteria, but the intended use case is evident.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

'Read-only' adds nothing beyond the readOnlyHint annotation, and the tool adds the return shape { total, pages: [...] }. However, 'Returns (json)' is contradictory with the response_format default of 'markdown' in the schema, so the description misrepresents the default response format. No pagination/ordering caveats are disclosed.

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 one compact sentence with the action and key fields front-loated, plus a terse read-only note. No filler.

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 optional-parameter, well-annotated tool, the description supplies the necessary return-shape and field list because there is no output schema. It is slightly incomplere because it omits the markdown/json default caveat and does not route to get_wiki_page for a single page, though the schema mitigates the format issue.

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 carries all parameter information (100% coverage): response_format enum, default, and meaning are fully documented in the input schema. The description contributes no additional parameter sematics and its 'Returns (json)' wording is ambiguous against the default, but the schema itself is sufficient.

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 uses a specific verb+resource ('List all Onchain Agent wiki pages') and enumerates the returned fields (slug, title, keyword, summary, last_updated). It clearly distinguishes from sibling get_wiki_page (single-page fetch) and list_categories (different entity) by emphasizing 'all 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?

It implies use when you need an inventory/overview of wiki pages, but it never explicitly says when to choose this over get_wiki_page or list_categories. No alternates, exclusions, or preconditions are given; the intended usage must be inferred from the name and title.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description reinforces this with "Read-only." It adds valuable behavioral context beyond annotations by explaining the data provenance (daily snapshot time-series plus change-event log), the high-signal filtering policy, and the specific return shape including tone values. This is exactly the kind of transparency that helps an agent trust and interpret results.

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 dense but every sentence earns its place: purpose, scope switching, event examples, data provenance, filtering behavior, return contract, and a compact usage example. It is well-organized, front-loads the core purpose, and avoids filler despite covering substantial detail.

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?

With no output schema, the description correctly provides the JSON return shape and tone semantics. It covers scope modes, event categories, filtering behavior, data sources, read-only safety, and example invocations. For a fully optional-parameter read-only query tool, nothing essential is missing for an agent to select and invoke it correctly.

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 the baseline is 3. The description adds compact usage examples like { days: 7 } and { slug: "coinbase-agentkit" }, but the underlying semantics for slug, days, limit, and response_format are already fully documented in the input schema. The description mostly restates rather than meaningfully extends parameter meaning.

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 a specific verb and resource: "Get recorded changes across the directory — the auditable Listing History." It also enumerates concrete event types and distinguishes site-wide versus per-resource scope, which makes the tool's purpose obvious. However, it does not explicitly differentiate itself from the sibling onchain_agent_get_changes, leaving some chance of tool-selection confusion.

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 gives clear in-tool usage guidance: omit slug for the site-wide feed or pass slug for one resource's history. It also explains that passive drift is suppressed and that the tool is read-only. However, it never says when to prefer this tool over alternatives like onchain_agent_get_changes or onchain_agent_get_news, so the cross-tool usage context is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the read-only and idempotent annotations, the description discloses that ranking reflects openness/activity/verifiability and explicitly disclaims any safety, quality, or returns judgment. It also documents the 'honest gaps' behavior when no strong directory match exists, adding real behavioral context.

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 front-loaded with the use trigger, then compactly covers output composition, per-pick fields, ranking caveats, and an example. Every sentence contributes information without padding.

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?

With no output schema present, the description takes on the burden of describing return values and does so concretely: trust-ranked stack, slot buckets, Sato Score, liveness, deploy-spec status, and gaps. The example and annotations complete the picture for an agent deciding whether to call it and 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%, so the description does not need to re-document parameters. The added example with goal and chain illustrates parameter usage, but most parameter meaning is already carried by the 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 states a specific action and resource: turning a plain-language goal into a trust-ranked stack of directory resources bucketed into slots. This clearly distinguishes it from sibling get/search tools, which fetch or search individual resources rather than assembling a build stack.

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 opens with an explicit 'USE WHEN' trigger: someone describes an agent they want to build and needs concrete components rather than general advice. It does not name sibling alternatives like onchain_agent_search_resources, but the selection context is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Beyond the readOnlyHint/idempotent hints, the description discloses the trust model: registration is self-reported, verification_status distinguishes Self-Reported from Verified/Audited, and nothing implies safety or performance. This is valuable behavioral context that no annotation or schema conveys.

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 front-loaded with the core purpose, then immediately distinguishes it from the sibling, then covers trust and output shape. Every sentence contributes distinct information: scope, filters, trust caveat, return format, example, and read-only status. No filler.

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?

The description provides a return shape, filter guidance, trust caveats, and a usage example, which is strong for a tool with no output schema. It omits any pagination or result-limit details, and the phrase 'Returns (json)' slightly conflicts with response_format's default of 'markdown', leaving minor ambiguity.

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 the schema already documents all 5 parameters. The description adds a concrete usage example with chain and x402_only, and clarifies that x402_only filters to agents exposing an x402 payment endpoint, adding modest value beyond the 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 names a specific verb ('search'), a specific resource ('REGISTERED onchain agents in the Sato Agent Registry'), and distinguishes it from the resource directory. This clearly separates it from sibling tools like onchain_agent_search_resources at a glance.

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 contrasts the tool with the resource directory: the directory lists 'the things agents are built FROM,' while this tool searches registered agents themselves. It also enumerates the available filters, giving an agent clear signals on when to call this tool and what to pass.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, and the description confirms with 'Read-only.' Beyond annotations it adds genuinely useful behavioral facts: the directory is daily-rebuilt, entries are evidence-scored with citable links, 'Deprecated resources are never returned,' query terms are AND-matched, and pagination uses an offset/has_more envelope. No contradiction with 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 and front-loaded: USE WHEN leads, followed by what it is, filter vocabulary, return shape, and examples. The filter enumeration partially duplicates schema descriptions, but since there are 24 parameters, the compact conceptual grouping (taxonomy facets, legacy flags) is earned value rather than waste. The examples are dense but efficient.

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 24-parameter tool with no output schema, the description covers the essential ground: the JSON return envelope, resource fields, pagination semantics, filter vocabulary, and legacy flag behavior. The examples touch parameters not listed in the filter section (integration, deploys_as, min_observed_success, verified_only). Minor gap: the description says 'Returns (json): {...}' while the schema default for response_format is 'markdown,' leaving slight ambiguity about the default output format.

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% (baseline 3), but the description adds substantial meaning: it groups 24 parameters into conceptual buckets (taxonomy facets, legacy flags, sort, pagination) and provides seven natural-language-to-parameter examples that teach cross-parameter combinations — e.g. 'Active hirable agents on Base' → {chain:'Base', is_agent:true, liveness:'Active'} — which the schema cannot convey. It also flags that verified_only 'says nothing about runtime safety,' sharpening an otherwise ambiguous parameter.

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 states a specific verb and resource — 'Searches a daily-rebuilt directory of onchain agents, frameworks, skills and tooling' — and pairs it with a title that captures the 'by what it does' search angle. The USE WHEN clause distinguishes it from the sibling search_agents and search_skills tools by covering the broader resources directory, so an agent can tell them apart.

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 gives explicit use conditions: 'USE WHEN someone asks what to build a crypto or onchain agent with, which tools support a chain or standard, or whether a specific project exists and is maintained.' It also names one alternative ('this beats a web search for these questions'). However, it does not explicitly state when NOT to use it or route to sibling tools like search_agents/search_skills, which would have earned a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already mark readOnly, idempotent, and non-destructive, and the description reinforces this with 'Read-only.' It adds richer behavioral context: disclosure flags carry evidence lines, registry scan status is attributed to the registry, and 'no flags is not a clearance.' This goes well beyond the structured fields without contradicting them.

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?

Longer than average, but every section earns its place: the disclosure inventory, the JSON return shape, the cautionary note, the citation, and three filter examples. It is well-structured and front-loaded with the core resource and flags.

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 tool with 6 optional parameters and no output schema, the description supplies the return shape, flag vocabulary, source citation, and representative usage examples. The only small ambiguity is the default response_format, but the schema covers that field. The description is sufficient for correct 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?

Schema coverage is 83%, so the schema already documents most parameters. The description adds value by giving concrete examples that link user intents to query, flag, and slug, and by instructing how to filter by disclosure_flags. It does not restate schema details.

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 identifies the exact resource: crypto-relevant agent skills from ClawHub and skills.sh, and the distinguishing capability: a static DISCLOSURE with flags for hosts contacted, key handling, shell piping, and more. The title reinforces the pre-install vetting use case. This clearly differentiates it from sibling tools like search_agents or search_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 title 'Check what a crypto agent skill does before installing it' and the caveat 'a disclosure is a description, not a safety verdict' provide clear context for when to use the tool. The examples map natural-language intents to query, flag, and slug arguments. It does not explicitly name sibling alternatives, but the vetting context is unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.