OnchainAI

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

Discloses payment requirement, potential connection errors, and return data fields. Lacks explicit safety hints but is informative given no 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?

Three sentences efficiently convey purpose, constraint, and alternatives with no 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?

Covers purpose, usage constraints, return data, and alternatives; complete for a simple health-check tool without 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?

Adds context beyond the schema: slug must come from search_tools and be x402-listed, fully covering the single 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?

Description clearly states the tool returns premium trust data including endpoint liveness, probe uptime, and last probe time for x402-listed tools, distinguishing it from the free get_tool_detail 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?

Explicitly describes when to use (for x402-listed tools) and when not to (standard MCP clients cannot pay), and provides alternatives (get_tool_detail, HTTP client).

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?

No annotations provided, so description carries full burden. It discloses the potential x402 payment requirement and HTTP 402 response behavior. While it doesn't explicitly state read-only nature, the 'compare' action implies idempotency, and the payment disclosure is valuable.

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 states core purpose, second adds payment caveat and alternative. Extremely concise, front-loaded, 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?

Given no output schema, the description does not specify return format, but the tool is simple (one parameter). The purpose, constraints (2-4 slugs), and behavioral notes (payment) are adequately covered. Could mention output structure but not essential for a comparison 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% with clear description for 'slugs' parameter (min/max items). The description adds context about what the comparison includes (trust, install risk, etc.) but does not provide additional parameter-level semantics beyond the schema. 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 uses a specific verb 'Compare' and resource 'approved tools' with explicit scope: 'side-by-side on trust, install risk, chains, pricing, and x402 status'. It clearly distinguishes from sibling 'get_tool_detail' which returns a single tool detail.

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 notes when payment may be required (x402 premium enabled) and provides a free alternative: 'call get_tool_detail for each slug'. This gives clear when-to-use vs. when-not-to-use 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?

With no annotations, the description carries full burden. It discloses the payment requirement and HTTP 402 response, output format, and that only approved tools are exported. It does not detail side effects or if the operation is read-only, but based on purpose it appears non-destructive.

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 usage, second covers important behavioral caveat. No redundant or irrelevant information. Front-loads 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?

Given no output schema, the description should explain return structure. It mentions 'JSON + markdown install kit' but does not detail contents. It also does not clarify that slugs and category are mutually exclusive or mention the max 25 slug limit from schema. Adequate for a simple export, but gaps remain.

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 for both parameters. The description adds value by stating that 'slugs or a function category id' are alternatives, implying mutual exclusivity (though not explicitly). This goes slightly beyond the 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 verb 'Export', the resource 'bundle of approved tools', and the output format 'JSON + markdown install kit for agents'. It distinguishes from sibling tools like get_tool_detail and search_tools by focusing on exporting a bundle.

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 when to use (to export approved tools via slugs or category) and includes a notable caveat about potential payment requirements (402 error). However, it does not explicitly contrast with alternatives or state prerequisites.

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?

With no annotations, the description carries full burden. It discloses that the tool is public and requires no login (read-only behavior). However, it does not mention other behavioral traits like rate limits, data freshness, or whether it mutates state (implied not). Simply stating 'snapshot' adds some transparency but not comprehensive.

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 a single sentence of 14 words, front-loading key details ('Public no-login snapshot'). Every word adds value, no redundancy or fluff.

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, the description lists the categories covered (tool coverage, trust, x402, featured tool lists), giving a good sense of response structure. The parameter is documented. It could be improved by clarifying if 'per section' applies to each category individually, but overall sufficient for a simple snapshot 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 already describes the 'limit' parameter. The tool description does not add extra meaning about the parameter's effect on the response (e.g., default behavior if omitted). Baseline score of 3 is appropriate as the schema does the heavy lifting.

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 provides a 'public no-login snapshot' covering specific areas: tool coverage, categories, trust, x402, and featured tool lists. This distinguishes it from sibling tools like get_tool_detail (single tool) or list_categories (just categories), giving a broad aggregated view.

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. While the description implies it's for a public overview without login, it doesn't mention when not to use it or compare to siblings like search_tools or check_endpoint_health.

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?

