Crypto intelligence: rug/scam scans for any token, verified whale flows, AI signals + track record
Scored across 9 tools
Most tools target clearly distinct resources: news, signals, track record, launches, search, coin data, whale flows, and token safety. The main overlap is between scan_token and analyze_token for token risk, and between get_coin and get_whale_flows for per-coin whale activity, though the descriptions explain the fast/deep and per-coin/aggregate distinctions.
The set uses snake_case throughout and mostly follows an action_noun pattern such as analyze_token, get_coin, get_news, and scan_token. Minor deviations are search lacking a noun and get_track_record being slightly less parallel, but the convention remains predictable.
Nine tools is well scoped for a crypto intelligence server. Each tool covers a distinct workflow such as scanning, deep analysis, signals, news, whale flows, launches, search, and agent performance.
The surface covers the core lifecycle of discovering, checking, analyzing, and monitoring crypto assets and agent signals. Minor gaps include no dedicated full report retrieval beyond search results, and limited historical price or chart data, but agents can work around these for the stated purpose.
Slower, deeper report (10–40 s) written by ARC AI's model: overall score, scam probability, risk/hype/whale scores, narrative tags, section-by-section analysis and holder/developer data. Prefer scan_token for a quick safety check; rate-limited to about 15 per minute.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional token name, helps the report | |
| chain | No | Chain the token lives on | solana |
| ticker | No | Optional ticker, helps the report | |
| tokenAddress | Yes | Token contract (EVM 0x…) or Solana mint address |
| Name | Required | Description |
|---|---|---|
| name | No | Token name |
| report | No | Link to the report on arcai.io |
| ticker | No | Token ticker |
| summary | No | AI-written summary |
| sections | No | Report sections |
| hypeScore | No | Hype score 0–100 |
| riskScore | No | Risk score 0–100 |
| riskMetrics | No | Risk metrics |
| overallScore | No | Overall intelligence score 0–100 |
| narrativeTags | No | Narratives the token belongs to |
| whaleInterest | No | Whale interest 0–100 |
| scamProbability | No | Estimated scam probability 0–100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and world-access are covered structurally. The description adds genuinely useful context beyond them — 10–40 s latency and a ~15/minute rate limit — but says nothing about failure modes, caching, or what happens when an address is unknown. Solid additive value on top of a lower bar, 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?
Two sentences, both front-loaded: the latency cost and report contents lead, the alternative tool and rate limit follow. No filler or restatement of the title.
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 an output schema present, the description need not explain return values, yet it still summarizes the report's payload. Combined with read-only annotations plus disclosed latency and rate limits, an agent has everything needed to call 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% (including address formats and chain enum), so the schema already carries parameter meaning. The description adds no syntax, format, or filtering detail beyond what is in the schema, so the baseline 3 applies.
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+resource (a deep AI-generated token report) and enumerates exactly what it contains: overall score, scam probability, risk/hype/whale scores, narrative tags, section analysis, holder/developer data. It is immediately distinguishable from scan_token, the sibling it names 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?
"Prefer scan_token for a quick safety check" gives an explicit alternative and the condition that selects it, and the opening "Slower, deeper report (10–40 s)" frames the tradeoff. The agent knows both when to reach for this tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price and 24h change for a coin plus ARC AI's own data on it: 24h whale buys/sells, the latest call from each agent (with that agent's graded accuracy) and its ARC AI listing score if listed.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker, e.g. SOL, JUP, BONK |
| Name | Required | Description |
|---|---|---|
| note | No | Hint when not found |
| arcai | No | ARC AI data: whale flow, latest agent calls with accuracy, listing |
| found | No | false when ARC AI has no data for this ticker |
| price | No | Price USD |
| ticker | No | Ticker |
| change24h | No | 24h change % |
| marketCap | No | Market cap USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world reach are covered. The description adds one genuinely useful behavioral detail — the listing score is present only 'if listed', i.e. a conditionally-present field — but says nothing about data freshness, caching, or what happens for an unknown ticker.
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?
One sentence, front-loaded with the core value (price and 24h change) before the colon expands into the ARC AI-specific extras. Dense but every clause names a distinct returned dataset; 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?
An output schema exists, so return-value explanation is not strictly required, yet the description usefully previews the payload shape. For a one-parameter read tool the coverage is nearly sufficient; the missing piece is guidance on selecting this over the more specialized sibling tools.
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%: the single ticker parameter is documented with format examples (SOL, JUP, BONK). The description adds no format, casing, or resolution rules beyond what the schema already states, so the baseline 3 applies.
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 the resource (a coin) and enumerates exactly what data is returned — price, 24h change, whale buys/sells, latest per-agent call with graded accuracy, and listing score. It is a clear retrieval purpose, but it never distinguishes itself from siblings like get_whale_flows or get_track_record, some of whose data it aggregates.
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?
There is no when-to-use or when-not-to-use guidance and no named alternative, even though sibling tools (get_whale_flows, get_track_record, get_signals, analyze_token) clearly overlap with the data this tool returns. The agent must infer that this is the 'overview' entry point versus the specialized siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New Solana tokens (under 7 days old, $10K+ liquidity) with an activity score, RugCheck safety label (safe / caution / risky), suspicious-volume flag (likely wash trading), liquidity, 24h volume and trades.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many launches to return (1–50) | |
| safe_only | No | Only tokens with a clean RugCheck scan and no suspicious volume |
| Name | Required | Description |
|---|---|---|
| launches | No | New tokens, most active first |
| scannedAt | No | When the radar was last refreshed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context the schema doesn't carry: the implicit 7-day age cutoff, the $10K liquidity floor, and the existence of a wash-trading heuristic. However, most of the sentence enumerates return fields that the output schema already defines, so net added value is moderate.
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?
A single dense sentence that front-loads the resource and inclusion criteria before the field list. No filler or repetition, though the trailing field enumeration makes it run long rather than optimal.
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 an output schema present and annotations covering the read-only profile, the description only needs to frame filters and usage, which it partially does. It omits sort order, default behavior when no filters are passed, and any hint about how the activity score is computed, leaving meaningful gaps for an agent deciding how to call it.
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 both limit and safe_only are fully documented in the schema and this is a baseline 3. The description implicitly clarifies safe_only by explaining what the RugCheck safety label and suspicious-volume flag mean, but adds no syntax, ordering, or defaulting detail 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 pins down a specific resource and scope: new Solana tokens under 7 days old with $10K+ liquidity, plus the exact enrichment fields returned (activity score, RugCheck label, wash-trading flag, liquidity, volume, trades). It is clearly a 'list fresh launches' tool rather than a single-token analyzer. It lacks an explicit verb ('get'/'list') and does not distinguish itself from neighbors like scan_token or analyze_token, which also involve token safety analysis.
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?
There is no when-to-use guidance, no mention of when NOT to use it, and no routing to alternatives such as scan_token or analyze_token for deeper per-token work. The agent must infer the tool's role purely from the returned-field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest ARC AI market news stories (title, summary, coin, link). Stories include ARC AI's own whale and agent data where available.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional coin ticker filter, e.g. SOL | |
| limit | No | How many stories to return (1–20) |
| Name | Required | Description |
|---|---|---|
| items | No | Results, newest or most relevant first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuine provenance caveat — stories blend external news with ARC AI's own whale/agent data 'where available' — which warns of inconsistent content coverage, but says nothing about freshness, caching, or result ordering.
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 short sentences, zero waste, with the resource and returned fields front-loaded before the data-provenance caveat.
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 two-parameter read tool with an output schema, the description is nearly sufficient; the return shape need not be restated (it partly is anyway). Only the freshness/cadence of 'latest' news is left unstated.
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 'coin' (ticker filter with example) and 'limit' (1–20, default 10) are fully documented in the schema. The description adds no filtering or pagination detail beyond that, so the baseline 3 applies.
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+resource ('Latest ARC AI market news stories') and even enumerates the returned fields (title, summary, coin, link). It is clearly distinguishable from the sibling tools (get_coin, get_whale_flows, get_signals), though it never explicitly contrasts itself with them.
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?
Usage is only implied by the word 'Latest' — an agent can infer it should call this for recent news, but there is no stated when-to-use, no exclusions, and no routing against siblings like get_signals or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest signals from ARC AI's six agents: verified whale trades, Sentinel rug warnings, Hunter launch picks, momentum and narrative calls. Newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only signals of this type | |
| limit | No | How many signals to return (1–50) |
| Name | Required | Description |
|---|---|---|
| items | No | Results, newest or most relevant first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds the ordering behavior ('Newest first'), which is genuinely useful context, but says nothing about freshness, rate limits, pagination, or the difference between the ALERT tag and the other categories.
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?
A single sentence that front-loads the source and scope, then lists categories, then ends with the ordering guarantee. No filler, no restatement of the title.
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?
An output schema exists, so return structure need not be explained, and the two optional parameters are fully covered by the schema. What is missing is routing information against the many overlapping siblings, which is the main thing an agent still needs.
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 both parameters are already documented, and the enum values are self-explanatory. The description's category list loosely maps to the tag enum, adding marginal value but no filtering syntax or semantics 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?
States a specific resource (an aggregated feed of signals) and enumerates the content types: verified whale trades, Sentinel rug warnings, Hunter launch picks, momentum and narrative calls. This is far more informative than a tautology, but it never distinguishes itself from siblings that cover overlapping territory (get_whale_flows, get_launches, get_news).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance at all. Given siblings like get_whale_flows and get_launches whose subject matter is explicitly named in this description's own category list, an agent gets no help deciding whether to call this aggregated feed or the specialized tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How often ARC AI's agents were right: graded BUY / SELL / rug-warning calls over the last 30 days per agent, plus recent calls with the evidence each was graded on. Use it to decide how much weight to give a signal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| agents | No | Per agent |
| source | No | Track record page |
| totals | No | All agents |
| window | No | Time window, 30 days |
| recentCalls | No | Recent graded calls |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declared, the description usefully adds the 30-day window, the per-agent breakdown, and that each recent call comes with the evidence it was graded on. It does not mention rate limits, freshness, or pagination behavior, but the added scoping is meaningful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: the first front-loads the data content and the second states the use case. No filler or 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?
An output schema exists, so the description need not explain return shapes, and it correctly focuses on scope and purpose. For a zero-parameter read tool this is nearly complete, with only minor gaps around interpretation or staleness of the 30-day window.
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 tool takes no parameters and schema coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies: no param semantics are needed and none are missing.
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 resource (per-agent grading accuracy of BUY/SELL/rug-warning calls over 30 days) with the concrete scope of the data. It is clear what 'track record' means, though it does not explicitly name a sibling tool to contrast with (e.g. get_signals), so differentiation is inferential rather than stated.
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 it to decide how much weight to give a signal' gives a clear decision context, effectively linking it to signal-consuming siblings like get_signals. It stops short of naming an alternative or an exclusion condition, so it is strong context but not full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified on-chain whale trades ($10K+ DEX swaps) in the last 24h, combined per coin: buys vs sells in USD, net flow, number of wallets, plus the most active whale wallets. Also big Hyperliquid futures orders per coin (longs vs shorts opened, latest orders with wallet and position after) — leveraged bets, reported separately from the DEX buys and sells. Optionally narrow to one coin by ticker or contract address.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Optional ticker (e.g. JUP) or contract address |
| Name | Required | Description |
|---|---|---|
| flows | No | Per-coin flows, biggest first |
| source | No | Page with every trade and its transaction link |
| totals | No | Totals across all coins |
| window | No | Time window, 24h |
| futures | No | Hyperliquid futures whales, 24h (not purchases; not included in flows) |
| topWallets | No | Most active whale wallets |
| minTradeUsd | No | Smallest trade counted, USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and openWorld, and the description adds real behavioral context beyond them: the 24h window, the $10K+ threshold, 'verified on-chain', and that futures orders are reported separately from DEX buys/sells. It doesn't cover rate limits or data freshness beyond the window, so not a 5.
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 dense sentences that front-load the DEX whale flow data and then the futures data, with the optional filter last. Slightly heavy with parentheticals, but every clause carries 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?
With an output schema present, the description needn't explain return values, and it covers scope, time window, threshold, and the DEX/futures separation. An agent has enough to call it correctly, though a comparison cue against siblings would make it fully complete.
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 and already documents ticker or contract address. The description only restates that the filter is optional, adding no syntax or format detail beyond the schema, so the baseline 3 applies.
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 resource and data type: aggregated on-chain whale DEX swaps ($10K+) and Hyperliquid futures orders per coin, with buys/sells, net flow, and wallet counts. This is far more than a restatement of the name. It does not explicitly differentiate itself from siblings like analyze_token or scan_token, which keeps it at 4.
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?
Usage is implied by the content (24h whale flow summary, optionally narrowed by token). The description mentions the optional narrowing, which is a light usage cue, but it never says when to choose this over analyze_token or scan_token, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast rug/scam check for any Solana or EVM token by contract address (1–3 s, no AI cost). Returns a CLEAN / CAUTION / RISKY verdict with plain-language reasons, contract checks (mint & freeze authority, LP lock, honeypot, buy/sell tax, top holder, RugCheck or GoPlus risk score) and live market data (price, liquidity, 24h volume and trades, market cap, pool age). Use this before recommending or trading any token.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Token contract (EVM 0x…) or Solana mint address |
| Name | Required | Description |
|---|---|---|
| name | No | Token name |
| note | No | Disclaimer |
| chain | No | solana, ethereum, base, bnb, arbitrum, polygon or avalanche |
| found | No | false when no trading pool exists (e.g. a wallet address) |
| links | No | arcai.io scan page, chart and ARC AI listing |
| market | No | Live market data from the deepest pool |
| symbol | No | Token ticker |
| address | No | The address that was scanned |
| reasons | No | Plain-language reasons behind the verdict |
| verdict | No | Overall safety verdict |
| security | No | Contract checks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true and openWorldHint=true, so safety is established; the description then adds non-obvious traits: 1-3s latency, no AI cost, and the shape of the result (CLEAN/CAUTION/RISKY plus contract checks and market data). It does not discuss rate limits, rate-limit failures, or behavior on unrecognized addresses/chains.
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 dense sentences, front-loaded with the purpose and ending with the call to action. Every clause carries information, though the enumerated return contents partly duplicate the output schema.
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 one-parameter read-only scan with an output schema present, the description supplies everything else an agent needs to choose and invoke it: speed, cost, chains, verdict vocabulary, and a recommended usage moment.
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% and there is a single required parameter, so the baseline is 3. The description adds chain context (Solana mint vs EVM 0x) but no format, normalization, or validation guidance beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: a fast rug/scam check for Solana or EVM tokens by contract address, and defines the scope (both chains, address-keyed). It never distinguishes itself from the overlapping sibling analyze_token, so an agent cannot tell the two apart from the description alone.
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?
Gives a clear trigger: 'Use this before recommending or trading any token.' That is actionable usage context. However, it names no alternative (e.g. analyze_token) and states no exclusions or conditions under which this tool is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ARC AI for a coin or project by name or ticker: listed projects, tracked tokens with prices, published AI reports and news stories.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name or ticker |
| Name | Required | Description |
|---|---|---|
| news | No | News stories |
| tokens | No | Tracked tokens with prices |
| reports | No | Published AI reports |
| projects | No | Projects listed on ARC AI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world profile is covered. The description usefully enumerates the content classes reachable through search (projects, priced tokens, reports, news), but adds nothing about result ordering, matching behavior, or result limits.
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?
One sentence, front-loaded with the verb and scope, with zero filler. The enumeration of searchable content is the only elaboration and it earns its place by widening the query semantics.
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?
An output schema exists, so return shape need not be explained, and annotations cover the safety profile. For a one-parameter read tool the description is nearly sufficient; only the routing guidance versus the specific getter siblings 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?
There is a single parameter and schema coverage is 100%, so the schema fully documents 'query' (Name or ticker). The description's 'by name or ticker' merely restates the schema field rather than adding syntax, partial-match, or ticker-format guidance. Baseline 3 for full 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?
States a specific verb (Search) and resource (ARC AI) plus the entity and content scope: coins/projects by name or ticker, listed projects, tracked tokens with prices, reports, and news. This cross-entity breadth implicitly distinguishes it from the narrower get_coin/get_news siblings, but no sibling is named or contrasted.
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 says what can be searched but gives no when-to-use guidance, no indication that this is the entry point when the entity or its ID is unknown, and no exclusions relative to get_coin, get_news, or scan_token. The agent must infer the routing decision from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_whale_flows1 field changedOutput schema / properties / futuresAdded value: +{
+ "description": "Hyperliquid futures whales, 24h (not purchases; not included in flows)",
+ "properties": {
+ "coins": {
+ "description": "Per coin: longs / shorts opened and closed in USD, orders, wallets",
+ "items": {
+ "properties": {},
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "recent": {
+ "description": "Latest big orders: coin, wallet, side, usd, dir (Open Long, Close Short, ...), positionUsd after (+ long / - short)",
+ "items": {
+ "properties": {},
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}analyze_tokenget_coinget_launchesget_newsget_signalsget_track_recordget_whale_flowsscan_tokensearchMemecoin safety scanner for Solana, BNB and Robinhood Chain with an onchain track record
Token rug-risk scans, Know Your Agent wallet checks and deployer reputation for AI agents.
AI crypto signals, whale positions, 19 technical indicators, derivatives, screener and backtests
Pay-per-call crypto intel via x402: honeypot/rug check, whale flows, unlocks, MEV, liquidation risk
Add one secure layer between your agents and this server.
