OnchainAI
Server Details
Crypto tool MCP: search/trust/install-risk. Remote tools/call is x402 paid.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Coinyak/onchainai
- GitHub Stars
- 1
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.1/5 across 12 of 12 tools scored. Lowest: 3.4/5.
Each tool serves a clearly distinct purpose: search, detail, comparison, recommendation, gap audit, export, health check, price history, trends, categories, install guide, dashboard snapshot. No two tools overlap in functionality, enabling an agent to select the correct tool unambiguously.
All tool names follow a consistent verb_noun pattern with lowercase and underscores. Verbs like check_, compare_, export_, get_, list_, recommend_, and search_ are used predictably, making the tool surface easy to navigate.
With 12 tools, the count is well-scoped for a tool discovery and evaluation platform. Each tool covers a distinct aspect (search, detail, comparison, recommendation, audit, export, health, trends, etc.) without being excessive.
The tool surface covers the full lifecycle of discovering, evaluating, and installing crypto tools: searching, getting details, comparing, diagnosing gaps, getting recommendations, exporting, checking health, viewing trends and history, listing categories, and obtaining install guides. No obvious gaps for the stated purpose.
Available Tools
12 toolscheck_endpoint_healthAInspect
Premium K2 x402 trust data: endpoint liveness, 30-day probe uptime, and last probe time for a listed x402 tool. On public POST /mcp requires ~$0.001 USDC (Base, CDP env gate) per call — HTTP 402 + PAYMENT-REQUIRED. Standard MCP clients (Claude Code, Cursor) cannot complete payment and may show a connection error — use free get_tool_detail for x402 verification flags, or GET /api/v2/premium/check-endpoint-health/{slug} with an x402-capable HTTP client. On POST /mcp/okx this is part of the OKX package rate.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug from search_tools — must be an x402-listed tool |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses payment requirement (~$0.001 USDC per call), HTTP 402 response, and incompatibility with standard MCP clients, which is critical 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 a single dense paragraph containing valuable info but could be more structured; some technical details (e.g., 'HTTP 402 + PAYMENT-REQUIRED') could be streamlined for readability.
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 hints at return fields (liveness, uptime, last probe time) and covers payment flow and alternatives; mostly complete for a simple 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 description adds context beyond schema: 'Tool slug from search_tools — must be an x402-listed tool', clarifying the parameter's source and constraint.
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 'endpoint liveness, 30-day probe uptime, and last probe time for a listed x402 tool' with specific verb+resource, and distinguishes from sibling get_tool_detail by noting it provides 'x402 verification flags' instead.
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 advises when to use alternatives: 'use free get_tool_detail for x402 verification flags, or GET /api/v2/premium/check-endpoint-health/{slug} with an x402-capable HTTP client' and warns that standard MCP clients 'cannot complete payment and may show a connection error'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_toolsAInspect
Free discovery on public POST /mcp: compare 2–4 approved tools side-by-side on trust, install risk, chains, pricing, and x402 status. Alternative: call get_tool_detail for each slug. On POST /mcp/okx this tool is package-metered.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Tool slugs to compare (2–4 unique) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the endpoint and pricing model, but does not mention whether it is read-only, any authentication requirements, rate limits, or side effects. The 'Free discovery' hint is vague about behavioral traits.
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 with three sentences that cover the core action, an alternative, and a context variation. No filler or 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 the tool's simplicity (one parameter, no output schema, no annotations), the description provides a good overview of purpose, constraints, and alternative. It could mention the output format but is otherwise complete enough for an agent to decide 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?
The only parameter 'slugs' is described in the schema. The description adds meaning by specifying the count constraint (2–4) and explaining that the tool compares tools, contrasting with fetching detail individually via `get_tool_detail`.
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 that the tool compares 2–4 approved tools on specific dimensions (trust, install risk, chains, pricing, x402 status), using a specific endpoint. It distinguishes itself from the sibling `get_tool_detail` by offering side-by-side comparison.
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 usage context: free on public POST /mcp, package-metered on POST /mcp/okx, and mentions an alternative method (calling get_tool_detail for each slug). While it doesn't explicitly state when not to use, the alternative implies a different use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_toolkitAInspect
Premium: export a bundle of approved tools as JSON + markdown install kit for agents. Pass slugs or a function category id. Always paid on public POST /mcp — $0.01 USDC on Base (Axis B / site_settings; HTTP 402 + PAYMENT-REQUIRED). Not free discovery. On POST /mcp/okx uses the OKX package rate instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | No | Explicit tool slugs to export (max 25) | |
| category | No | Alternatively export top tools for a function category |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully covers behavioral traits: it discloses payment requirement (cost and currency), error code (HTTP 402 with PAYMENT-REQUIRED), and endpoint variance for OKX. It implies a read-only export but does not elaborate on other behaviors like auth beyond 'Axis B / site_settings'.
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 relatively concise, front-loading the primary action. Each sentence adds value, though 'Axis B / site_settings' is somewhat cryptic. Overall, it is efficient with minimal 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?
Given the absence of an output schema, the description should explain the output structure more fully. It mentions 'JSON + markdown install kit' but lacks details on format or fields. The description covers endpoints and cost adequately but leaves behavioral details slightly incomplete.
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 each parameter already having a description. The description adds the context 'Pass slugs or a function category id' but does not provide additional semantics beyond what the schema already conveys.
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 exports a bundle of approved tools as JSON and markdown install kit. The verb 'export' and resource 'toolkit' are specific, and the description distinguishes it from sibling tools like 'get_install_guide' or 'search_tools' by focusing on bundling and approval.
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 states this is a premium, always paid operation ('$0.01 USDC on Base', 'Not free discovery') and mentions alternative endpoint pricing. It does not explicitly state when not to use this tool or compare to alternatives, but the cost and endpoint details provide clear context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gap_auditAInspect
Premium: decomposes a task intent into subgoals and maps each to OnchainAI catalog tools, surfacing gaps where no tools exist. Returns a subgoal table with covered (candidate slugs) or gap (manual research needed) status. Always paid on public POST /mcp — $0.01 USDC on Base (Axis B; HTTP 402 + PAYMENT-REQUIRED). Use free search_tools for simple lookups. On POST /mcp/okx uses the OKX package rate instead.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Natural-language task intent (e.g. 'bridge BTC to Base then swap to USDC and stake') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses premium cost ($0.01 USDC on Base), HTTP 402 payment requirement, endpoint-specific rates, and return format (subgoal table with covered or gap status). No annotations provided, so description carries full burden and meets it.
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 plus a third clarifying endpoint difference. Information-dense with no fluff. Purpose and key details 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?
Covers premium nature, cost, endpoint variations, return value, and alternative tool. Despite no output schema, the description fully informs agent about tool behavior and outcomes.
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?
Only one parameter (intent) with 100% schema coverage; schema already describes it as natural-language task intent. The description adds an example but no additional semantic beyond what the 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?
Clearly states that the tool decomposes a task intent into subgoals and maps them to catalog tools, surfacing gaps. Differentiates from sibling 'search_tools' by specifying premium nature.
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 tells when to use (gap analysis for complex intents) and when to use alternative ('Use free search_tools for simple lookups'). Also explains payment contexts (POST /mcp vs /mcp/okx).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dashboard_snapshotAInspect
Public no-login snapshot of OnchainAI tool coverage, categories, trust, x402, and featured tool lists
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum tools or buckets per section |
Tool Definition Quality
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.
get_install_guideAInspect
Get platform-specific install guide. Pass slug from search_tools or get_tool_detail and platform (claude, cursor, generic). If blocked=true or risk_level=critical, do not install.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug from search_tools or get_tool_detail — do not guess slugs | |
| platform | Yes | Target agent environment for install steps |
Tool Definition Quality
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.
get_price_historyAInspect
Free discovery: x402 endpoint price and liveness history for a specific tool. Returns probe records (status, actual price, latency) over the specified time window. Use get_tool_detail for current x402 flags.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days of history (default 30, max 90) | |
| slug | Yes | Tool slug from search_tools — must be an x402-listed tool |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the output format (probe records) but does not detail the data source, freshness guarantees, rate limits, or any side effects of invoking this read-only tool. The description is minimal and lacks safety or cost 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 concise with three sentences: first states purpose, second specifies return fields, third points to an alternative. No redundant information; each sentence contributes meaningfully.
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 that there is no output schema, the description adequately covers what the tool returns (probe records) and the time window concept. It also mentions the sibling tool. However, it could mention that the slug must correspond to an x402-listed tool, which is only in the schema. Overall, it is mostly complete for a simple 2-parameter 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 parameter descriptions. The description restates the time window concept but adds no additional meaning beyond the schema. According to guidelines, baseline is 3 for high coverage, and the description does not compensate with extra detail.
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: retrieving price and liveness history for a specific x402-listed tool. It explicitly mentions returning probe records with status, actual price, and latency, and distinguishes itself from get_tool_detail for current flags.
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 some guidance by noting 'Free discovery' and suggesting get_tool_detail for current flags. However, it lacks explicit when-to-use versus alternatives like get_x402_trends or check_endpoint_health, and does not mention prerequisites or ideal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tool_detailAInspect
Get full detail (install risk, x402 verification flags, chains, repo) for a tool by slug. Use the slug from search_tools results. Call before get_install_guide to verify trust status, x402, and install risk.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Tool slug from search_tools results |
Tool Definition Quality
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.
get_x402_trendsBInspect
Free discovery: aggregated x402 ecosystem trends — live rate, probe counts, and latest prices for all x402 tools.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to aggregate (default 30, max 90) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden but only says 'aggregated' and lists data types. It does not disclose read-only status, rate limits, data freshness, or any side effects.
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?
Single sentence packs key information (free discovery, aggregated trends, live rate, probe counts, prices). Front-loaded with 'Free discovery' to indicate cost. Slightly less structured 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?
Given one optional parameter and no output schema, the description is adequate but lacks details about return format and data structure. Could be more complete for a trend 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 adequate parameter description ('Number of days to aggregate (default 30, max 90)'). The description adds no additional meaning 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 clearly states it returns aggregated x402 ecosystem trends including live rate, probe counts, and latest prices. It distinguishes from siblings like get_price_history by focusing on aggregation and free discovery.
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 use for exploring trends but does not explicitly state when to use or avoid this tool versus alternatives. No when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
List all tool categories with counts. Use for browsing what exists on OnchainAI. Pass the returned id as search_tools category to filter by function.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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.
recommend_verified_toolAInspect
Premium: returns a single verified live x402 tool for a task. Probes top candidates on-demand for liveness and price honesty, then returns the best one with rejection reasons for the rest. Always paid on public POST /mcp — $0.01 USDC on Base (Axis B; HTTP 402 + PAYMENT-REQUIRED). Use free search_tools first to check if candidates exist. On POST /mcp/okx uses the OKX package rate instead.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Optional chain filter (e.g. base, ethereum, solana) | |
| intent | Yes | Natural-language task intent (e.g. 'bridge USDC to Base', 'get Ethereum price data via x402') | |
| function | No | Optional OnchainAI function filter (bridge, swap, wallet, payments, lending, staking, trading, nft, data, dev-tool, identity, governance, social, ai-agent) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses payment requirement ($0.01 USDC), probing logic for liveness and price honesty, and that it returns rejection reasons. No annotations provided, so description covers full 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?
Three sentences with zero waste. Front-loaded with core purpose, then usage and payment details.
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?
Adequately covers purpose, when to use vs sibling, behavioral traits, parameter usage, and return value. No output schema but description states what is returned.
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 already describes all 3 params (100% coverage). Description adds value by explaining how intent is used in probing and recommendation, but does not repeat 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?
Explicitly states it returns a verified live x402 tool for a task, contrasting with free search_tools. Verb 'recommend' and resource 'verified live x402 tool' are clear.
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?
Directs to use search_tools first, explains payment scenarios (POST /mcp vs POST /mcp/okx), and clarifies it is premium/paid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_toolsAInspect
Search OnchainAI for crypto/onchain MCP, CLI, SDK, API, x402, and AI-agent tools by capability. Use when you need to find or compare tools for a task. Examples: bridge USDC to Base, Uniswap MCP server, Solana wallet SDK. For browsing by function, call list_categories first and pass the returned id as category.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ranking strategy. trust currently sorts by stars until a dedicated trust signal ships. Defaults to relevance. | |
| chain | No | Optional chain filter, such as base, ethereum, solana, arbitrum, or bitcoin | |
| limit | No | Maximum number of tools to return; defaults to 10 | |
| query | Yes | Natural-language capability, package, protocol, or tool name to search for | |
| cursor | No | Pagination offset string from the previous next_cursor (e.g. "10", "20"). Omit or pass "0" for the first page. | |
| category | No | Optional OnchainAI function filter. Use list_categories ids (bridge, swap, wallet, payments, lending, staking, trading, nft, data, dev-tool, identity, governance, social, ai-agent). |
Tool Definition Quality
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.
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!