RiskDataApi — Solana token risk scoring for AI agents. Safety score, insider clusters, honeypot.
Scored across 6 tools
Most tools have clearly distinct purposes, but check_token_risk and check_token_risk_batch cover the same operation at different cardinalities and could be confused at a glance. The descriptions do explicitly clarify the difference, so ambiguity is limited.
All tool names use consistent snake_case with clear verb_noun patterns such as check_payment, create_topup_invoice, and get_token_risk_history. The batch variant follows the same convention with a suffix, making the naming highly predictable.
Six tools are well-scoped for a token risk API that also handles payment, key issuance, and historical data. Each tool has a clear role and the surface does not feel bloated or underspecified.
The core lifecycle is covered: free key issuance, top-up invoicing, payment verification, live risk checks, batch checks, and historical data. A minor gap exists around direct account/quota status inspection or subscription management, though agents can work around this via error responses and repeated checks.
Checks on-chain whether an invoice from create_topup_invoice has been paid and, if so, credits your key. Safe to call repeatedly (idempotent), at most once every 5 seconds per payment_id (after 30 checks per hour per key, once a minute); if throttled it returns error_code verify_rate_limited with retry_after seconds. Returns verified true/false with a reason.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional. Your RiskDataApi key, for MCP hosts that cannot send an Authorization header. If both are present, the Authorization header wins. | |
| payment_id | Yes | payment_id returned by create_topup_invoice |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: idempotency, per-payment_id 5s throttle, a 30/hour-per-key cap degrading to once a minute, the throttle error_code verify_rate_limited with retry_after, and the credit-your-key side effect. Return shape (verified true/false with a reason) is also disclosed, which is essential since no output schema exists.
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 core action and its side effect are front-loaded in the first clause, and every following clause carries operational information. The nested parenthetical rate-limit details make it dense to parse, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter polling tool with no annotations and no output schema, the description covers the prerequisite, throttling behavior, error contract, side effect, and return values. An agent has everything needed to call it and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, and the baseline of 3 applies. The description adds only implicit meaning by referencing payment_id as the throttling unit; api_key is left entirely to 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?
States a specific verb and resource ('Checks on-chain whether an invoice ... has been paid') plus the side effect ('credits your key'). It explicitly ties itself to the sibling create_topup_invoice, so an agent can distinguish it from check_token_risk and the other siblings without opening a schema.
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?
Establishes the prerequisite workflow (must follow create_topup_invoice) and gives polling guidance ('safe to call repeatedly (idempotent), at most once every 5 seconds'). It doesn't name an explicit alternative tool or state a when-not-to-use case, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a 0-100 safety score, on-chain insider wallet clusters (wallets sharing a first funder), mint/freeze authority status, holder concentration, and live price/liquidity/volume for a single Solana token mint. Use before recommending or executing a trade on any Solana token. 5 free anonymous calls/day, no signup. Then call get_free_api_key (15/day) or pay per call via x402; pass a key via the Authorization header or the api_key argument. Quota refusals return error_code + options[] with the exact next step.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | The Solana token mint address to check | |
| api_key | No | Optional. Your RiskDataApi key, for MCP hosts that cannot send an Authorization header. If both are present, the Authorization header wins. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the 5 free anonymous calls/day limit, dual auth paths (Authorization header vs api_key argument, header wins), the paid fallback, and the exact shape of quota refusals (error_code + options[]). It does not state whether the call is read-only/free of side effects beyond implication, nor latency or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is returned, then what it's for, then quota/auth/payment mechanics — a sensible priority order. Two sentences are dense but each clause (outputs, trigger, quota, auth precedence, error shape) carries distinct information; the error_code detail pushes it slightly long.
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?
No output schema exists, but the description enumerates the returned fields so the agent knows what it gets back, and auth/quota/error behavior covers the main failure modes. Only edge details (non-quota errors, response format, latency) are unaddressed, which is minor for a single-mint lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description still adds value by explaining how to obtain a key (get_free_api_key) and that the header takes precedence over the argument, which contextualizes the api_key param rather than restating it. The mint param is left entirely to 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?
States a specific verb+resource ('Returns ... for a single Solana token mint') and enumerates the exact payload: safety score, insider wallet clusters, mint/freeze authority, holder concentration, price/liquidity/volume. The word 'single' implicitly contrasts with the check_token_risk_batch sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use before recommending or executing a trade on any Solana token' gives an explicit usage trigger, and the quota/auth sentences route the agent to get_free_api_key or x402 payment. It never explicitly says when NOT to use it (e.g. 'for multiple mints use check_token_risk_batch'), so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Same as check_token_risk but for up to 25 mints in one call — N mints charged as N calls, same per-call economics as check_token_risk, no bulk discount. All-or-nothing: if the batch can't be fully covered by remaining quota/credit, the whole batch is rejected rather than partially processed. Needs an API key (Authorization header or api_key argument) or x402 — no anonymous batch calls.
| Name | Required | Description | Default |
|---|---|---|---|
| mints | Yes | 1-25 Solana token mint addresses | |
| api_key | No | Optional. Your RiskDataApi key, for MCP hosts that cannot send an Authorization header. If both are present, the Authorization header wins. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers the non-obvious traits: billing is N mints = N calls with no bulk discount, and the batch is all-or-nothing — rejected outright if quota/credit doesn't cover it, never partially processed. That atomicity and cost model are exactly what an agent must know before calling. Return shape and per-mint error handling are still unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the sibling comparison, then cost model, then atomicity, then auth. Every sentence carries distinct information. Slightly dense with repeated 'same per-call economics as check_token_risk' phrasing that could be trimmed.
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 2-parameter batch tool with no annotations and no output schema, the description covers auth, pricing, atomicity, and the single-vs-batch decision. The gap is response detail — no output schema and no statement of what each mint returns or how partial failure would look, though the all-or-nothing rule removes most of that concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so mints (1-25) and api_key are already fully documented, including the 'Authorization header wins' precedence rule. The description restates the 25 cap and auth paths, adding only the cost implication of mints length (N mints = N charges). 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 and resource (check risk for mints) and immediately scopes it against the sibling: 'Same as check_token_risk but for up to 25 mints in one call.' An agent can distinguish batch from single without opening either schema.
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?
Names the alternative (check_token_risk) and the condition selecting this tool (multiple mints, max 25). It also gives a prerequisite: API key or x402, no anonymous batch calls. It never states the inverse rule explicitly ('use check_token_risk for a single mint'), but the routing is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Solana payment invoice for your API key: kind "topup" adds call credit ($5-$500, usd_amount, default $5); kind "subscription" buys 30 days. Returns payment_id, the exact pay_amount and wallet_address. Send exactly pay_amount, then call check_payment. Max 3 pending invoices per key.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | topup (default) or subscription | |
| api_key | No | Optional. Your RiskDataApi key, for MCP hosts that cannot send an Authorization header. If both are present, the Authorization header wins. | |
| currency | No | Payment currency (default USDC) | |
| usd_amount | No | Top-up amount in USD, 5-500 (default 5); ignored for subscription |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and performs well: it discloses the required payment flow, return fields, top-up bounds, subscription duration, and the maximum number of pending invoices. It does not cover invoice expiry, overpayment behavior, or error cases, which keeps it from 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?
The description is dense and front-loaded, with zero wasted sentences. It moves from purpose to kind behavior to return values to next action to limits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return values despite there being no output schema, and covers the critical payment flow and limits. It is mostly complete, though it omits details about invoice expiry and failure handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents kind, usd_amount bounds, defaults, and currency options. The description reinforces kind and usd_amount behavior but does not add meaningful parameter guidance beyond what the schema provides, especially for currency and api_key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: creates a Solana payment invoice for an API key. It clearly differentiates the two invoice kinds, topup versus subscription, with concrete effects for each.
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 gives clear workflow guidance: send exactly pay_amount and then call check_payment. It also states a pending-invoice limit, which helps the agent understand operational constraints. It does not explicitly say when not to use this tool, but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issues a free RiskDataApi key for an email address (15 checks/day instead of 5 anonymous calls/day). No email verification. One active key per email; the key is returned once and also emailed. Use it when you hit the anonymous daily limit.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to register the free key to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does it well: it discloses the quota grant, the absence of email verification, the one-active-key-per-email constraint, and that the key is shown once and emailed. It doesn't say what happens if the tool is called again for an existing email (re-send vs error) or whether the email is validated.
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 dense sentences, front-loaded with the action and followed by constraints and a usage trigger. No filler; every clause adds operational 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?
No output schema exists, and the description compensates by explaining the return behavior (key returned once and also emailed). For a one-parameter issuance tool with no annotations, this covers everything an agent 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?
Only one parameter and schema description coverage is 100%, so the schema already explains the email field. The description adds only that the email is the identity the quota is bound to (one key per email), which is marginal beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Issues a free RiskDataApi key for an email address'. This is clearly distinct from all siblings (check_payment, check_token_risk, create_topup_invoice, etc.), none of which mint keys.
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 concrete trigger condition: 'Use it when you hit the anonymous daily limit.' The daily quota numbers (15 vs 5) make the selection criteria explicit. It does not name alternatives, but no sibling overlaps functionally, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns hourly historical data points (safety_score, insider_cluster_count, holder_count, price, liquidity, volume) for a mint over the last N days (max 90). Free and unmetered — no quota, works with or without an API key — pure read from stored history, no live upstream call.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days of history to return (default 30, max 90) | |
| mint | Yes | The Solana token mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden and does so excellently. It discloses that the tool is read-only ('pure read from stored history'), has no quota ('Free and unmetered'), needs no API key ('works with or without an API key'), and makes no live upstream call. This is rich, useful 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 three tight sentences with no filler. It front-loads the core function and returned fields, then adds the behavioral caveats. Every clause earns its place and the structure is easy to scan.
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-only tool with no annotations and no output schema, the description is remarkably complete. It covers purpose, output shape (listed fields), time window, quota, auth, and upstream behavior. 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%, so both mint and days are already documented. The description reinforces the max-90-day limit and adds hourly granularity, but it does not add meaningful new parameter-level meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') with a clear resource ('historical risk trend for a Solana token') and enumerates the exact data fields returned. The word 'historical' plus the time-window framing distinguishes it from siblings check_token_risk and check_token_risk_batch, which sound current-state oriented.
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 clearly implies when to use it: when a historical trend over multiple days is needed, not a current snapshot. It does not explicitly name the sibling alternatives or state when not to use the tool, but the context is unambiguous enough for an agent to make the right choice.
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.
check_paymentcheck_token_risk1 field changedInput schema / properties / api_keyAdded value: +{
+ "description": "Optional. Your RiskDataApi key, for MCP hosts that cannot send an Authorization header. If both are present, the Authorization header wins.",
+ "maxLength": 200,
+ "type": "string"
+}check_token_risk_batch1 field changedInput schema / properties / api_keyAdded value: +{
+ "description": "Optional. Your RiskDataApi key, for MCP hosts that cannot send an Authorization header. If both are present, the Authorization header wins.",
+ "maxLength": 200,
+ "type": "string"
+}create_topup_invoiceget_free_api_keycheck_token_riskcheck_token_risk_batchget_token_risk_historySolana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Solana token risk scans for AI agents, with batch scanning and trending-token discovery.
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Add one secure layer between your agents and this server.