With no annotations, the description carries full burden. It mentions a safety condition but omits details about response format, error handling, or rate limits. The behavioral disclosure is functional but minimal.

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 concise sentences, front-loaded with purpose. Every part earns its place—purpose, parameter guidance, and safety condition. No waste.

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 tool with 2 parameters and no output schema, the description covers purpose, parameter sources, and a safety condition. It lacks response format details, but overall it is sufficiently complete for the tool's complexity.

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%; both parameters have descriptions. The description adds value by specifying the slug's origin (search_tools or get_tool_detail) and reiterating platform options, enhancing clarity beyond the 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 it returns a platform-specific install guide and specifies the required parameters (slug, platform). It distinguishes from siblings by noting that slug must come from search_tools or get_tool_detail, establishing its niche.

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 tells when to use this tool ('Pass slug from search_tools or get_tool_detail and platform') and includes a critical when-not-to-use condition: 'If blocked=true or risk_level=critical, do not install.' The platform enum is also listed.

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?

No annotations are provided, so the description must convey behavioral traits. It implies this is a read operation by listing fields returned, but it does not disclose whether the tool has side effects, requires authentication, or what error behavior looks like. It mentions 'verify' but doesn't detail the response format, leaving some ambiguity.

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 sentences long, front-loads the core purpose in the first sentence, and provides usage context in the second. No extraneous 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 no output schema, the description partially compensates by listing some return fields (install risk, x402 verification flags, chains, repo). However, it omits other possible details and does not mention the output format or error scenarios. It adequately positions the tool in the workflow with sibling tools, but falls short of full completeness.

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 'slug', and the description repeats the schema's explanation ('slug from search_tools results'). While it adds context about sourcing the slug, it does not add new meaning beyond what the schema already provides, earning a baseline of 3.

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 verb (Get) and resource (full detail for a tool by slug), and lists specific attributes (install risk, x402 verification flags, chains, repo). It also distinguishes itself from siblings by indicating it should be called before get_install_guide.

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?

Explicit guidance on when to use: 'Use the slug from search_tools results' and 'Call before get_install_guide to verify trust status, x402, and install risk.' This provides clear context and sequence relative to 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?

No annotations are provided, so the description must fully disclose behavioral traits. It only states listing categories with counts, but does not mention any potential side effects, data freshness, or performance characteristics, leaving uncertainty about read-only nature.

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 concise sentences front-load the purpose and action, 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?

The tool has no parameters and no output schema; the description explains the purpose and a usage hint but does not describe the return format (e.g., structure of categories with counts), leaving a gap in completeness.

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?

There are no parameters, so schema coverage is trivially 100%. The description adds no parameter details, but baseline for zero parameters is 4.

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 verb 'list' and the resource 'tool categories with counts', and distinguishes from sibling tools like search_tools by indicating the output id can be used as a filter parameter.

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 mentions browsing as the use case and directs how to use the returned id with search_tools, providing good context. Lack of when-not-to-use guidance prevents a higher score.

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?

No annotations provided; description covers basic behavior but doesn't disclose rate limits, authentication, or edge cases like empty results. Adequate but not exhaustive.

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?

Concise but covers key points: purpose, usage guidance, examples, and alternative. Front-loaded with main verb.

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 6 parameters, no output schema, and sibling tools, description provides enough context for use. Lacks return format or error details but acceptable for a search 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 covers all 6 parameters with descriptions; description adds context for sort (trust alias) and cursor pagination, 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?

Describes specific action (search) on a specific resource (OnchainAI tool database) by capability. Distinguishes from sibling tools like list_categories and get_tool_detail.

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 states when to use (find/compare tools), provides examples, and directs to list_categories for browsing by function.

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